社区医疗服务中心信息系统的设计与实现-软件工程专业毕业论文

摘要摘要摘要摘要厦门市以调整和优化医疗卫生资源结构为手段，加快构建新型城市卫生效劳二级体系，2023年确立了政府主导、表达公益性质的社区卫生效劳“厦门模式一。这一模式解决了区域卫生存在的很多问题，在全国产生较大影响。如何建立一套可推广可移植的区域协同医疗集成平台和运行机制，为创立全新的符合国家新医改政策的现代医疗效劳模式提供强大的信息化技术支撑能力，把三级医院和社区形成一个整体，．使总院与社区实现真正意义上的一体化，同质化，初步解决“看病难’’、“看病贵"、“看病乱"是一迫切的问题。本文在分析了建立符合“厦门模式’’的社区医疗效劳中心信息系统重大意义的根底上，详细阐述了社区医疗效劳信息系统的需求分析、设计和实现。该系统可有效实现病患完整的诊疗信息在社区与医院之间的共享与交换，促进居民就医模式向“小病在社区，大病到医院，康复回社区，保健不出门"的转变，从而极大的优化医疗资源的运行负载，推动医疗卫生行业的健康开展，为人民谋取更大利益。关键词：区域医疗；厦门模式；HISAbstract‘'XiamenAbstract‘'Xiamenmode'’forthecommunityhealthservicewasestablishedin2023whichwasgovernment-ledandreflectingthepublicnaturethroughtheadjustingandoptimizingofthestructureofhealthca∞resourcesandalsotheacceleratingtheconstructionofsecondarycityhealthservicesystem．Thismodesolvesmanyoftheexistingregionalhealthproblemsandhasagreaterimpactinthewholecountry．It’Sanurgentissueabouthowtosetupaportableregionalcollaborationhealthcareintegrationplatformanditsrunningsystem．Itistoprovideapowerfulinformationtechnicalsupportforthenewmodemhealthcaremodelswhichisunderconstructionandsuitingforthehealthcarereformpolicy．Andit’Salsotoformthetertiaryhospitalandcommunityhospitalasaunity,integrateandhomogenizethegeneralhospitalanditscommunityhospitals．Wimthissystemit’Stoimtiallysolvetheproblemssuchas‘'hardtoseedoctor'’and“expensivetoseedoctor'’，andSOon．Thisdissertationintroducesthesignificanceoftheconstructionofcommunityhealthserviceinformationsystem．Onthisbasis，thedissertationproposedthesystemrequirementanalysis，systemdesignanditsimplementation．ThisSyst锄willleadtotheeffectiveinterventionsontreatmentofpatientinformationbetweenhospitalsandcommunities．Thiswillpromotethemodelchangeforpeopletooptimizethehealthcareresources，andpromotethehealthydevelopmenttoseekgreaterbenefitsforthepeople．Keywords：RegionalHealth；XiamenMode；HIS第一章绪论第一章第一章绪论第一章 绪论1．1 研究背景及意义2023年2月，厦门市正式实施医疗重组方案，将原来社区卫生效劳中心的医疗效劳与公共卫生效劳职能做出合理划分。医疗效劳职能由市属三级综合性医院派出的社区医疗效劳中心承接，采用属地就近原那么布点，由三级医院分区、分片延伸医疗效劳，从三级医院一直到社区医疗机构，组成假设干个一体化管理的医疗效劳集群，承当根本医疗效劳职能。其中厦门第一医院承当7个，中山医院及市中医院分别承当其中4个社区医疗中心。这些机构的名称一般为：3级医院名称+所在街道名称+社区医疗效劳中心名称。公共卫生效劳职能由区政府承接，每个街道主持一个社区公共卫生效劳中心。对区政府主持的社区公共卫生效劳中心，采取收支两条线，由差额拨款改为全额拨款，确保公共卫生效劳中心能够专心从事公共卫生职能。这些机构的名称为：厦门市+所在行政区名称+所在街道名称+社区公共卫生效劳中心名称。厦门市卫生局制定下发了{：厦门市社区医疗效劳中心管理方法?、?厦门市社区公共卫生效劳中心管理方法?、?社区医疗效劳中心设置标准?、?社区公共卫生效劳中心设置标准?和?社区医疗效劳中心根本用药目录?等一系列标准性文件。市委机构编制委员会办公室等有关部门制定并下发了?关于贯彻<中共厦门市委、市政府关于改革和开展医疗卫生事业、破解人民群众‘就医难’的决定>有关职能、机构、编制和人员调整的实施意见?、市财政局、市发改委等有关部门制定了?关于社区医疗卫生效劳补助政策的意见?。同时分两批预拨了补助经费901．57万元和1366万元，确保了社区医疗效劳中心的正常运转。在医改大潮的推动下，厦门市对原来社区医疗效劳中心公共卫生与根本医疗功能进行合理划分，推进厦门市医疗资源的垂直整合，构建出具有厦门特色的新型社区医疗效劳体系。由三级医院承办社区医疗效劳中心：由区政府承办社区公共卫生效劳中心：实行全额拨款、收支两条线。从效果看降低了医疗和药品费用，提高了居民满意度。但也存在三级医院对社区医疗效劳理念理解偏误，财政补偿1社区医疗效劳社区医疗效劳中心信息系统的设计与实现机制不完善等多种问题，需进一步探索一套与之相适应的运行管理机制。厦门在医改方面一直走在前面。国内社区医院管理模式一直有两种意见：一种是社区卫生中心管理模式，另一种是大医院承办社区医院的模式。厦门市在全国率先大规模尝试了大医院承办社区医院的改革方法。这种方法有利于大医院直接帮助社区医院提高医疗水平，解决居民“大病上医院，小病上社区"的后顾之忧。国内其他地区的社区卫生中心独立管理社区医院，与大型医院的关系很难捋顺，双向转诊没有“利益根底"，因而很难实现，而厦门模式的大医院和社区医院实际是一个医疗集团，这样的管理模式和信息系统都比拟容易。随着医疗改革的不断深入，我们还面临社区医疗体系建设新形势的挑战，面临着与公共卫生信息体系、社区基层医疗体系等方面互联互通、共享信息新任务的要求【11。由此可见，建立一套符合“厦门模式’’、覆盖社区全业务的社区医疗信息系统是必要的，它的完善和建立具有重大的意义。(1)实现社区医疗效劳中心和医院的双向转诊、跨医疗部门的信息调阅、慢病患者的自动建档与跟踪、居民健康档案辅助建档，并自动将患者诊疗记录转换成标准的居民健康档案。实现了区域内医疗资源的共享【3A】。(2) 社区医疗效劳管理信息系统使工作效率明显提高。通过厦门市民健康数字平台的接入，使社区与其他医疗机构之间实时互联互通、信息共享、双向转诊，降低了医疗本钱，减少了过失事故；远程会诊、远程心电检查等可及时解决医疗难题，对于提高医疗质量有重大实际意义。1．2论文研究内容与结构本文根据厦门市社区医疗效劳中心的现状，以“厦门模式"为指导思想，设计和实现了一个社区医疗效劳管理信息系统，用于解决“信息孤岛’’、医疗资源利用不充分、保密性差等问题。以系统的开发过程为根底，围绕系统开发技术分析、系统需求分析、系统框架设计、系统模块实现等步骤展开论述。论文的主要内容如下：(1) 本文首先研究分析了系统开发的相关技术，包括数据效劳WebService、网络数据平安对称加密与非对称加密、串口通讯以及Socket通讯技术；2第一章绪论(2)第一章绪论(2)对社区医疗效劳管理信息系统展开进行全面的需求分析，包括系统架构选择分析、社区医疗效劳业务分析以及数据技术分析；(3)开发实现了社区医疗效劳管理信息系统，重点阐述了各子系统模块的设计与实现过程，从系统架构设计、硬件环境要求等总体方案设计到功能实现的说明，并对接口局部设计进行详细阐述。本文的结构安排如下：第一章分析社区医疗效劳管理信息系统中的现状与问题，并引出解决方法，最后给出本文的研究内容。第二章对社区医疗效劳管理信息系统中的关键技术进行介绍，包括数据共享效劳、对称与非对称加密等。第三章社区医疗效劳管理信息系统的需求分析。 第四章社区医疗效劳管理信息系统设计方案及实施。第五章总结和展望。3社区医疗效劳社区医疗效劳中心信息系统的设计与实现第二章相关技术介绍2．1数据共享效劳0AtebService)WebService是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。WebService可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他WebService应用程序可以发现并调用它部署的效劳。WebService是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地表达在互联网和企业内部网上。可将Web效劳视作Web上的组件编程【5I。WebService的结构如图2．1所示。图2．1：WebService结构资料来源：?基于WebService的教学资源效劳系统的研究和实现?[61可扩展的标记语言XML是WebService平台中表示数据的根本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(w3c)创立，w3c制定的XMLSchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型【71。WebService平台是用XSD来作为数据类型系统的。当你用某种语言如4第二章相关技术介绍VB．NET或C群来构造一个Web第二章相关技术介绍VB．NET或C群来构造一个WebService时，为了符合WebService标准，所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这种东西就是一种协议，如SOAP[51。微软的．NET技术应该算是时下最为流行的WebService开发技术。首先因为其公司在以前相应的产品就占有相当大的市场份额，以至使新推出的．NET得以有比拟稳定的用户群；其次也是更重要的是，．NET平台不仅延续了微软一贯的编程风格，而且还增加了许多支持Web效劳的关键性技术，使得．NET在操作的简单性和执行的稳定性，高效性上到达了一个非常好的结合。许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或．NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、VisualBasic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这二样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的“高级程序到程序交流(APPC)〞等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过WebService，客户端和效劳器才能够自由的用HTTP进行通信，不管两个程序的平台和编程语言是什么【刀。2．2PowerBuilderPowerBuilder美国Sybase公司研制的一种新型、快速开发工具，是C／S结构下，基于Windows平台的一个集成化开发工具。由于PowerBuilder采用了面向对象和可视化技术，提供可视化的应用开发环境，使得我们利用PowerBuilder，可以方便快捷地开发出利用后台效劳器中的数据和数据库管理系统的数据库应5社区医疗效劳社区医疗效劳中心信息系统的设计与实现用程序【23】。PowerBuilder提供了对目前流行的大多数关系数据库管理系统的支持，由于在PowerBuilder的应用程序中对数据库访问的局部一般采用国际化标准数据库查询语言SQL，使得用PowerBuildcr开发的应用程序可以不做修改或者只做少量的修改就可以在不同的后台数据库管理系统上使用。也就是说用PowerBuilder开发的应用程序是独立于效劳器上的数据库管理系统的。和大多数的WINDOWS应用程序一样，PowerBuilder也是事件驱开工作方式【241。在这种工作方式中，程序的运行没有固定的流程，程序中的代码也是为各种可能发生的事件编写的，当程序开始运行之后，它就可以接受来自系统，用户或者其它应用程序触发的事件，然后执行相应的事件代码。事件驱动的工作方式与面向对象技术是紧密相关的，在PowerBuilder应用程序中，接受发生的事件的往往就是程序界面中的各种可视化对象。为了给用户提供各个方面的支持，PowerBuilder具有自己的编程语言POWERSCRIPT，这个语言除了提供根本的流程控制语句，还提供了几百个函数来操纵各种对象和提供诸如DDE，OLE等方面的支持瞄】。此外我们还可以定义自己的函数，处理特定的事件。学习PowerBuilder时相当一局部的时间就是用来了解和熟悉PowcrBuiIder提供的各种函数。PowerBuilder一个很大的特点就是提出了数据窗口对象的概念。数据窗口对象也是PowerBuilder中的一种对象类型，与其它对象不同的是数据窗口对象是专门为了访问后台的数据库效劳的，在数据窗口对象中我们定义了数据的来源和数据的显示风格，这样在应用程序中我们就可以把精力完全放在程序的运行流程控制上，而不用关心具体数据的来源，因为我们在数据窗口对象中已经定义好了数据的来源【261。如果需要使用数据库中不同的数据也只要对数据窗13对象进行修改就可以了。特别要指出的是PowerBuilder在数据窗口对象中提供了丰富的数据显示方式，可以满足各种不同的需要。在PowerBuilder较新的版本中提供了根底类库PFC，它为应用程序的开发提供了许多可重用的预定义类和对象，利用根本类库PFC可以快速开发出高质量重用性好的应用程序。真正发挥面向对象编程的巨大威力。6第二章相关技术介绍2．3本章小结第二章相关技术介绍2．3本章小结本章主要针对社区医疗效劳中心信息系统中所用的关键技术进行简要说明，由于WebService基于SOAP，具有标准、开放、平安、跨平台等特性，所以做为向厦门市市民健康信息平台传输的标准手段和方式。而对于社区内部业务来说，系统要求稳定、快速、操作体验要求高、便于维护和定制，所以采用了PowerBuilder这个比拟成熟的数据库开发工具。7社区医疗效劳社区医疗效劳中心信息系统的设计与实现第三章 系统需求分析社区医疗效劳管理信息系统是社区医疗效劳面向社区全体居民，开展全方位社区医疗效劳工作的信息平台。系统以个人、家庭为单位，以健康档案为主线，在生命全周期的时间范围内，通过系统、连续地采集和运用各种健康数据，以提高社区医疗效劳工作的系统性、针对性及有效性、及时性，是促进社区居民健康改善、降低整体医疗费用的重要技术手段。目前，国内的大多数的社区医疗效劳管理系统大多是基于传统的医院管理信息系统和早期的公卫管理信息系统演变而来，多侧重于社区卫生效劳机构人、财、物的管理和一些公共卫生效劳信息的记录和上报功能，规划和设计在一定程度上偏离了社区卫生效劳的本质，难以满足新型社区卫生效劳体系“全人群、全生命周期、全方位〞的社区健康效劳需求。现结合近几年来从事社区医疗管理工作和社区医疗信息化建设工作的经验和教训，就新型社区的医疗效劳建设的需求进行分析。3．1架构及环境的需求分析在架构和环境的需求分析时，可以有两种选择。 第一种方案是采用C／S两层架构方式，通过程序直连本地数据库效劳器，把本社区的业务数据直接存入数据库当中。然后再将这局部数据同步或者异步传入市民健康数据中心。当遇到需要调用其他医疗机构资源时，那么直接从市民健康数据中心获取。其特点为：(1)考虑到社区的客户端数量不多，该方式具有很高效的业务数据吞吐能力和处理能力，能支撑起多患者涌入社区的压力；(2) 社区需要单独的数据库效劳器。另一种方案是采用C／S／S的三层架构方式，数据库采用托管方式，把业务数据通过调用应用效劳器的webservice效劳向托管数据库写入。然后通过应用服务器同步或者异步传入市民健康数据中心。其特点为：8第三章系统需求分析(1)第三章系统需求分析(1)业务数据吞吐能力较第一种情况下较弱，但是能支撑起客户端并发数较多的情况；(2) 社区不需要安装单独的数据库效劳器；(3) 业务数据在多社区间交互操作较多的情况下比拟擅长。事实上，两种方案特点鲜明，在性能与价格之间各自占有优势，所以都有各自的市场，对区域医疗信息化建设来说，取舍的原那么很简单，就是实用主义，既无需恐惧高科技，裹足不前，也不必一味追求先进，浪费资源。3．2医疗效劳需求分析新医改方案明确提出从2023年开始，逐步在全国建立统一的居民健康档案。因此建设基于健康档案的区域卫生信息平台建设，是当前的医改方向。而新形势下的社区医疗效劳关系信息管理系统就不能是仅仅是满足乡镇社区的需求，而是要满足健康档案的需求，满足区域医疗信息平台的需求。1、切实执行国家相关法律、标准与标准：从2023年5月19日到2023年12月31日，卫生部陆续发布了包含?健康档案根本架构与数据标准(试行)?【161、?住院诊疗根本数据集标准?【17】、<电子病历根本架构与数据标准(试行)?Os)、?国家卫生数据字典与元数据管理系统(试用)?【19】等38个医疗卫生相关标准与标准，加上原来发布的众多管理标准与法律法规，根本涵盖了医疗卫生的各个领域，也为农村卫生信息系统的开发奠定了坚实根底。这些标准定义了191个分类代码，2252个(其中1163个公用数据元)已定义数据元全部给出了相关定义，包括命名、定义、属性、代码分类等，有些标准还给出了具体的技术路线与系统应遵循的技术架构。2、平安与准确是系统的根本需求：对于基层医疗卫生机构来说，信息系统将逐步成为其运营的支撑平台，容不得任何的过失和平安漏洞。一方面，医疗卫生机构是一个经济体与效劳机构，有经济体运行的必然法那么和效劳业的市场特点；另一方面，又是保障地球上最重要资源——人的生命的机构，生命无价，因此医疗质量、医疗平安是医疗信息系统的核心价值所在，在设计其信息系统时，9社区医疗效劳社区医疗效劳中心信息系统的设计与实现必须充分考虑系统的平安体系和数据的准确性。3、以卫生局集成平台、数据中心为核心支撑，在兼顾应用的情况下，尽可能简化技术架构，统一技术平台：国内社区医疗机构实际使用的医院信息系统现状，大多是多个应用并存，从保护投资和尊重操作习惯考虑，实际又不太可能全部推翻重来，因此通过一个集成系统来解决社区医疗信息系统所包含的临床信息系统、管理信息系统、公共卫生和妇幼保健等系统的集成，是一个现实可行的方案。但另一方面，考虑资金投入、数据集成的难易性、后期维护等多方面考虑，还是应该在兼顾应用的情况下尽可能简化技术架构，统一技术平台。4、以病人为中心优化流程，进行流程再造、职能重组：信息化建设不是简单地现行流程的计算机模拟，而是要从管理角度出发，大胆尝试新的管理流程；同时为了对旧的工作习惯的尊重，利用参数，将原来的流程也用参数支持起来，大大加强了系统的生命力。信息系统建设的业务需求必须是以病人为中心，因此必须以病人为主体进行流程优化、改造，通过流程的再造，同时对工作人员的职能归并与分解，优化组织结构，提高工作效率。核心原那么是在保证医疗质量的前提下，只要是符合病人利益的就应该坚决地执行。5、以健康档案为核心进行信息的收集、存储和分析：根据健康档案的根本概念和系统架构，健康档案的根本内容主要由个人根本信息和主要卫生效劳记录两局部组成。由于人的主要健康和疾病问题一般是在接受相关卫生效劳(如预防、保健、医疗、康复等)过程中被发现和被记录，所以健康档案的信息内容主要来源于各类卫生效劳记录。主要有三个方面：一是卫生效劳过程中的各种效劳记录；二是定期或不定期的健康体检记录；三是专题健康或疾病调查记录。6、重视接口体系的设计：通过以下方面的措施，以期在必要时可以方便的(至少在技术上可行的)与任何第三方互联互通。7、重视运行维护体系：实际工作普遍存在着“重建设、轻维护"的现象，认为运行维护不能产生利润、是花钱的工作，这就容易造成运行维护工作得不到应有的重视，也给应用系统的平安运行带来较大的风险。因此，为了保证运行维护工作正常进行，就必须坚持科学开展观，对运行维护工作要有正确的认识。lO第三章系统需求分析3．2．1第三章系统需求分析3．2．1 区域诊疗一卡通目前，各医疗卫生业务部门都各自建立了相应的业务管理系统，重复采集患者的根本信息增添了不必要的麻烦，而且造成了个人根本信息的不一致，并且各部门为提高智能化管理水平，很多部门都有面向效劳对象发卡的意愿，这种情况将会导致医疗卫生的效劳对象在不同机构接受效劳时都要办理不同的多张卡和各类证件。因此，厦门市卫生厅为了适应医疗体制的改革开展，充分利用现代信息技术，已经在规划建设一个全省统一标准标准的“一卡通"应用系统，实现业务信息互联共享，提高医疗卫生管理和效劳水平，真正做到便民利民。建立全省的病人主索引ID，任何诊疗行为均记录在主索引下面，能够将各种卡(社保卡、健康卡等)关联到该主索引上，实现全市医疗效劳和公共卫生效劳“一卡通"健康卡主要应用在就诊、保健、方案免疫、健康咨询等，其主要功能是：识别持卡者在医疗卫生各项业务中的合法身份，并作为办理业务的电子凭证；替代手工完成信息录入，增强数据真实性和准确性，提高工作效率；在信息网络建设先期不完善的情况下，辅助网络准确性，实现医疗卫生业务有关信息的收集和交换，完成信息识别；在网络完善后，完成必要的信息交换，减少网络传输量，并：充分利用IC卡的信息识别和完成必要的信息交换，减少网络传输量，并充分利用IC卡的信息识别和平安认证功能提高系统平安性；实现业务的电子化办公和社会化运行，增强管理部门的管理力度，增强业务的透明度，实现各项业务的信息共享和交换，并与其他政府部门间的相关信息进行交换。由于该社区医疗效劳管理信息系统作为厦门卫生局市民健康集成平台的一局部，必须满足一卡通功能，才能满足根本的数据交换的第一步要求。3．2．2电子健康档案共享电子健康档案包括居民从生到死整个生命周期所有的关于医疗健康保健的信息和资料，包括居民的根本信息、出生证明、个人健康档案、家庭健康档案、每次就诊的病历、报告、处方、体检结果等等，电子健康档案的共享就是各医疗社区医疗效劳社区医疗效劳中心信息系统的设计与实现卫生机构(医院，社区中心、乡镇卫生院、村卫生室等)将各自对居民医疗卫生服务的业务数据采用统一的标准汇总到数据中心形成每个居民完整的健康档案信息，同时各医疗卫生机构又能够方便地共享查询这些资料为居民提供医疗卫生服务。3．2．3 社区同其他医疗机构协作需求2023年2月21日，国务院在?关于开展城市社区卫生效劳的指导意见?(国发(2023)10号)中指出，“建立社区卫生效劳机构与预防保健机构、医院合理的分工协作关系。实行社区卫生效劳机构与大中型医院多种形式的联合与合作，建立分级医疗和双向转诊制度，探索开展社区首诊制试点，由社区卫生效劳机构逐步承当大中型医院的一般门诊、康复和护理等效劳【加1。"分级医疗和双向转诊制度，即社区卫生效劳机构与区域大中型综合医院、专科医院签订协议，让一般常见、多发的小病在社区卫生效劳机构治疗，大病那么转向二级以上的大医院，而在大医院确诊后的慢性病治疗和手术后的康复那么可转至社区卫生效劳机构。这样，就可以实现“小病不出社区，大病及时转诊〞。实现社区中心院前检查、观察、院后康复，缩短平均住院日，减少平均住院费用，提高床位使用率，进一步利用有限的卫生资源，指导与帮助社区诊疗质量的提高，以及医院对社区的有效监管并提高管理效率。3．2．4 公共卫生与妇幼保健需求妇幼保健信息信息需与其他信息系统数据实现共享与交换，实现妇幼保健业务与医疗业务，妇幼保健行政管理业务的全面整合。3．2．5 疾病预防信息交换的需求为预防、控制传染病的传染与流行，疾病控制机构对传染病预防与控制进行综合管理，主要包括疫情报告、传染病监测、疫情调查与控制。社区门诊点发现传染病病例后，经过确诊，填写传染病报告卡，上报区级疾控中心和区卫生局相12第三章系统需求分析关业务部门，区级疾控中心收集辖内的传染病报告卡，记录到传染病报告卡数据第三章系统需求分析关业务部门，区级疾控中心收集辖内的传染病报告卡，记录到传染病报告卡数据库中，并根据数据库里的记录进行统计分析，形成各种报表上报到市疾控中心，并进行分析。33数据设计需求分析(1)数据标准：符合国家和卫生部有关数据集标准及数据标准要求。在省卫生厅发布?福建省社区卫生信息系统数据标准?后，按照该标准对软件进行改造和升级。(2) 数据平安：保证数据平安，数据不能被非法窃取、篡改和删除。(3)数据输入：提供准确、快速、完整性的数据输入操作手段，实现应用系统在数据源发生地一次性输入数据。数据采集表的工程可维护、可定义为必填工程；支持多途径多方式采集数据，包括键盘、鼠标、电子卡、数据文件及网络等；对采集的数据要进行逻辑审核校验；并记录数据来源(门诊、电话、上门等)、采集人和录入时间；提供批量数据的快速录入、导入功能。(4)数据处理：对采集和加工后的数据可进行查询、查重、查漏、取消作废、修改、删除、打印、汇总、统计的功能。所有个案数据都可实现结案、取消结案；所有数据、查询结果和统计报表均能打印、显示和导出，导出的文件应有Excel、txt等通用、公开文件格式。(5)数据接口：提供基于WEBSERVICE的标准数据接口，接口方式平安、高效。提供逻辑审核功能，所有导入数据均需审核通过前方能写入。提供仪器设备接口、LED等显示设备、语音设备和读写卡设备的接口。提供与其他系统数据共享的功能。(6)数据备份：具有数据备份的功能，包括自动定时数据备份和手工操作备份。要求同时提供数据库格式和通用格式(txt文本文件、dbf数据文件等)两种备份文件。提供的备份程序可设定应备份的数据库和数据表、间隔时间、备份地址，支持完全备份和增量备份；支持通用格式文本备份。有管理数据备份的功能，能实现备份情况的查询统计。为防止不可预见的事故及灾害，数据必须异地备份功能。13社区医疗效劳社区医疗效劳中心信息系统的设计与实现(7)数据恢复：提供数据恢复程序实现备份数据的恢复，包括操作系统恢复和手工操作恢复；可选定文件、日期来恢复数据。(8)数据传输：可通过VPN虚拟专线在公众数据网络上建立属于本系统的私有数据网络。通过相应的加密和认证技术以确保用户的数据在公用网络上的传输平安，从而实现网络数据的专有性。(9)数据交换：提供完整的数据交换解决方案，包括双向转诊、数据更新、数据同步等。支持离线方式，保证系统的(划价、收费)关键业务不间断运行，并在网络恢复时进行数据同步，并保证数据的一致性。同时，系统应能提供在终端意外断线或脱机情况下查询特定历史数据的功能。3．4本章小结本章主要针对社区医疗效劳中心信息系统的硬件环境需求、社区业务需求以及设计需求分别进行阐述。作为一个完整的工程需求分析必须对整个工程所涉及的各个环境进行严密的需求分析。往往有许多人在做需求分析的过程中，只重视用户需求分析或设计需求分析两者之一，所以造成了用户所期望的产品和设计交互后的产品偏差很大，最终产品不能满足用户的需要而导致工程失败。14第四章系统设计与实现第四章第四章系统设计与实现第四章 系统设计与实现为了更好地效劳厦门市民，提高各社区医疗效劳中心业务和管理水平，厦门市第一医院要求各个社区医疗效劳中心和总院建立统一的计算机业务平台，实现网络化数据管理。建立一套完整的、综合程度较高的社区卫生效劳中心信息系统，主要包括社区医疗效劳中心的医疗业务工作站、健康档案和慢病管理、药品与财务管理、社保接口、厦门市市民健康系统接口和厦门市疾控中心系统接口等。在性能技术指标上要求实用且易操作、技术成熟可靠、平安性强，易维护和可扩展虚盘4．1系统整体设计方案。矗4．1．1 系统设计目标等，(1)支持社区医疗效劳中心的日常业务工作。(2) 以简化流程，方便市民为原那么，尽量切合临床习惯，注重实效。(3)程序界面要符合Windows界面标准。系统操作界面必须符合Windows界面标准，做到标准、美观、简洁、大方。(4)采用Oracle9i[36’37’381作为数据存储平台。(5)必须采用全编译的开发语言。为了提高系统的响应时间和效率，开发语言必须经过完全的编译，而不是基于解释型运行。(6)要求开发商对效劳器进行合理配置、对软件合理设计、优化，以保证数据的平安、运行速度等方面问题；(7)实现全科诊疗业务电子化；(8)总院与下属的社区采用相同的价表；(9)能够对内部的药品流进行管理；(10)实现医院与社区间双向转诊；(11)实现社区医疗机构门诊建档和慢病管理；15社区医疗效劳社区医疗效劳中心信息系统的设计与实现(12)实现管理数据的统计分析；(13)实现社区慢病档案的批量导出；(14)本工程不得与中华人民共和国法律相抵触，应符合卫生部及国家中医药管理局发布的?医疗机构管理条例?、?医疗事故处理条例?、?医疗机构病历管理规定?、?病历书写根本标准(试行)?等规定，如相关法律及规定有变动，本工程中标人应负责免费随之改动，防止与相关法律相抵触。4．1．2 系统设计原那么(1)先进性原那么：社区医疗效劳管理信息系统涉及到系统思路要从以往的内部网络系统的管理模式向广域网的协同作业管理模式的较大的转变，所以采用的技术必须具有先进性和实用性，系统设计的架构同时必须具有高扩展性，而在业务模式的处理上那么必须符合实际工作中的应用，但也要考虑到流程的优化和重构，使系统的建设既可满足实际的需要，又能适应新的管理模式的要求。(2)高扩展性：社区医疗效劳管理信息系统所采用的技术需有较大的扩展空间，所开发的业务系统也相应要预留全面扩展的能力。不能仅着眼于当前的系统要求上，而是应该进行高起点的全局规划，把本工程作为未来一个完整的社区医疗信息共享效劳平台的一个根底工程来开发，在不浪费现在投资的前提下，可方便地进行扩展和改造，而不能“头疼医头，脚疼医脚"，等系统将来无法适应新形势时全盘推到重来。(3)平安性：由于局部功能涉及到居民完整的健康档案的管理，所以系统的平安性至关重要。系统在设计上要能充分保证数据的平安性，防止居民隐私等泄露，同时也要注重系统运行的平安性，不能发生系统的崩溃和效劳的中断。(4)高性能的业务处理能力：一个工程的成功一定是该工程具有高性能的业务处理能力，而对业务处理能力的要求又是专业性极强的医疗相关的信息系统的关键要求，所以本工程的业务处理系统必须是基于完整的、稳定的，同时又是具有极高业务处理能力的一套成熟应用软件来开发的。16第四章系统设计与实现4．1．3第四章系统设计与实现4．1．3 系统架构与技术方案根据前期的业务和环境的需求分析，并结合和响应“厦门模式〞下社区医疗的要求，我们可以把社区医疗效劳管理系统分解成2个局部：HIS管理系统、公共卫生与保健。为此将分别采用两种系统框架：HIS管理系统局部采用C／S方式的两层架构，以满足它实时性的需要；而公共卫生与保健局部采用C／S／S的三层架构，以满足它机构间更快捷的数据访问要求，如图4．1所示。图4．1整体架构设计图社区HIS建设方案拓扑图如图4．2所示。蕾萱亩看官省凰毒0重眦蟹愚护士工作站 门诊药虏 医技科室图4．2社区HIS建设方案拓扑图17社区医疗效劳社区医疗效劳中心信息系统的设计与实现4．1．4 系统环境及其技术性能要求(1) 数据库效劳器环境a．操作系统：WIN2023Serverlb．数据库：ORACLE9i以上(2) 终端用户设备环境a．操作系统：Windows2000及以上版本；b．浏览器：MicroSoftIE5．0及以上版本；(3) 开发工具钆开发语言：．NET，PB，Java、VisualBasielb．开发工具：不限；，～4) 支持TB级超大容量数据存储。(5) 公卫HIS支持1000台以上终端同时使用。(6) 系统支持双机热备份，高可靠性设计，支持7x24小时不问断运行。(7) 高平安性，符合国家法律、卫生行政部门、医疗单位及病人对健康信息资料的平安性要求。(8) 中标供给商对应用系统能够实现非现场远程维护。(9) 系统采用分立化设计，便于各模块拆卸、替换及更新升级。4．1．5 系统接口要求(1)要求把用户就诊的患者的各种信息，通过本系统与厦门市卫生局市民健康信息系统的接口，实现在全市范围内的共享，并归档到市民健康信息系统的个人健康档案里。(2) 厦门市卫生局市民健康信息系统采用标准的XML格式为数据交换18第四章系统设计与实现格式，本系统必须支持生成符合标准第四章系统设计与实现格式，本系统必须支持生成符合标准标准的数据，然后调用WebService接口提交数据。(3) 由于提交的数据在广域网上传输，所以必须采用厦门市卫生局市民健康信息系统制定的压缩、加密和编码标准。(4) 响应厦门市劳动局的要求，必须满足易联众(原实达科技)医保接口的要求，能进行医保卡病人进行医保卡就诊的要求。(5) 响应厦门市财政局的要求，必须满足博思财务软件接口，以进行博思系统一发票打印等功能。4．2系统功能实现说明按照以病人为索引，以健康档案为核心的患者就诊模型设计如图4．3所示。图4．3患者就诊模型设计流程图4．2．1． 门诊收费管理子系统根据需求分析以后，门诊收费管理子系统设计为如图4．4所示的结构。19社区医疗效劳社区医疗效劳中心信息系统的设计与实现图4．4门诊收费管理子系统功能模型(1)注册：提供为新病人录入信息的功能，需能录入姓名、年龄、电话、费别(自费或医保)等常见病人根本信息，能从医保接口读取医保病人各项根本信息，并回填到本系统中。在本模块中，提供从市民健康信息系统读取病人根本信息的功能，假设是已注册的市民健康信息系统的病人，直接从该系统读取数据，注册到本院系统中。实现的功能界面如图4．5所示。图4．5病人注册第四章系统设计与实现(2)病人信息修改：对于保存过的病人，第四章系统设计与实现(2)病人信息修改：对于保存过的病人，假设合理要求修改信息的，在本模块中进行修改，必填项与注册模块一样。(3)预交金管理：只开放给预交金模式的单位使用，让病人缴交预交金，或退回预交金给病人。实现的功能界面如图4．6所示。图4．6门诊预交金查询(4)挂号：一般社区挂号是不收挂号费的，但对于自费病人，应在本环节收取诊察费。对于现金模式的单位，直接收取现金；而对于预交金模式的单位，直接从病人余额里扣除。实现的功能界面如图4．7所示。2l社区医疗效劳社区医疗效劳中心信息系统的设计与实现图4．7：门诊挂号导航(5)代理开单扣费：对于老专家，不懂计算机的，允许让收款员为他们开处方。功能同医生工作站子系统的“门诊单据扣费〞。(6)退费管理：同医生工作站子系统的“门诊退费管理〞。(7)发票领用：对于使用发票的单位，收款员需设置发票的范围，且必须与实物一模一样。这样，每张发票的使用情况可以通过系统很容易的调出来。(8)发票操作：允许收款员根据病人医保卡或市民健康卡(包括正式与临时卡)或条形码，检索出病人在特定时间范围内的发票结算情况。也可以根据实物的发票号进行检索。提供发票重打(发票未作废，只是没打好，使用同一号码发票重新打印发票)、作废发票(当天结算的，作废后，系统标识该发票号为作废状态)、冲销发票(非当天结算的，冲销时，需要填写一笔负的记录，以相互抵消。系统标识该发票号为冲消状态)等功能。另外，需要为特定用户提供单方面冲销医保的功能。实现的功能界面如图4．8所示。第四章系统设计与实现．曼篾∥。一第四章系统设计与实现．曼篾∥。一 霉爨攀防l矗肇珏群。I，娜-即M¨·彤黝糍翌，擘?●譬掣棚队一剐 且lmi3且■囊枷¨幸T一’B■w啊单一瞄砖薯■■-雌撼糯■t—簟Il●簟量错，捌冉i,11髑t^融毫付臣晨个^怯P童悖墨馕蛹—囊鬟誊崎—蠢鬣P毫骨■曩嚆—薯量聋付：．：：．：i一Ⅱ嗣翻啊誓曲l啊～，*l砸慢t递叠韵抖釜竺：三}黪囊翁蛰鳝女§瓣端蠢，糍雾i缀茹鞭荔螽i蕊j；秘韬毒；囊辔筘甥_，~艄_r蚋秘搬捌臻删塑墅鲤蚓翌苎翻Pn’峨∥譬簟E-_是l—_El_■妻博茸荫詈l～娄。l娟．k．娄8I绷b娄8l蝴。』 锄∞，．1酗I量 3置l擅 钾1降—晴 5目—茹茹—tq馘一∞、，l婴叟二．．1s¨ 鼍曩∞l(9)结算：自动把所有费用进行分类累加计算，并打印在发票上，对于医保病人还应能与医保系统做正确交互，得出病人自付金额。对于现金模式单位，结算后，应能提示收款员需要收病人多少自付金额。结算后还要能自动打印发票，发票内容需符合发票管理要求。结算时，应能与医保系统、博思发票管理系统做正确交互。实现的功能界面如图4．9所示。图4．9门诊结算社区医疗效劳社区医疗效劳中心信息系统的设计与实现(10)退费三合一：所谓三合一，是指将作废(或冲消)发票、退出该退项目的钱、为剩余工程重新结算三个步骤合成一个步骤，只需按钮一按就把这三个步骤依次做完了。(11)病人清单打印：打印病人某次就诊的费用清单，遵循物价局要求的标准格式。对于发票上不能打完明细的情形，可以在此处打印费用清单。(12)门诊收款员结帐：用于对收款员每天收取的金额进行统计，计算出共有多少发票，其中正常为多少张，作废的为多少张，冲销的为多少张，还要计算出收款员应向财务缴交的现金总数。每个结帐单都是从上一次结帐时间点后开始到现在的时间范围内的发票统计，有结帐、上报和作废三个状态。做完本操作并经收款员确认后，状态为结帐状态。实现的功能如图4．10所示。图4．10收款员结账(13)门诊收款员结帐审核：让收款员可以按时间范围查询所有该时间范围内的结帐单。可以对其中的结帐单进行作废操作。作废后，可以重新做结帐，但作废应从最后一张往前作废，不允许对中间时间的结帐单进行作废处理。一旦收款员在本模块进行了上报操作，那么结帐单变为上报状态，上报状态的结帐单不允24第四章系统设计与实现许收款员作废。第四章系统设计与实现许收款员作废。(14)门诊预交金查询：主要是开放给预交金模式的单位操作，用于查询某一病人在某一时间段范围内所有缴交或退回的预交金，以便于有疑问的病人核对。(15)门诊病人担保与欠费审批：对于特殊病人，假设允许其欠费，须在本模块内由有权限的人对该病人进行担保，申请欠费，经特定人员审批后，允许病人不收费看病。(16)其它功能：支持工伤保险结算、商业保险结算、小额支付卡结算。所有功能均需满足各大医院财务管理的要求，同时提供财务及管理部门需要使用的各种报表。4．2．2． 门诊医生工作站门诊医生工作站功能模型如图4．11所示。图4．11门诊医生工作站功能模型(1)挂号：对于要求预交金模式的医院，在医生工作站子系统中应能挂号，并自动扣去病人预交金余额。当一个医生已经接诊时，其他医生不能再接诊同一个号，除非该接诊医生未开任何医嘱(或着开了全删掉后)进行了转诊操作，使该号处于可接诊状态。社区医疗效劳社区医疗效劳中心信息系统的没计与实现(2)开单管理：需提供接诊下医嘱的功能，应能区分西药、中成药、中草药、中颗粒、检查、化验、手术、治疗等所有医嘱分类大类。开单界面应同时能表达病人姓名、病人身份(如医保，自费)、年龄(婴儿应细化到几个月又几天)、病人余额及当前医生等信息。(3) 诊断管理：需能让医生输入主诉、病史、体症、处理意见等信息，同时要能让医生通过计算机下诊断，诊断遵循ICDIO编码，但诊断名称允许修改。但当所输入诊断为传染病时，那么只能从预先设定的传染病列表中选择诊断，不允许手工输入，同时，系统应强制让医生通过计算机书写传染病卡片，书写成功后方能保存诊断。当医生所开工程相关科室尚未执行时，允许修改诊断。诊断也应能提供医生个人常用诊断管理，毕竟有些需要手写的可以通过模板快速定位，免去再次手写诊断的麻烦。(4)模板管理：能让医生对所开医嘱进行分类模板化，如西药类、成药类、草药类等；以便医生能够就类似病例通过模板快速开单。(5)门诊单据扣费：单据特指非药品申请单。根据物价局规定，材料都必须与特定工程绑定，本功能主要是协助处方扣取相关材料费用和治疗费，对于预交金模式，可以在医生站扣取费用，现金模式那么只开单，让收费处扣费。不该扣费的材料，不能以任何形式被用户无绑定地扣费。具体实现的功能界面如图4．12所示。图4．12开单扣费第四章系统设计与实现(6)第四章系统设计与实现(6)门诊退费管理：主要指退非药品单据已经扣收的费用。对于已经执行的工程不允许退费。对于预交金模式单位，假设是可以退费的工程，可以直接把金额加到病人余额上；对于现金模式单位，要医生开单，收费处退回现金或冲到社会保障卡里。具体实现的功能界面如图4．13所示。图4．13门诊退费管理(7)门诊退药开单：退药有三种情况，一种是医生开了处方，但病人未交钱(对于预交金模式就是未扣费)，此时只要在开单模块中把不需要的药品删去，不需要使用本模块功能；二是医生开了处方，病人也已经交了钱，但未拿药；三是医生开了处方，病人也已经交了钱，已经拿到了药。对于后两者，在合理要求的情况下，系统应通过本模块允许病人退药。具体实现的功能界面如图4．14所示。社区医疗效劳社区医疗效劳中心信息系统的设计与实现图4．14门诊退药开单(8)社区保健功能：做好糖尿病、发热病及高血压病的记录。要求诊断为发热的需要填写体温；诊断为高血压病的需要填写血压。(9)双向转诊：需实现医院与社区，社区与医院的双向转诊，实现在全市范围进行不同社区与不同医院之间的双向转诊。转诊的接口标准和数据共享通过市民健康系统三期建设的转诊平台交换。具体实现的功能界面如图4．15所示。图4．15接诊导航窗口28第四章系统设计与实现(10)其它要求：以上所有模块需满足各社区在医务管理上的功能要求，第四章系统设计与实现(10)其它要求：以上所有模块需满足各社区在医务管理上的功能要求，并提供医疗统计的各种报表。(11)门诊诊断、检查检验结果、用药情况、医嘱等诊治信息能稍后自动导入社区健康档案系统。 (重点是60岁以上老年人，慢性病患者)。4．2．3． 门诊医技管理系统门诊医技管理系统设计为如图4．16所示的结构。图4．16门诊医技管理系统功能模型(1) 病人单据查询：用于查询病人所开单据的情况。具体的实现的功能界面如图4．17所示。图4．17门诊医技单据导航社区医疗效劳社区医疗效劳中心信息系统的设计与实现(2) 单据的执行。(3) 门诊退费：对于本科室所开单据且以扣费的，提供退费功能。(4)结果登记与查询：调阅检查、化验结果，填写结果，并能提供灵活的查询方式。(5) 其它要求：以上所有功能满足财务及医技管理要求。4．2．4． 药房管理系统药房管理系统设计为如图4．18所示的结构。图4．18门诊药房管理系统功能模型(1)门诊配药：病人在已经缴交费用的情况下，到门诊药房拿药，通过病人的病历卡号(条形码)或社会保障卡或市民健康卡，把病人已经缴完费用的药品自动摆出来，让药房工作人员进行配药。门诊配药界面中不能表达开单医生，但打印出来的处方纸(假设有的话)那么需表达开单医生。具体实现的功能界面如图4．19所示。第四章系统设计与实现图4．19门诊发药第四章系统设计与实现图4．19门诊发药(2)处方重制：对于已经配药过的病人，有时因打印机问题打出来的处方不清楚或有缺陷，那么通过本模块进行重新打印。提供读卡功能及时间段范围。处方重制显示界面中不能表达开单医生，但打印出来的处方纸(假设有的话)那么需表达开单医生。具体实现的功能界面如图4．20所示。图4．20门诊处方重置3l社区医疗效劳社区医疗效劳中心信息系统的设计与实现(3) 退药开单：有时医生不在，在医生同意的情况下，替医生开单退药。(4) 退药入库：对退药开单的单据进行入库处理，改变该药品的库存量。(5)药名字典维护：由于同一药品既有化学名，又有商用名等等，所以需在本模块中将同一药品的不同药名进行关联。自动生成拼音首码、五笔首码。所有修改均应保存痕迹。(6)药品字典维护：对药品根本信息进行维护，需符合各大医院在药品信息上分类的要求，进行药品医保工程对照。自动生成拼音首码、五笔首码。非新增的药品，所有修改均应保存痕迹。(7)药品库存查询：提供药品库存一览表，可以根据多种条件过滤，如药品名称，药品代码，最少用药品等。(8)出入库导航：提供药品出入库操作界面。分为开单、审核、上账三个状态。在未上账情况下，允许回退，这主要是考虑到仓管员与药品会计别离。上账时，也就是修改库存的同时，不允许再回退。在本模块也应能查询某一时间段内所有出入库的情况。具体实现的功能界面如图4．2l所示。塑翌1．兰蹩曼墅l黧蹩鲎l兰：堡翌兰：l。鍪兰：二I．茎翌坚：：．：j图4．21出入库导航第四章系统设计与实现(9)第四章系统设计与实现(9)帐页查询：主要是对出入库(已上账)的记录进行查询，在本模块中，要表达每一次上账后的结存数。本模块不能表达开单医生。提供多种复合查询方式。具体实现的功能界面如图4．22所示。图4．22帐页查询(10)调零售价管理：允许对库存中的某一药品的某一批次进行零售价调价，或对该药品全部批次都调价，调价后，自动计算盘盈、亏出零售价出入库并上账。(11)调进货价管理：允许对库存中的某一药品的某一批次进行进货价调价，或对该药品全部批次都调价，调价后，自动计算盘盈、亏出进货价出入库并上账。(12)盘点管理：分为：新开盘点单，录入实点数，盘点冲正及盘点单查询四大局部功能，要求表达药品不同批次的先进先出原那么。具体实现的功能界面如图4．23所示。33社区医疗效劳社区医疗效劳中心信息系统的设计与实现图4．23盘点管理(13)库存干预：有时候，由于系统原因，某医生为病人开了某一批次的药，病人也交了钱，但到药房确发现该批次的药品已经没有库存了，此时，需要药剂管理人员对该药品的库存进行干预。(14)结存管理：主要表达期初、期中与期末的关系，为财务审计提供数据。(15)效期管理：方便用户查询实效药品，并根据药剂管理要求进行处理。(16)限量管理：方便用户查询超出限量管理要求的药品，以便生成采购方案单，控制库存量。(17)报表管理：提供用户要求的各种报表。(18)其它要求：所有功能均需满足各大医院在药剂管理上的功能要求，并提供财务与药剂管理需要的各种报表，假设有打印处方，那么需符合国家处方管理规定。4．2．5． 临床检验管理系统临床检验管理系统设计为如图4．24所示的结构。第四章系统设计与实现图4．24临床检验管理系统功能模型第四章系统设计与实现图4．24临床检验管理系统功能模型(1) 检验标本接收：主要是将医生站开出的并已经打印条码检验工程标本进行集中接收的操作。(2) 检验结果工程录入和审核：主要是将仪器发送或者手工工程的录入、审核结果。具体实现的功能界面如图4．25所示。图4．25检验结构工程录入35社区医疗效劳社区医疗效劳中心信息系统的设计与实现(3) 检验报告打印：用于打印己审核的检验结果报告。具体实现的功能界面如图4．26所示。图4．26检验报告打印(4) 检验工程的维护：主要是将检验工程的对照、维护以及结果工程的维护操作。(5) 检验接口端程序：通过串口、Socket、数据库、文件级交互的方式，进行检验程序与检验仪器的对接。4．2．6． 报表管理子系统报表管理子系统设计为如图4．27所示的结构。第四章系统设计与实现图4．27报表管理子系统功能模型第四章系统设计与实现图4．27报表管理子系统功能模型(1) 要求能够让用户自定义报表，并能集成到系统中来。(2) 要求对报表的权限功能进行按各种条件和情况的分发和控制。427 系统管理工具系统管理工具设计为如图4．28所示的结构。图4．28系统管理工具功能模型(1) 员工人事信息管理：对本单位员工进行根本信息维护，应符合人事管理的要求。对于有些单位，还应能表达员工所属的医疗小组。社区医疗效劳社区医疗效劳中心信息系统的设计与实现(2)员工业务权限设置：分发普通处方权，特殊处方权，分发代理权限，分发挂号权限。应满足单位业务权限控制上的需要。(3)用户管理：用于创立数据库用户，分发数据库操作权限角色，修改数据库操作权限。应符合数据管理在平安上的要求。(4)科室维护：对于不同业务功能的科室能进行分类维护。分发子系统权限，即什么部门能用什么子系统。(5)子系统管理：对各系统的权限如菜单进行默认分发维护，进行版本控制，自动升级管理。(6)角色管理：角色，就是权限的集合，有的角色只能使用某一子系统，有的角色却需要能够使用多个子系统。本模块对权限进行分类管理。(7) 在线用户死锁监测：让系统管理员及时发现死锁并进行处理。(8) 其它要求：所有修改均应保存痕迹，所有功能符合系统管理要求。4．2．8． 社区公共卫生和保健系统社区公共卫生和保健系统设计为如图4．29所示的结构。图4．29社区公共卫生和保健系统功能模型(1)居民健康档案管理：用来管理和记录社区调查得到居民的健康档案，包括根本信息、根本健康情况、居住条件、生活条件、经济状况等，记录和跟踪居民的所有的健康问题。具体实现的界面功能如图4．30所示。第四章系统设计与实现图4．30个人健康档案管理第四章系统设计与实现图4．30个人健康档案管理(2)家庭档案：用来管理家庭情况，包括家庭的建立、家庭成员的组成、迁移，记录社区调查得到的居民家庭档案情况等。具体实现的界面功能如图4．31所示。图4．31家庭健康档案管理社区医疗效劳社区医疗效劳中心信息系统的设计与实现(3)慢病管理：专门用来管理居民的慢性病问题。慢性病主要包括高血压、糖尿病、脑血管、冠心病、恶性肿瘤、慢阻肺。通过本功能可以对各种慢性病进行专案管理及流程跟踪。(4) 残疾管理：专门用来管理居民的残疾问题。残疾主要包括视力残、听力残、言语残、智力残、肢体残、精神残。通过本功能可以对各种残疾进行专案管理及流程跟踪。(5) 五病管理：专门用来管理儿童的五病问题。五病主要包括佝偻病、营养性缺铁性贫血、营养不良、肺炎、腹泻。通过本功能可以对各种儿童疾病进行专案管理及流程跟踪。(6)婚前保健：妇幼保健信息系统的组成局部。婚前检查主要是用来记录人在婚前进行的体检信息，主要有女性婚前检查和男性婚前检查，本系统提供对婚检数据的分析功能。本系统婚前检查功能符合?婚前检查功能标准?。主要有婚前检查证明登记、婚前检查记录登记等功能。由于涉及的法律敏感信息，一般要求人在做婚检的时候先签字后再进行，之后登记到系统。(7)方案生育：妇幼保健信息系统的组成局部。计生主要是用来记录节育手术及异常∥。本系统提供对婚检数据的分析功能。本系统计生功能符合?计划生育节育手术功能标准?。主要有节育手术及异常情况登记，节育手术随访等功能。(8)死亡登记：用来登记居民死亡的信息，包括死亡诊断及死因等。通过本功能标记居民的死亡状态，所登记的死亡信息和死亡医学证明一致。(9)统计报表与工作量统计：主要用来统计居民健康问题(高血压、糖尿病、残疾等)、出生信息、死亡信息、孕产妇保健情况、儿童保健情况，依据不同统计范围、所属区域、性别、年龄、问题分类、健康问题等统计指标，得出相关的统计报表。同时也可以针对各个机构的不同针对各个机构自己的相关数据、工作情况、居民建档情况进行统计分析。具体实现的功能界面如图4．32所示。第四章系统设计与实现l嬲■!■开莉ij萌谶蠢函潮“毒0第四章系统设计与实现l嬲■!■开莉ij萌谶蠢函潮“毒0iir～～～——～——]l瑚—一蕊妊越面瞳叠_～’蜀羽麟·一ob嘲搠盯兰三三三三三三三三：：兰兰三三三兰兰兰三兰三兰兰===麓========================l嘲睫鲁耋醚：一二国帮照二叠皈!璺堕二二．酒鼬≥鳓匿二爱-张匕]l翻明∞¨q啷强一撕i前面溺濑翳鲤凌燮夔悠麟麴嬲嬲燃鲤麟魈豳嬲濂黝摹，m墨唰疆姗舅∞口删¨舅 l，，铲I卜l·乃 筲笃榭●弄■—t奠n再∞艄曼允耵t柏2协H’·14穗黝孙-瞻葛∞暖哪．勇蕾∞姗童 l∞t-●-一躺砌n市鬻o●2冀舭章，12监!t帆卜卜3镌自绷■一R■针。啪●-写啪■lloI土∞ll·T畸0■田_谴长■●羹鲁4‘●口●埔，嘲I■兵置】ot柏If绷I-T-3麓燃饿抽-¨ltl篮I冀∞均-'·∞舅薯墨奠■鼍七l蠢曩ml囊-％●l∞矬●虎●，12茁彻l-f-3麟㈣纛室一蔓蝴l·玎。驾嘲删J勇彻L-T-$矗茸薯t童n币钾AYr．Mi瞅踟I．T·'糍燃^岛奠M暨，，∞皇：㈦’舢i毫曩广】市锄嘲舯量圮覃，l碰∞〞一f一，凝霸麟i黝燃缀麟麟图4．32综合查询4．3接口设计与实现4．3．1． 市民健康接口厦门市民健康信息系统是厦门市所有医疗公共卫生数据中心，它的数据通过各医院、社区等医疗机构进行采集或调用，数据收集接口采用WcbScrvicc接口标准制定，采用WSDL格式发布，客户端通过WEB地址获取。具体调用基于卫生系统VPN网络【2l】。市民健康对社区开放的接口包括以下内容：(1) 构造临时保障卡号：系统对于没有市民卡的人员分配临时保障号，临时保障号由市民健康信息系统统一核发，具有唯一标识特性，用于临时市民保障卡写卡。(2) 更改市民保障卡号(包括取消、挂失卡号)：如果正式的市民卡要关联原来保障卡的健康信息，必须进行一次转换，系统将自动关联原来的市民健康41社区医疗效劳社区医疗效劳中心信息系统的设计与实现信息。(3)新注册市民：在市民卡发卡机构客户端新注册市民时必须向卫生局数据中心登记，只有登记的市民卡才可以在其他医疗机构就诊时使用。(4) 查找市民：根据条件查找已经存在的市民。(5)修改市民信息：市民根本信息有可能变更(例如：婴儿在注册时无法提供正式姓名和身份证号)，所以提供修改根本信息接口。除此之外临时市民卡转换为正式市民卡时也需要修改信息的功能。(6) 健康信息提交接口：用于市民健康信息提交数据。(7) 获取市民根本信息：用于获取市民健康根本信息。(8) 双向转诊接口：用于社区、医院之间进行病人转诊操作的接口。现举例如何实现获取病人的市民健康信息。实现接口函数为：stringGetBaseInfo(stringstrSSID，stringstrCredential，strKey)；参数：strSSID：市民卡号strCredential：身份标识，市民或系统用户strKey：对称钥匙加密、编码：RSA+卫生局公钥加密；ENCODE编码返回：成功：返回XML格式的市民根本信息<?xmlversion=〞1．0〞?><rootversion=〞1．0．0000．0〞><guid>市民健康系统分配唯一市民ID号<／guid><ssid>市民卡<／ssid><name>姓名<／name>code=一性别代码〞>性别<／sex><birthday>出生日期<／birthday><nationcodeffi〞民族代码〞>民族<／nation><idno>身份证号<lidno><native>籍贯<／native><address>住址<／address>42第四章系统设计与实现<post>邮编<／post>第四章系统设计与实现<post>邮编<／post><telphone>联系电话<／telphone><photo>不再返回照片信息，该节点总；捌F<Iphoto><workcode=〞职业代码〞>职业名称<／work><email>邮箱地址<lemail><notes>备注<／notes><archive>是否授权：0不授权归档，l授权归档<／archive><pwdstatus>密码是否设置过：0未设置过，1设置过<／pwdstatus><question>取回密码的问题<／question><extend／><／root>压缩、加密、编码：返回信息压缩后采用传入的DESKey加密，然后ENCODE编码。4．3．2． 医保接口(含农保)医保接口采用文本文件交换信息的方式，每个业务接口主要步骤均为：医院程序删除应答文件(如果存在)，提交一个请求文件，医保程序检测到后自动解释，生成一个答复文件，并删除原来的请求文件，医院程序检测到应答文件生成后就去读取医保程序返回的信息。文件的结构主要借鉴Windows系统通用的信息文件格式(事．ini)。为平安起见，每一个涉及收费的接口均需校验卡号。为方便起见，对交换文件不进行加密处理，采用文本文件。实达接口的主要内容包括：(1)下载内容及处理：实时或定时的从上级医保部门下载更新的药品目录、诊疗目录、效劳设施目录、黑名单、各种政策参数、政策审核函数、医疗保险结算表、医疗保险拒付明细、对帐单等，并根据政策要求对药品目录、诊疗目录、效劳设旌目录、黑名单进行维护。(2) 上传内容及处理：实时或定时向上级医保部门上传。a．门诊挂号信息、门诊处方详细信息、门诊诊疗详细信息、门诊个人帐户、支付明细等信息。b．住院医嘱、住院首页信息、住院个人帐户支付明细、基金支付明细、现43社区医疗效劳社区医疗效劳中心信息系统的设计与实现金支付明细等信息。c．退费信息：包括本次退费信息，原费用信息、退费金额等信息。d．结算汇总信息：按医疗保险政策规定的分类标准进行分类汇总。(3) 医疗保险病人费用处理：a．根据下载的政策参数、政策审核函数对医保病人进行身份确认，医保待遇资格判断。b．对医疗费用进行费用划分，个人帐户支付、基金支付、现金支付确认，扣减个人帐户，打印结算单据。c．根据医疗保险指定格式完成对上述信息的上传。(4) 在医院信息系统中保存各医疗保险病人划分并支付后的费用明细清单和结算汇总清单。(5) 医疗保险接口系统维护：a．对下载的药品目录与医院信息系统中的药品字典的对照维护。b．对下载的诊疗目录与医院信息系统各有关工程的对照维护。c．对下载的医疗效劳设施与医院信息系统中各有关工程的对照维护。d．对医疗保险费用汇总类别与医院信息系统中费用汇总类别的对照维护。e．对疾病分类代码的对照维护。实达医保接口的实现方式与原来省医保或地方医保的接口实现方式相同。接口采用文本文件交换信息的方式，每个业务接口主要步骤均为：医院程序删除应答文件(如果存在)，提交一个请求文件，医保程序检测到后自动解释，生成一个答复文件，并删除原来的请求文件，医院程序检测到应答文件生成后就去读取医保程序返回的信息瞄1。文件的结构主要借鉴Windows系统通用的信息文件格式(木．ini)。为平安起见，每一个涉及收费的接口均需校验卡号。为方便起见，对交换文件不进行加密处理，采用文本文件。请求文件名为：request．txt；接口返回的文件名为：reply．txt。该接口文件目录必须指定文件夹，如：“医院接口＼sfjk＼"。在实现接口的过程需要注意以下几个考前须知：(1) 发出请求前，应当删除应答文件，否那么医保程序将不会响应请求文第四章系统设计与实现件。第四章系统设计与实现件。(2) 发出请求文件时，填写request字段的内容应填写完参数后进行；注意： 无论读或写，务必采用独占方式(LOCKREADWRITE!)翻开文件。(3) 检测应答文件时，应当等到应答文件的reply=TRUE时，方可进行读取工作。(4) 读应答文件时，可以和发送的信息进行一些简单的校验(例如接口发送和接收的处方数目、明细、总金额等是否一致等)，保证程序正确运行。请求文件和应答文件的中英文字段说明如下表所示，其中C代表字符类型N代表数值类型例如N5，2代表取值0．00到999．99。实达医保接口数据字段说明参见下表4．1：表4．i实达医保接口数据规格说明022l字段 类型，位数或取值范围 字段意义Bcbxf0 N8，2 总费用Bckbcs N3 本次看病次数(即视同住院次数)Bndjyy Varchar(400) 当事人不能入院登记原因Bnghyy Varchar(400) 病人不能挂号原因Bqbm00 C20 病情编码Bml00 N3 年龄CfxmsO N3 处方工程数Cardno c12 医保IC卡号CxdjhO C16 冲销单据号Cxlsh0 C16 冲销流水号Cydjr0 C8 出院登记人Cyrq00 C8 出院日期CysjOO CA 出院时间Dbgrzf N8，2 大病个人支付(超支段费用)45社区医疗效劳社区医疗效劳中心信息系统的设计与实现Dbjjzf N8，2 大病基金支付Dbzhzf N8，2 大病帐户支付OjIsh0 C16 单据流水号Dqmc00 C20 投保人所属地区名称Dwmc00 c30 单位名称Error Varchar(400) 操作结果成功否Fzxmc0 C20 投保人所属分中心名称第四章系统设计与实现续表4．1第四章系统设计与实现续表4．1字段 类型／位数或取值范围 字段意义Ghfy00 N5，2 挂号费用Ghksmc C10 挂号科室名称Ghlsh0 C16 挂号流水号Ghfq00 C8 挂号日期Ghsj00 C4 挂号时间Grzfe0 N8，2 个人现金支付额Grzhye N8，2 个人账户余额Gzztmc C30 工作状态名称Icztmc C20 IC卡状态名称Id0000 c19 医疗保险号Jjzfe0 N8，2 基金支付额Mzlsh0 C16 门诊流水号NdfylJ N8，2 年度医保费用累计Reply trueor铆se 各种业务接口请求文件的开始请求标志Rydjr0 C8 入院登记人Ryksmc ClO 入院科室名称Rylb00 C8 住院类别‘普通’或‘家庭病床’Ryrq00 C8 入院日期Rysj00 CA 入院时间S台qOO C8 收费日期Sfixrn0 C8 收费人姓名Sfsj00 C4 收费时间Sftsbz Cl YorN 是否特殊病种Sttsmz C1 YorN 是否特殊门诊Success trueorfalse 答复标志社区医疗效劳社区医疗效劳中心信息系统的设计与实现续表4．1字段 类型，位数或取值范围 字段意义V甜id0 trueorfalse 是否可以入院登记或是是否可以挂号Xbie00 cl 性别 1男2女9未说明性别Xmin90 e8 姓名Zhzfe0 N8，2 帐户支付额Zyksmc ClO 住院科室名称Zylsh0 C16 入院登记流水号?处方明细信息?中医院收费工程在一C20 医保中心的编号C1YOrN