基于全民健康档案管理的社区医疗数字化诊疗系统开发文档.docx

优质文本基于全民(quánmín)健康档案管理的社区医疗数字化诊疗系统技术开发文档成都金洋高新技术开发目 录1.引言(ynyán)31.1 定义31.2 编写目的31.3 工程背景31.4 参考文献42、技术架构42.1开发语言42.2运行环境52.3开发目的52.4网络拓扑图62.5数据库63.功能模块73.1 通用管理73.1.1 平台主窗体界面73.1.2 平台登陆模块83.1.3 最习惯的汉字输入法93.1.4 修改密码103.2 卫生局总控113.2.1 卫生机构管理113.2.2 系统数据字典143.3.3 角色定义153.3.4 权限定义163.2.5 统一药品目录管理173.2.6 菜单设置193.3 医疗机构总控203.3.1 机构科室213.3.2 职工223.3.3 人员角色定义233.3.4 机构药品设置243.4 (中、西)药库管理253.4.1 库房业务配置263.4.2 药品入库业务283.4.3 药品出库业务303.4.4 药品采购方案323.5 (中、西)药房管理343.5.1 药品划价343.5.2 药品请领353.6 门诊挂号363.6.1 门诊专家设置363.6.2 门诊挂号373.7 门诊收费393.7.1 门诊收费393.7.2 门诊退费业务423.7.3 门诊药房发药业务433.7.4 门诊药房退药业务441.引言(ynyán)1.1 定义金洋基于全民健康档案管理的社区医疗数字化诊疗系统软件以下简称是由金洋软件公司医疗卫生事业部开发的，应用于地市级或区县级卫生局，对其下属公立医院主要是乡镇级卫生院及社区医院进行医院管理、业务监督、数据统计、数据上报等一系列业务的数字化集中管理平台。1.2 编写目的本文编写的目的主要是对基于全民健康档案管理的社区医疗数字化诊疗系统V5内部版本V1中包含的17个大类中的子模块功能性需求的描述，按照适用对象、需求描述、业务逻辑流程、输入输出项四类来分析每个子模块的需求，最终到达的目的是开发人员可以通过阅读本文，对于基于全民健康档案管理的社区医疗数字化诊疗系统开发的过程有个较为清晰的认识，明确开发目的，从而理清整个开发思路。1.3 工程背景2016年4月?党中央、国务院关于深化医药卫生体制改革的意见?正式公布，确立了建立中国特色的医药卫生体制，逐步实现人人享有根本医疗卫生效劳，提高全民健康水平的医药卫生体制改革目标，首次将信息化确定为支撑医疗卫生体制改革四梁八柱的支柱之一。今后3年的5项重点任务包括加快推进城乡根本医疗保障制度建设，初步建立根本药物制度，健全城乡根底医疗效劳体系，促进根本公共卫生效劳均等化和公立医院改革试点。乡镇级医院是我国数量最多，涉及面最广的医疗效劳机构，随着国家新型农村医疗体系的建立，每个村卫生所、中心卫生院、社区卫生院担负着根底医疗与公共卫生效劳的任务，国家对这些医疗机构的投入逐步增加，公益性特点明显，卫生行政管理部门的管理也随之需要加强，如人才培养、药品统一配送、设备与材料的管理等。随照信息技术的开展，构建区域化的卫生信息管理平台能有效解决这些问题，能有力支持卫生事业的改革与开展。当前卫生系统的现状是：上级卫生主管部门不能实时监管村乡两级医疗机构经营及资金使用情况；局部乡镇卫生院因收入有限，也没有实施医院管理信息系统的费用，信息化利用水平低。现在局部新型农村合作医疗在乡卫生院全靠手工完成，无法及时为参保农民报销结算，人员工作量大且受人为因素影响容易出错。随着新农村医疗合作制度的广泛推行，这一矛盾正变得越来越突出。而在村卫生所一级，那么更没有计算机信息管理，新型农村合作医疗的下一步开展也要求村卫生所是医疗保险政策推行的难点之一。乡镇卫生院、村卫生所由于没有实施计算机管理，药品销售与诊疗效劳工程无法实现管理，药品包括耗材质量和进药渠道不能有效监管，群众用药平安存在隐患;效劳工程以及(yjí)收费工程也没有统一的监管，这些单位在纳入公共卫生体系以后，必须提高管理水平，才能有效为基层百姓提供高质量的医疗效劳。工程名称：是由成都金洋高新技术开发组织研发的金洋区域卫生平台的重要组成局部。先期主要用于县或者地级市下属医疗机构除地级人民医院、县级人民医院、私立医院之外的卫生信息化整合，后期参加临床管理、医学影像管理、电子病历等模块后，将涵盖所有公立医疗机构。1.4 参考文献卫生部?医院信息系统根本功能标准?02版;7 7中文版卫生部?中国医院信息根本数据集标准1.0 版?卫生部?基于健康档案的区域卫生信息平台建设技术解决方案?0912版2、技术架构2.1开发语言本产品采用目前主流的做为开发语言；采用 架构；效劳器端采用了、等技术框架；客户端采用；源码管理采用；数据交换格式采用国际通用的文档格式；数据交换效劳采用方式；消息传输技术标准采用方式；：效劳器端采用，客户端采用；2.2运行环境Ø 软件运行环境效劳端运行环境：目前产品支持主流的企业级操作系统环境、；应用效劳器支持、等主流中间件；客户端运行环境：支持系列产品、2003、7，虚拟机： 6.0；Ø 硬件运行环境客户端硬件(yìn jiàn)环境：支持目前主流配置普通，显示器最少支持1024×768分辨率效劳端硬件环境：主要支持x86架构效劳器2.3开发目的金洋基于全民健康档案管理的社区医疗数字化诊疗系统，应用于地市级或区县级卫生局，对其下属公立医院主要是乡镇级卫生院及社区医院进行医院管理、业务监督、数据统计、数据上报等一系列业务的数字化集中管理平台。通过建立区域医疗卫生效劳协同信息共享平台，实现医疗机构之间的数据交换和共享，满足卫生行政管理部门、区域内各级医疗机构之间以及病人对医疗业务活动数据的需求，由此实现政府部门对医疗活动的有效监管，医疗机构对病人医疗历史数据的快速有效的利用，以及病人对自身治疗情况的有效把握。最终促进区域医疗活动更加有序，医疗效劳水平不断提高，病人看病难看病贵问题得到缓解。2.4网络拓扑图2.5数据库本产品(chnpn)支持910g11g3.功能模块3.1 通用管理 图2.13.1.1 平台主窗体界面适用对象 所有基于全民健康档案管理的社区医疗数字化诊疗系统用户，按照不同的角色权限，可能显示不同的功能菜单。描述 平台用户需要一个直观的界面来完成对软件的操作，对于平台而言，优秀的界面可以影响客户对我们产品的第一印象。所以在设计方面一定要做到贴近主题、直观、友好。 建议(jiànyì)设计成标准风格，左侧树状导航菜单显示功能模块菜单，允许换肤，下方状态栏记录登录信息。允许以分栏选项卡方式激活多个模块。导航菜单模块插件式动态生成，支持拖曳。业务逻辑流程参看图3.1输入输出项功能描述输入输出备注角色切换用户；机构；返回值；返回信息；用户角色科室对象集合科室、角色用户可以在界面中完成自身角色的切换，以得到其它的权限，实现其它的功能。权限获取机构；角色；返回值；返回信息；权限对象集合权限根据用户选择角色的号，取得其相应的权限集合。可用机构获取用户；返回值；返回信息；机构对象集合(机构、机构名称、机构简称)根据用户的号，取得其可以访问的机构或机构集合可用菜单获取角色返回值；返回信息；菜单对象列表取指定角色能够使用的菜单3.1.2 平台登陆模块适用对象 所有基于全民健康档案管理的社区医疗数字化诊疗系统用户，按照不同的角色权限，可能加载不同业务数据。描述 用户需要输入登陆账号和密码才能进入平台，同时，在登陆平台前也可以做一些设置工作，比方：对应用效劳器的选择；对登录密码的修改等等；为了减少平台交易中的数据往返造成的流量，所以在平台登陆时会下载一些本院静态或者变动不大的数据到客户端内存中，使得使用这局部数据时，不用频繁地进行网络调用。 用户(yònghù)翻开平台客户端程序时，自动根据网络情况选择登陆网络线路，可以弹出登陆界面，密码输入三次错误，那么退出平台。操作员登陆时，进度条显示加载本院人员、科室、数据字典、本院诊疗工程目录、本院诊断目录等根底信息，登陆后，其权限范围将影响其操作模块的可视性以及模块内部操作的可行性。没有任何权限的用户，只要密码正确也可以登录平台，不过其所有模块菜单皆不可见.业务逻辑流程参看图3.1输入输出项功能描述输入输出备注可用效劳器获取返回值；返回信息；可用地址对象集合可用地址，是否默认地址从配置文件中读取当前区域可用效劳器列表由工程实施人员发布连接效劳器效劳器地址返回值；返回信息；根据效劳器地址选择连接登陆用户代码；密码；返回值；返回信息；用户对象用户；用户姓名；所属机构；默认角色；默认科室；通过输入用户名和密码，登陆平台加载静态数据用户角色返回值；返回信息；角色对象包含权限；可登录菜单；业务数据对象机构科室对象；机构职工对象；机构诊疗目录对象；机构诊断目录对象；机构病床对象等根据用户角色，登陆时加载其业务所需的静态数据对象 3.1.3 最习惯的汉字输入法适用对象面向业务操作层面需要大量中文输入的用户门诊收费员、入院处工作人员、病案管理人员、人力资源管理员等。描述用户在一些需要快速输入中文的模块中，往往希望一切换到需要输入中文的组件时，能够自动转换成自己最熟悉的中文输入法。可以在模块中对此进行定义习惯汉字输入法，习惯的汉字输入法不需要保存在数据库效劳器中，可以放在配置文件中。业务逻辑流程参看图3.1输入输出项功能描述输入输出备注可用输入法获取返回值；返回信息；可用输入法对象集合从操作系统中获取所有可用的中文输入法设置输入法输入法对象返回值；返回信息；选择习惯使用的输入法，写入到配置文件中去3.1.4 修改(xigi)密码适用对象所有基于全民健康档案管理的社区医疗数字化诊疗系统用户。描述密码是每个用户进入平台的钥匙，会影响整个平安的平安性，所以必须严格管理，特别是拥有高级权限的用户，可能会定期修改自己的密码，以确保不会被破解或者他人盗用。(以后可以消息系统中提示修改密码)。用户可以在登录平台后，在相应的模块中修改密码。业务逻辑流程参看图3.1输入输出项功能描述输入输出备注修改密码用户代码；旧密码；新密码返回值；返回信息； 将用户名，旧密码，新密码进行验证，并且修改用户登陆密码3.2 卫生局总控 图3.23.2.1 卫生机构管理(gunl)适用对象卫生局全局系统管理员；具有下级分支机构且具有管理能力的医院系统管理员。描述 图3.3基于全民健康档案管理的社区(shè q)医疗数字化诊疗系统的使用群体为地级市或县级卫生局，及其下属公立医院。卫生局对于医院具有监督管理的权责，所以在平台设计时必须要有个层次关系。地级市县级人民医院有时候不直接被当地卫生局监管，而是由上一级卫生部门管理，所以在软件表达时，可以以同级类别不同的类型和当地卫生局并存。而医院自身也可能充当下级医院的管理角色，如某些地方的大型医院对当地的乡镇卫生院进行托管。卫生机构的设置会影响用户的权限作用范围。举例1：同样一个统计模块中的统计权限，某医院在模块中只能统计出本院的情况；而上级机构可以查询出其下属所有医院的情况。举例2:权限、允许所有的机构分医院类或卫生局类进行设置，但某医院的人员设置权限只对本院有效，不会影响到其它医院，而其上级机构除了可以设置本机构内的人员权限之外，还可以辅助其下属机构设置权限。卫生机构可以设置本机构的一些政策性参数，以控制本机构的平台用户的使用，而其参数很可能还会影响到下属机构的运行，下属机构自身又允许设置其运行参数，这时候与上级参数不匹配时，可以通过一个优先权参数判断其优先执行哪个。关于系统管理员全局漫游的必要性及实现建议：首先，我们应该明确的是集中根底并不是一种纯粹意义上的免维护平台。它和传统有相似之处，就是由于操作流程复杂，以及平台自身不断升级完善，所以可能会导致用户的使用的过程中经常需要人员维护的现象。其次，基于全民健康档案管理的社区医疗数字化诊疗系统面向的是数十家医疗机构，而并非传统中单个医疗机构，只需要一个系统管理员帐号就可以维护整个医院。频繁地建立多个维护帐号不利于管理，也容易造成平安隐患。再那么，我们的基于全民健康档案管理的社区医疗数字化诊疗系统的效劳对象是卫生局，而非医疗机构，因此用医院帐号管理起不到真正监管的目的。最后，我们面前的医院用户中，往往因为人员素质问题，缺乏计算机专业人才，无法胜任系统管理的角色。因此，必须(bìx)建立一个卫生局掌控的，可以对其下属医疗机构进行漫游管理监督维护的系统管理员帐号。建立卫生局全局系统管理员以下简称超级用户在开发上会存在着一些问题，该角色不同于一般的医院用户，它拥有进入该卫生局下属所有医院的权限，而我们在登陆模块设计时，会加载本院的很多根底数据信息，如果超级用户加载所有医院的根底数据信息的话，那么可能会造成网络堵塞，速度缓慢。况且，并非超级用户每次进系统都会漫游，所以建议把登陆平台加载的数据设计成一个以每个医院为对象的数组，漫游到该医院时，系统进行判断，该医院是否加载过根底数据，如果有，那么跳过加载流程，直接进入平台，如果没有，那么加载该医院的根底数据。描述区域内卫生机构的相关信息，可以新建、修改、取消，并且可以配置不同的参数将会影响区域化参数表；左侧树状导航分级查询各机构信息，右边可以对其明细内容进行编辑修改。树状导航栏中，类型不同的结点通过不同的图标来区分，这样用户可以直观清晰地区分哪些是卫生局直属局部，哪些是市级医疗机构、县级医疗机构、乡镇卫生院甚至村卫生室。卫生机构可以设置优先权，以实现对各自分管单位的掌控。机构在平台中是允许切换的，前提有两个：一、操作用户所在单位具有下级机构；二、操作用户具备切换到下级机构的权限。业务逻辑流程参看图3.3输入输出项功能描述输入输出备注卫生机构列表用户；返回值；返回信息；卫生机构对象集合根据操作用户获取其可控的机构列表添加卫生机构用户；类别同级目录或下级目录；医疗机构对象或集合返回值；返回信息；添加操作用户允许范围内的机构信息，支持批量添加变更医疗机构角色；卫生机构对象返回值；返回信息；变更已经产生的机构中的信息机构迁移角色；旧上级机构；新上级机构；卫生机构对象或集合返回值；返回信息；变更机构归属关系机构停用角色；卫生机构对象返回值；返回信息；将指定机构设置为不可用状态机构删除角色；卫生机构对象返回值；返回信息；新建机构在没有使用的情况下，如果出现错误，允许删除。3.2.2 系统数据(shùjù)字典适用对象卫生局全局系统管理员。 描述平台需要使用的大量的数据字典，其中包含有卫生部官方文件中命名的标准，也包含实际使用过程中可能需要的一些数据集。如果建多表描述的话，不利于维护，而其中很多表结构都是有同性的。数据字典界面上呈树状展开，通过父结点可以查询其子集，并且允许向下扩展多级子集，对只读属性的结点及子集不允许变更，对非只读属性的结点及子集允许进行添加、修改和删除，并且允许通过鼠标拖曳改变数据集归属关系。系统中用的数据集通过数据分类的方式以视图获取。业务逻辑流程作为公用数据集合，应用于绝大多数业务模块中。输入输出项功能描述输入输出备注系统数据字典列表角色；返回值；返回信息；系统数据字典对象集合获取系统数据字典对象列表新增根结点角色；系统数据字典对象或集合返回值；返回信息；添加角色允许范围内的机构信息，支持批量添加变更医疗机构角色；卫生机构对象返回值；返回信息；变更已经产生的机构中的信息机构迁移角色；旧上级机构；新上级机构；卫生机构对象或集合返回值；返回信息；变更机构归属关系机构停用角色；卫生机构对象返回值；返回信息；将指定机构设置为不可用状态机构删除角色；卫生机构对象返回值；返回信息；新建机构在没有使用的情况下，如果出现错误，允许删除。3.3.3 角色(jué sè)定义适用对象卫生局全局系统管理员角色定义、角色分配；医疗机构系统管理员角色分配 描述平台涉及到的用户可能多达上千人，同时涉及到的模块权限可能也会有上百个之多，如果每个人都单独配置权限，那么一方面工作量繁重，另外一方面也容易引起失误，导致权限配置混乱。在平台使用过程中，会存在着角色的定义，角色在这里是指对平台操作模块及权限要求类似的群体。比方：收费员角色、院长角色、系统管理员角色等等。定义角色可以将针对这一类角色所拥有的共同权限添加到角色中去，对于每个用户而言，只需要设置其对应的角色，就可以赋予其对应的权限。一个用户可以对应多个角色，当需要完成当前角色之外的功能时，可以进行角色切换。角色包含的权限只能是该类型机构能够拥有的权限。角色要能够根据机构类别来进行分组，这样可以杜绝跨权限操作的事件发生。业务逻辑流程 图3.4输入输出项功能描述输入输出备注角色列表用户；返回值；返回信息；角色对象集合获取当前用户允许操作的角色列表新增角色用户；角色对象或集合返回值；返回信息；添加当前用户允许范围内的角色，允许批量添加修改角色用户；角色对象返回值；返回信息；修改已经创立的角色对象取消角色用户；角色对象返回值；返回信息；取消已经创立的角色对象停用角色用户；角色对象返回值；返回信息；将指定角色设置为不可用状态3.3.4 权限(quánxiàn)定义适用对象开发人员权限定义；卫生局全局系统管理员权限分配描述简单讲，权限是指用户对于平台的应用范围。平台中的模块由菜单统一控制，而权限定义中包含两局部内容：模块的可见性以及模块的可控性。具体实现方法：树状列出平台中在用的所有模块，也即是所有显示的菜单。每个菜单模块都有一个可见性的权限，但凡拥有这个权限的用户，进入系统后可以看到其对应模块菜单，否那么，那么不可见。而菜单模块下一级，那么是可控性权限列表，定义了其中的操作权限，如：新增、删除、修改等等。一个新建用户，没有分配任何权限，也可以进行平台，但在此情景中，所有菜单皆不可见。而当用户仅仅分配了登录权限，而没有其它可控权限的话，也可以看到模块，并且进入模块，但对其中的内容无法操作。业务逻辑流程参看图3.4输入输出项功能描述输入输出备注权限列表用户；返回值；返回信息；权限对象集合获取当前用户允许操作的权限列表新增权限用户；权限对象集合返回值；返回信息；添加的权限，允许批量添加修改权限用户；权限对象返回值；返回信息；修改已经创立的权限对象取消权限用户；权限对象返回值；返回信息；取消已经创立的权限对象停用权限用户；权限对象返回值；返回信息；将指定权限设置为不可用状态3.2.5 统一药品目录(mùlù)管理适用对象卫生局全局系统管理员描述根据?国家根本药物目录基层医疗卫生机构配备使用局部?2016版(卫生部令第69号，基于全民健康档案管理的社区医疗数字化诊疗系统中必须创立一套统一的药品目录含根本药物目录和非根本药物目录。统一目录的好处是：限制了医疗机构乱用药物；限制了厂家私下对于医疗机构、药剂科、医生的交易统一的药物目录可以限制生产厂家；方便统计，防止了一院一目录之后产生的统计不便问题；简化社保接口流程，往往社保接口时要求对药品和诊疗目录进行对码，而采用统一药物目录之后，只需要对统一药物目录对一次码，那么所有医疗机构都可以不用对码，直接使用社保接口。药品目录因为存在多种对应关系，一种科目中包含了多种药品信息，一种药品有多种别名，一种药品中包含多种规格，一种规格对应多种单位。举个例子：科目为青霉素类药品包含青霉素、苯唑西林、氨苄西林等药品药品科目与药品目录的一对多关系；而青霉素又包含80万、160万、400万等规格药品目录与规格的一对多关系；同时青霉素又被称为青霉素G、 G、 盘尼西林、配尼西林、青霉素钠、苄青霉素钠、青霉素钾、苄青霉素钾药品目录与药品别名的一对多关系；80万的青霉素包含支、盒等单位药品规格与药品单位的一对多关系；药品单位又划分为入出库常用单位、门诊常用单位和住院常用单位单位与常用单位之间一对多的关系。所以从设计上应该多用树状层次关系来表达其内涵。业务逻辑(luó jí)流程图2.5输入输出项功能描述输入输出备注药品科目管理用户；药品科目对象返回值；返回信息；药品科目对象集合获取药品科目对象集合以树状方式展示，并且允许增、删、改药品目录管理药品科目；药品科目对象返回值；返回信息；药品目录对象集合根据药品科目对象，列出其附属的药品目录，并且允许增、删、改药品规格管理药品目录；药品规格对象返回值；返回信息；药品规格对象集合根据药品目录对象，列出其附属的规格对象，并且允许增、删、改药品单位管理药品规格；药品单位对象返回值；返回信息；药品单位对象集合根据药品规格对象，列出其附属的单位对象，并且允许增、删、改药品别名管理药品目录；药品别名对象返回值；返回信息；根据药品目录对象，列出其附属的别名对象，并且允许增、删、改3.2.6 菜单设置适用对象卫生局全局系统管理员描述基于(jyú)全民健康档案管理的社区医疗数字化诊疗系统的功能模块规划为动态可扩展的插件模式。所有的模块都以自定义类的方式分别指定程序员开发。同时为了界面美观，以及未来转换到开发的扩展需要，所以提供了图标地址。在基于全民健康档案管理的社区医疗数字化诊疗系统中，菜单即是模块，菜单的定义不仅仅是指实际可见的界面菜单列表，也包含了为了某些公用模块权限的需要，而创立的虚拟菜单。菜单是允许实时拖动并且变更附属关系的。菜单和权限的关系是一对多，一个菜单可能包含多个权限，其中有可见权限以及可控权限。菜单管理模块主要是开发人员或卫生局高级系统管理人员使用，在其中可以定义菜单对应的菜单类名称。业务逻辑流程输入输出项功能描述输入输出备注菜单列表用户；返回值；返回信息；菜单对象集合获取菜单对象集合新增菜单菜单类别；菜单对象集合返回值；返回信息；创立菜单对象，允许创立同级或下级菜单修改菜单菜单对象返回值；返回信息；修改已经创立的菜单对象取消菜单菜单对象返回值；返回信息；取消已经创立的菜单对象停用菜单菜单对象返回值；返回信息；将指定菜单设置为不可用状态变更菜单上级关系菜单对象；旧上级菜单；新上级菜单；返回值；返回信息；修改菜单所属上级菜单3.3 医疗机构(jgòu)总控图2.83.3.1 机构科室适用对象卫生局全局系统管理员；医疗机构系统管理员描述这里的科室定义不仅仅指的是传统中各医疗机构下属科室，还包括卫生局直属科室，因为我们基于全民健康档案管理的社区医疗数字化诊疗系统的用户群体不仅仅是医疗机构人员，还包括了卫生局工作人员。科室与职工存在着多对多的关系，一个职工可能附属于多个科室，而一个科室也会包含多个职工。科室除了用于对职工的管理之外，还要用于进行很多财务核算，病人管理等领域。科室的类别划分很重要，会直接影响到这个科室可以参与的业务。机构科室设置记录卫生局直属部门以及医疗机构所属科室信息，可以设置不同的属性，直接影响平台业务。门诊科室将会在门诊收费的开单科室中出现；住院科室将在住院收费模块的开单科室中出现；全科将同时可以在门诊及住院科室中出现；医技类科室将出现在执行科室中；库房类那么可以绑定入出库类业务。具体部门类型会在系统数据字典表中明确定义，不可修改。界面上按照类别分组。同单位内的科室是允许切换的，前提条件有两个：一、该用户只能切换本机构内的科室，跨机构切换科室必须先切换到能够切换的机构；二、用户只能切换到系统中配置过的科室。业务逻辑(luó jí)流程图2.9输入输出项功能描述输入输出备注科室列表机构返回值；返回信息；科室对象集合按类别树状获取指定机构下属所有科室新增科室科室对象集合返回值；返回信息在指定机构指定类别下创立新的科室，允许批量创立科室修改科室科室对象返回值；返回信息；修改已经创立的科室对象取消科室科室对象返回值；返回信息；取消已经创立的科室对象停用科室科室对象返回值；返回信息；将指定科室设置为不可用状态3.3.2 职工适用对象卫生局全局系统管理员；医疗机构系统管理员描述这里面的职工泛指本区域卫生系统中的从业人员，不仅仅指平台的操作用户，也包含了不接触平台，却要纳入管理范围的人员。除记录根本的姓名、性别，类别等信息外，还包含了平台内部的一些对应关系。很多医院可能存在的一名职工从事多科室业务的现象。比方一个人可能既是院长，同时又是医生，对应不同的职能科室，其角色接触范围也不同，所以在界面中设置职工与科室的多对多关系。可以将职工标识为操作员，具备这个属性的人员才允许操作平台。丧失密码的用户，系统管理员可以在模块中清空其密码，通知其重新设置。操作员密码无论是在平台中，还是在数据库中，都是不可见的后者必须采用不可逆的加密方式。职工人员(rényuán)设置中可以直接设置操作人员权限，权限作用范围是由两方面决定的：一、操作员拥有的权限；二、权限作用的范围。前者决定操作员可以做什么？后者决定操作员可以在哪些范围内做这些？前者容易理解，而后者在区域化卫生平台中的概念要由操作员附属的机构性质决定，前文提到过卫生机构是树状方式分级管理，表达在权限中，高级别的机构可以拥有管理下一级机构的权限，而低级别的机构不能越权管理上级机构的权限。业务逻辑流程图2.10输入输出项功能描述输入输出备注职工列表机构科室返回值；返回信息；职工对象集合按类别树状获取指定机构指定科室下属所有职工新增职工职工对象集合返回值；返回信息在指定机构指定类别下创立新的科室，允许批量创立职工修改职工职工对象返回值；返回信息；修改已经创立的职工对象取消职工职工对象返回值；返回信息；取消已经创立的职工对象停用职工职工对象返回值；返回信息；将指定职工设置为不可用状态3.3.3 人员(rényuán)角色定义适用对象卫生局全局系统管理员；医疗机构系统管理员描述平台涉及到的用户可能多达上千人，同时涉及到的模块权限可能也会有上百个之多，如果每个人都单独配置权限，那么一方面工作量繁重，另外一方面也容易引起失误，导致权限配置混乱。在平台使用过程中，会存在着角色的定义，角色在这里是指对平台操作模块及权限要求类似的群体。比方：收费员角色、院长角色、系统管理员角色等等。定义角色可以将针对这一类角色所拥有的共同权限添加到角色中去，对于每个用户而言，只需要设置其对应的角色，就可以自动赋予其相应的权限。而角色中不能包含的权限，可以通过赋予用户多个角色的方式来赋予其权限。用户在平台中可以自由切换其角色，来实现不同的功能应用。业务逻辑流程参看图2.10输入输出项功能描述输入输出备注赋予角色职工；角色返回值；返回信息；为指定职工分配角色取消角色职工；角色返回值；返回信息取消职工指定的角色3.3.4 机构药品设置适用对象医疗机构系统管理员；医疗机构药剂科管理人员描述(miáo shù)药品目录是包含了成千甚至过万种药品的数据集，而真正医院在用的药品可能只是其中很小的一个子集。根据实际使用的统计，一般乡镇卫生院的药品种类只有数百种，甚至更少，而县级医院那么可能会有上千种药品。从另外一个角度出发，如果将区域内所有药品全部列出来，也会造成医院管理上的混乱。因此设计了机构药品设置模块，允许医院可以象自选超市一样，自由点选本院拥有的药品，并且为该药品设置相关属性，如：价格、库存上下限等等。这样，在实际使用中，医疗机构的用户只能操作本院拥有的药品信息。业务逻辑流程略输入输出项功能描述输入输出备注新增本院药品机构；机构药品对象返回值；返回信息；添加本机构药品对象修改本院药品机构；机构药品对象返回值；返回信息修改本机构药品对象取消本院药品机构；机构药品对象返回值；返回信息取消本机构药品对象3.4 (中、西)药库管理药品库房管理是医院信息化中最为重要，也是最为复杂的环节之一。医院的库房通常指的是药库中、西药库、药房门诊中、西药房、住院中、西药房、物资库。这些单位通常都具有很多类似的属性，如：它们都具有入库、出库、调价、调拨、盘点、报损、退换等业务，它们都需要统计库存及入出库记录。因此，基于全民健康档案管理的社区医疗数字化诊疗系统在设计库房模型时，采用了“平级库房的理念，将药品库房定义为一个基于库房类为根底类，通过不同方法属性进行扩展延伸的一个层次结构。药库、药房、物资库同属于库房类，而药库具有采购方案、采购结算、接收领药单的方法和属性；药房那么具有划价、发药的方法和属性；物资库那么具有管理物资材料的属性。同样，中药库和西药库同属于药库类的同时，又分别具有管理中药以及西药的属性，中西药房也是同样的道理。因此，设计库房业务时，可以抽取其共性，并且将其个性化局部单独赋予属性即可。图2.113.4.1 库房业务(yèwù)配置适用对象卫生局系统管理员；医院系统管理员；医院药剂管理人员(药库、药房管理人员)描述库房业务配置是对医疗机构下属库房按照不同的属性进行配置，通过配置，原本抽象的根底库房类附加上了相关的业务，变成了药库、药房、物资库。而在一些规模较小的医疗机构，可能对库房实体管理的概念比拟模糊，比方：没有专门的药库和物资库，直接采购到药房，药房实现药库、物资库、药房三位一体的功能。这时候只需要将三者的属性同时附加给一个药房单位，即可实现。库房业务配置还会完成对药品入、出库业务的配置，其中药品入库业务是由多种类别自购入库、招标入库、调拨入库、.组成，药品出库业务是由多种类别发药出库、调库出库、价拨出库、.组成，它们分别会导致药品库存的增或减。在入、出库业务中，有些业务是药品双向业务，即入、出库业务的发生除了导致目标对象需要入出库的库房的库存发生变化之外，还会导致源对象引用库房的库存发生变化；有些业务是单向业务，即入、出库业务的发生仅会导致源对象的库房发生变化。举例：药库药品向药房的调拨出库就是双向业务，因为出库事件的发生，除了导致药房库存的增加之外，还会导致药库库存的减少；而采购入库那么是单向业务，因为我们的基于全民健康档案管理的社区医疗数字化诊疗系统，不会管理到医药公司的库存，所以采购入库时只会引起药库库存的增加，而不会产生其它的附加效应。此外，每个入、出库业务(yèwù)可以单独设置审核属性，但凡需要审核的业务，必须真正完成审核之后，才能对库房产生影响，未审核的单据可以直接修改或删除，而审核完成后的单据只能整体冲红，而不能做局部修改。药品库房业务来源于系统数据字典，医疗机构可以指定本机构库房允许开展的业务，并且为每个业务配置往来单位。业务逻辑流程图2.12输入输出项功能描述输入输出备注新增库房业务机构库房业务类别对象返回值；返回信息；在指定库房新增入出库业务修改库房业务机构库房业务类别对象返回值；返回信息修改指定库房入出库业务停用库房业务机构库房业务类别对象返回值；返回信息将指定库房配置入出库业务置为不可用取消库房业务机构库房业务类别对象返回值；返回信息取消指定库房入出库业务新增库房往来单位机构库房业务单位对象返回值；返回信息在指定库房业务下新增往来单位修改库房往来单位机构库房业务单位对象返回值；返回信息修改指定库房入出库业务下的往来单位停用库房往来单位机构库房业务单位对象返回值；返回信息将指定库房入出库业务下的往来单位置为不可用取消库房往来单位机构库房业务单位对象返回值；返回信息取消指定库房入出库业务下的往来单位3.4.2 药品入库(rù kù)业务适用对象医院药剂管理人员(药库、药房管理人员)描述药品库房可以通过多种方式执行入库业务，增加当前库存。药品是以批次的方式入库，生成批次库存，再在数据库中以视图的方式生成汇总库存。药品库房设计上采用“双库存设计理念。分为实库存和虚库存两种方式来展现库存情况。实库存表示实际存放在当前库房中的药品数量，而虚库存的定义是由于药品库房之前的调拨或病人交费未及时取药而产生的药品实际库存与药品冻结数量之差。举例1：西药房中有100支青霉素，目前尚未有病人购置此药品，那么实库存为100支，虚库存也是100支。此时，门诊病人A购置了10支青霉素，而他未及时取药，这时候实库存仍然是100支，而虚库