卫生信息平台区域居民主索引(EMPI)系统介绍.pdf

《卫生信息平台区域居民主索引(EMPI)系统介绍.pdf》由会员分享，可在线阅读，更多相关《卫生信息平台区域居民主索引(EMPI)系统介绍.pdf（21页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、卫生信息平台区域居民主索引（EMPI）系统介绍 业务描述 通过建立患者主索引，实现患者基本信息对全市卫生信息平台的共享，为整个卫生平台提供数据基础。患者主索引主要记录了患者的个人信息，由唯一 ID（内部使用）进行索引。考虑到患者诊疗信息是个人健康档案信息的一部分，为便于个人健康档案信息的建立、管理与服务，患者主索引 EMPI 的全域唯一标识将采用居民健康档案唯一编码，符合 国家基本公共卫生服务规范（2011 年版）中规定的居民健康档案号：采用 17 位编码制，以国家统一的行政区划编码为基础，以村(居)委会为单位进行编制。主要功能 1.1.1 区域患者主索引的建立 中心主索引的建立能够为患者提供

2、在全市医院就诊的唯一标识，在一定程度上避免了重复建卡发卡（主要针对昆通卡）的不合理现象发生，同时也建立了医院与患者的联系，方便了患者，特别是方便了患者的在本市联网的各家医院的就诊。区域卫生信息平台将以市民卡为载体规范对患者身份建立和识别的机制，其主要做法有以下几种：市民卡/昆通卡/老的医保卡：直接刷卡使用相关卡号，如不存在则产生唯一 ID，否则进行合并。无卡就医人员：区域卫生信息平台将提供统一的医院编码，医院将医院编码、患者识别号（一般是由医院 HIS 系统产生）和基本信息同时上传，中心将根据上传的基本信息，例如身份证号码、姓名等进行比对，没有相同的产生唯一 ID，否则进行合并。区域卫生信息平

3、台将提供相应的应用服务，供所辖医院上传其患者信息。说明：唯一 ID 为内部使用，与卡类型和卡号、或无卡人员在多家医院的就诊号无关，如果有合适的信息保证是同一个人，例如相同的身份证号码，在中心端就必须对应为同一个患者。患者在本市医院就诊时，每家医院都会分配给患者一个唯一的ID 标识，医院将此标识和患者对应的各类卡号或者其他可以证明患者身份的证件号码传递给中心系统，中心系统根据对医院传递的信息与自身数据库中的信息进行比对，如果中心数据库不存在记录，则在中心数据库中建立患者主索引；否则，进行归并。1.1.2 区域患者身份匹配 PIX 平台在各家医院对病人身份注册的基础上，按照配置的病人身份匹配规则，

4、实现一个病人在不同医院所使用的身份间的对照关系，为系统建立自动匹配算法，实现居民身份主索引机制。居民就诊类型包括：市民卡居民、昆通卡居民、老医保卡居民、临时分配就诊号居民（无卡现金等）。对于无法按照匹配规则完成匹配的病人身份需要人工干预完成匹配。1.1.3 区域患者主索引的归并 医院将患者信息传给中心系统时，患者信息满足归并条件，把患者信息归并到原有的主索引中。患者主索引的归并包括自动归并和手动归并，在中心系统中，设定自动归并规则和手动归并规则。对于满足自动规则的患者信息，中心系统将自动把患者信息归并到中心系统的主索引中；而对于满足手动规则对的患者信息，则将患者信息和疑似重复患者信息返回给工作

5、人员，由工作人员确认是否进行归并。1.1.4 区域患者主索引的拆分 主索引拆分主要是针对已知患者主索引归并有误的患者信息进行拆分。可以进行重新归并。1.1.5 区域患者主索引的调阅 完成中心患者主索引的建立后，如果患者在本市医院间进行就诊，平台将提供功能供医院直接从中心系统调阅患者基本信息。对持卡人员（市民卡或老的医保卡），医院用户只需要输入患者的相关卡号，系统就可将该患者的基本信息查询出来。对无卡人员，医院用户需要输入患者的身份证号、姓名等关键信息，系统可将符合条件的患者的基本信息查询出来。1.1.6 区域患者身份的模糊查询 通常情况下，居民信息查询有两种，一种是精确查询，一种是模糊查询。在

6、有居民准确的身份信息ID时，通过居民主索引对居民进行身份确认，从而精确查询的健康相关信息，实现健康信息的调阅共享。当没有居民准确的身份信息ID时，则可以通过居民的部分身份信息模糊查询出相关多个人的健康相关信息，通过人工比对确定居民身份，从而实现居民身份信息的确认以及健康相关信息的调阅共享。应用场景：急诊患者健康相关信息查询 某些情况下，急诊患者处于昏迷或者言语表达障碍时。为了能够及时有效的为患者做出诊断治疗，医生希望能够获取该患者的既往诊疗相关信息。由于无法获取患者的确切身份信息，仅能从患者身上找到部分身份信息，如姓名、出生日期。此时，通过患者身份的模糊查询，输入姓名、出生日期，查询出一系列姓

7、名、出生日期相同的患者，再根据该患者的其他体征，如，体重、身高等，从一系列患者中找出该患者，从而确定患者的身份，并通过确定的身份信息，调阅该急诊患者的既往健康信息。1.1.7 日志管理 由于本模块需要较高的安全性管理，因此对所有本模块的相关操作除在本模块内部处理之外提供完善的数据调用接口，所有的调用系统需要进行日志记录：主索引规则 维护主索引的规则，包括，标识编码规则的设置和维护、不同标识间逻辑关系的管理和维护、EMPI 管理的标识和各个信息系统内相关信息所特有的标识之间的映射关系的设置和维护。主索引创建和维护 相关主索引信息的创建和维护。对于创建和维护主索引的权限可以进行配置。主索引的创建可

8、以通过功能（过程）调用来创建。如，当一个新病人就诊时，HIS 系统可以调用该功能（过程）创建新的病人标识。主索引识别和整合 识别和整合不是由 EMPI 创建的索引信息。具体功能包括：对统一实体的重复的标识进行合并并设置新的统一的识别标志，并建立相应的映射关系；能主动在相关系统中检索和获得索引信息，如，从 RIS/PACS 系统中获得 Series ID 信息。能够提供可查询可操作的用户界面。查询与修改 可以根据权限级别将相应的数据取出返回给申请人，申请人可以使用所取得的数据。由于业务系统的需要，必须更新病人主索引的某些信息时，可通过此调用进行数据更新；为保证医院业务的一致性，修改业务需要提供设

9、置为即时更新或批次更新，由医院相关人员根据需要调整。数据采集场景 1.1.8 门诊类业务 门诊类业务指：普通门诊、急诊，社会医疗保险界定的专科门诊，专家门诊，特需门诊。就诊患者持昆山市市民卡、医保卡或昆通卡在联网医院内接受了一次完整的门诊类业务服务之后，由医院的信息管理系统将该患者就诊时的资料按照本文后述的内容和格式要求，对数据进行汇集后依本文后述要求的方式和时点提交区域卫生信息平台。银医通工程要求医院对数据的提交采用由信息系统自动汇集产生的方式运作。无论患者就医所持的是市民卡还是医保卡或昆通卡，也无论患者是否确实具有享受社会医疗保险的资格，或者享受的社会医疗保险是何种类型，均需要将其作为采集

10、个人基础数据的人员范围。采集的各类数据在医院内部信息系统中产生的图示如下：图中，区域卫生信息平台对医院患者的关键信息、基本信息的采集是与银医通项目直接相关的，患者关键信息的采集采用实时上传的方式，主要针对新办卡和持昆通卡进行身份验证的居民。对新办卡患者区域卫生信息平台还要求实时上传成功开卡的卡号。自助终端机或人工服务柜台持市民卡、医保卡患者持昆通卡患者身份验证新办卡区域卫生数据中心医院居民EMPI数据库挂号+收费就诊流水号诊疗收费取药检验检查医嘱明细费用明细检验检查报告患者基本信息结束患者关键信息实时上传汇集汇总后夜间定时上传汇集汇总后填报提交区域卫生数据中心区域医疗服务数据库汇集汇总后夜间定

11、时上传信息比对、整合信息校验通常的诊疗流程：流程各环节产生的采集数据：1.1.9 住院类业务 住院类业务指：普通住院、急诊观察，社会医疗保险界定的家庭病床，特需住院。就诊患者持昆山市市民卡、医保卡或昆通卡，在联网医院内登记入院，并接受了各种手术或治疗，结束住院过程之后，由医院的信息管理系统将住院期间该患者就诊时的资料按照标准规范的内容和格式要求，对数据进行汇集后按照本文后续章节详述的方式和时点提交区域卫生信息平台。要求对数据的提交采用由信息系统自动汇集产生的方式运作。采集的各类数据在医院内部信息系统中产生的图示如下：数据采集内容 1.1.10 患者关键信息 患者关键信息表(TB _Patien

12、t Key Information)自助终端机或人工服务柜台持市民卡、医保卡患者持昆通卡患者身份验证区域卫生数据中心医院居民EMPI数据库入院登记就诊流水号患者基本信息患者关键信息实时上传汇集汇总后夜间定时上传区域医疗服务数据库汇集汇总后夜间定时上传信息比对、整合信息校验通常的诊疗流程：流程各环节产生的采集数据：各类医嘱的发布检验检查医嘱明细检验检查报告手术报告结束手术各类医嘱的执行出院/离院结算医嘱明细费用明细汇集汇总后填报提交区域卫生数据中心新办卡字段 字段名 类型 字节 可否 为空 说明 卡号 KH 字符串 25 No 见说明（1）证件号码 ZJHM 字符串 32 No 见说明（2）证件

13、类型 ZJLX 字符串 2 No 见说明（3）性别 XB 字符 1 No 见说明（4）姓名 XM 字符串 32 No 1.1.11 患者基本信息 患者基本信息表(TB_ Patient Information)字段 字段名 类型 字节 可否 为空 说明 卡号 KH 字符串 25 No 见说明（1）证件号码 ZJHM 字符串 32 Yes 见说明（2）证件类型 ZJLX 字符串 2 Yes 见说明（3）性别 XB 字符 1 No 见说明（4）姓名 XM 字符串 32 No 婚姻状况 HYZK 字符 1 Yes 见说明（5）出生日期 CSRQ 字符串 8 Yes 格式：YYYYMMDD 出生地 C

14、SD 字符串 32 Yes 编码。按国标 GB2260-91 执行。民族 MZ 字符串 5 Yes 见说明（6）国籍 GJ 字符串 10 Yes 见说明（7）医院内部档案号 YYDAH 字符串 16 Yes 见说明（8）卡类型 KLX 字符 1 No 见说明（9）电话号码 DHHM 字符串 24 Yes 手机号码 SJHM 字符串 20 Yes 工作单位邮编 GZDWYB 字符串 6 Yes 工作单位名称 GZDWMC 字符串 128 Yes 工作单位地址 GZDWDZ 字符串 128 Yes 居住地址 JZDZ 字符串 128 Yes 户口地址 HKDZ 字符串 128 Yes 户口地址邮编

15、 HKDZYB 字符串 6 Yes 联系人姓名 LXRXM 字符串 32 Yes 联系人关系 LXRGX 字符串 8 Yes 见说明（10）联系人地址 LXRDZ 字符串 128 Yes 联系人邮编 LXRYB 字符串 6 Yes 联系人电话 LXRDH 字符串 24 Yes 密级 MJ 字符串 16 Yes 预留。可全填 0。修改标志 XGBZ 字符串 1 No 编码。1：正常、3：撤销。患者基本信息表说明：（1）卡号是 患者基本信息表 的主键。“卡号”是用以关联患者个人的索引。所谓“卡”，指本文“数据采集场景”中界定的各类卡（市民卡、医保卡、昆通卡）。（2）由于某些特殊人群没有身份证，这里

16、也可以填写其它有效身份证件的号码：如军官证号、护照号等。（3）证件类型用于区别有效身份证件的类别，定义如下：1=身份证 2=军官证 3=护照 4=学生证 5=回乡证 6=驾驶证 7=台胞证 9=其它（4）性别编码请按国家标准 GB2261-80 执行。（5）婚姻状况编码请按国家标准 GB4766 执行。使用通常医学意义上的概念。（6）民族编码请按国家标准GB3304-91 执行，采用字母代码。（7）国籍编码请按国家标准 GB26599 执行。（8）医院内部档案号的定义如下：医院内部档案号=“医院编码”+“医院内部患者唯一索引号”。针对一部分医院，其内部已对具有多卡就诊的患者实现了唯一索引功能的

17、情况。（9）卡类型用于说明作为主键的卡是属于何种类型，定义如下：0=市民卡；1=医保卡；2=昆通卡；3=手工（无卡人员走手工流程）；9=其它。（10）联系人关系参见国家标准 GB4761。数据采集方式 1.1.12 数据采集方式说明 区域卫生信息平台医疗服务信息资源的体系结构可按数据的产生、流向、利用顺序分为四层。最下层为医院端，它包含了 HIS、LIS、RIS、CIS、PACS 等医院内部的子系统，分别用于收集和整理各医院内部的就诊、住院、实验室检验等数据。其上一层为数据交换层，是指部署在医院端的前置服务器，用于整合采集上传的数据。再上层为存储处理层，它是指区域卫生数据中心的数据库和应用服务

18、器，它的作用是存储所有共享的数据，是整个区域卫生数据共享平台的数据基础。最上层为交换共享层，提供对患者诊疗档案的综合应用服务。为此，银医通工程需要在医院的局域网上，部署配置一台用于数据交换的前置服务器。前置服务器既作为医院与区域卫生数据中心沟通传递数据的桥梁，同时也作为隔离医院内部系统与区域卫生信息平台等外部系统的防护墙。在前置服务器的外层，将配置防火墙和路由器。医院以外的系统是无法通过前置服务器访问到医院内部的各个应用系统服务器上，或者医生工作站上。医院内的各服务器或医生工作站也无法越过前置服务器提供的相关应用服务而直接对区域卫生数据中心进行访问。该前置服务器中将部署数据交换平台软件。设置发

19、送数据缓存区。发送数据缓存区用于医院按照本规范的要求，将需要定时批量式采集上传的数据填入该数据缓存区的对应数据表中。图：医院定时批量式采集数据示意图 医院端提交数据的方式 由于在“数据采集内容”一章中所描述的数据涉及到需要医院具有与诊疗相关的信息系统予以支撑，为此，联网医院需要首先具备相应的运作条件。在具备运作条件的前提下，医院提交采集数据的方式有三种：第一种是服务调用实时上传的方式，主要是对新办卡或帐户激活、持昆通卡的患者进行身份验证时所用，将患者关键信息向区域卫生数据中心进行实时上传；第二种是定时批量式的提交采集数据，这将包含除去部分字典数据外的其他全部采集内容；另三种是通过 WEB 填报

20、的方式提交，此方式仅包括针对部分字典数据。下面将详细说明这三种提交方式：（一）服务调用实时上传的数据采集方式。主要针对新办卡或持昆通卡的患者进行身份验证时的业务场景，要求医院对自助终端机或人工服务窗口上，对上述业务操作的患者关键信息向区域卫生数据中心进行实时上传，以获得中心端对个人身份校验的结果。（二）定时批量式的提交采集数据。要求医院内部信息系统自动生成数据并定时批量提交到前置机中约定的发送文件缓存区，填写入指定的数据表中。特别需要说明的是：医院内部信息系统在编制提交采集数据的程序逻辑时，不要将提交采集数据的操作逻辑嵌入到医院内日常医疗业务流程中，即不要将提交采集数据成功与否作为日常医疗业务

21、流程是否可继续流转的必要条件。而是作为一个单独的处理程序逻辑予以定时单独运作。在部署前置机时会建立数据库管理系统，并预先创建各数据表的表结构。所有的表根据功能的不同向医院内相关信息系统开放读写权限。在提交数据时，医院信息系统需要按照数据采集时点要求，定时批量的将生成的采集数据填入对应的数据表内。由医院提交到前置机发送文件缓存区的采集数据，由部署在前置机中的医院端数据交换平台自动进行翻译解析上传等一系列工作。对发送文件缓存区内的存储空间释放工作，也将由数据交换平台在完成了上传之后的若干时间之后自动进行。医院将各表的数据填报到发送文件缓存区后，需要在“数据填报情况表”中插入一条记录，以表明当天的填

22、报工作已完成。用以避免由于各种原因导致医院的填报工作延迟而发生未填报完全数据交换平台就开始处理的情况出现。前置机端的数据交换平台在处理完当天的数据后，会将相应的记录的处理标志改掉，告知医院对填报数据已上传处理完毕。（三）WEB 填报式的提交数据方式是指区域卫生信息平台将对医院提供一种WEB 调用方式的字典维护功能，医院内可以使用 WEB 服务的工作站可在相关网页上对字典的数据进行实时维护。数据填报情况表 数据填报情况表用于记录医院数据填报和数据平台处理数据的情况，医院应在将数据写入前置机上传文件缓存后，填写该表，以表示上传处理可以开始了。数据驱动表中的各字段的定义和说明如下：TB_Trigge

23、r 数据项 字段名 数据类型 字节 可否 为空 说明 表名 BM 字符串 32 No 数据采集内容中规定的各种表 应填报时间 YTBSJ 时间 No 正常情况下应为当天填报，则为当天的日期；如果延后填报，则为应该填报的日期 实际填报时间 SJTBSJ 时间 No 处理标志 CLBZ 字符 1 No 0:医院填报完成；1:数据平台处理完成 中心端处理数据的方式 对实时上传的数据处理 对新开卡患者的关键信息采用实时上传的方式，终端机或人工窗口提交患者关键信息（包括证件号码、证件类型、性别、姓名），中心端对证件号码、证件类型、性别、姓名在 EMPI 数据库中进行查询，如果有此人，则返回“已有此人”并

24、告知到人工窗口核实确认，作进一步操作；如果没有此人，则暂存证件号码、证件类型、性别和姓名，终端机开立新卡，如果开立成功，则返回卡号，并调用区域卫生信息平台的服务接口上传卡号，在居民 EMPI 数据库中保存卡号、证件号码、证件类型、性别、姓名，并生成内部唯一索引号（暨档案号）。档案号是患者基本信息关键字段，它是区域卫生信息平台为每一个可能的患者建立的一个内部唯一索引号，采用居民健康档案唯一编码，符合国家基本公共卫生服务规范（2011 年版）中规定的居民健康档案号，采用 17 位编码制。对定时批量式数据上传的处理 批量数据区域卫生信息平台接收到医院上传的数据后，处理过程是首先检验上传数据的合法性，

25、即判断医院上传的数据是否是符合中心数据库约束条件和正确性。对于认为通过了检验的数据将被插入到相应数据表中；对认为有可能不正确的数据，中心端将拒绝接受，并指出出错的内容和原因，反馈医院。中心端检验数据合法性的步骤描述如下：对照中心端的数据字典表，检验医院端上传各数据表中的“编码”字段中的编码值是否在字典表中出现。若出现，则执行下一步处理；否则进行出错处理。检验医院端上传的患者基本信息表中的“卡号”字段是否出现在中心端的患者基本信息表中。若有，则合并患者信息；若没有，则插入患者基本信息表。同时进行患者信息相似度的比较，标记高度相似的患者信息。终端机提交患者关键信息证件号码、证件类型、性别、姓名是否

26、找到新办卡区域卫生数据中心医院居民EMPI数据库按证件号码、证件类型、性别、姓名在EMPI数据库中查询暂存证件号码、证件类型、性别、姓名终端机开立新卡是否开立成功银医通卡、户管理卡号调用平台服务接口（上传卡号）否提示信息返回“已有此人”并告知到人工窗口核实确认是成功银医通卡管理中心保存卡号、证件号码、证件类型、性别、姓名，生成内部唯一索引号开始数据检索数据检索按数据上传接口标准准备数据人工判断信息匹配医院区域卫生信息平台Y合并数据Y患者基本信息符合上传？N中心患者数据医院患者数据疑似NN中心数据存在N结束开始 注：在任何数据上传过程中，作为信息共享的基础，患者基本信息应该优于其它部分（就诊履历

27、、检验检查等）首先上传。上图清晰的描述了整个数据上传的流程，当医院采集了相应的患者信息时，需要按照上传的接口准备数据，然后写入医院前置机。医院前置机会在规定的时间（例如，为了避开工作高峰，在每日晚上），将前置机的数据通过数据交换平台发向中心端。中心端必须对每条数据在中心库中进行检索，根据检索结果分别作如下处理：1.如果信息匹配（卡号一致），那么说明该患者信息在中心已经存在，则不再处理；2.如果卡号匹配不一致，那么应该对患者的其它信息进行比对，如果信息不一致，那么系统认为这是一个新的患者，将会在中心数据库新建一条患者基本信息记录；3.如果系统判断患者的某些信息与中心库中的记录相匹配，例如姓名、年

28、龄等信息，那么系统将该信息标记为“疑似信息”，对于这些信息，应该由医院专门人员人工来判断这些“疑似信息”与中心库中的记录是否为同一个人，如果是同一个人，那么系统把这两条信息合并起来（即对该患者的基本信息进行更新，增加附加信息）；4.如果人工判断不是同一个人，那么系统会在中心数据库新建一条患者基本信息记录。采集结果的反馈和处理 区域卫生数据中心将把采集数据的处理结果通过卫生信息网内部网站向医院发布，医院可以到网站的相应的页面中对处理结果进行查询。发布的处理反馈结果包括如下信息：日期、时间、处理的数据表、提交数据条数、提交处理成功数据条数、未成功处理数据条数。未成功处理数据的内容和未成功的原因。医

29、院需要根据处理反馈结果查找原因，在解决了存在的故障之后，对未成功的数据再次进行提交操作。1.1.13 数据上传的时点 如上一节所述，医院通过内部信息系统自动生成数据并定时批量提交到前置机。医院端信息系统应每天提交门诊类型和住院类型的患者基本信息数据。具体的提交时间说明如下：医院的信息系统应在每天 19 点以后开始，并在 22 点以前完成将下述数据提交到前置机的工作。在当天 19 点之前的一整天内发生就诊或住院的患者基本信息；在当天 19 点之前的一整天内发生的患者基本信息修改信息；前置机将于每天 24 点整将当天医院信息系统提交的数据项上传区域卫生数据中心的数据库中，从而完成整个上传业务。1.

30、1.14 数据的约束条件 受到银医通工程业务逻辑以及数据库处理方式的限制，数据表中的一些字段存在着一些约束关系。医院端必须遵守这些约束条件才能正确地上传数据。采集数据的约束条件可以概括如下：除无卡走手工模式的就医人员外，患者基本信息表中必须有对应的“卡号”，实现与中心端患者关键信息表的关联。凡在各数据表的说明中指明是“编码”的字段，必须按照说明中编码的值域范围填报。调阅 银医通工程的建设成果（患者唯一索引库）将推动完善一个市级的、各联网医院间的数据共享平台，主要的服务对象是联网医院内的医护人员。联网医院中具有操作权限的医护人员都可以通过这个共享平台获得患者的诊疗档案，供诊断时参考。为此，医院需

31、要实现对中心系统诊疗档案的调阅功能。发送查询请求数据检索查询信息展示医院区域卫生信息平台患者卡号患者信息中心数据存在YN结束开始错误信息 1.1.15 数据调阅方式 在区域卫生信息平台中数据调阅的原则是按需调阅，即医院端根据实际需要对患者诊疗档案进行调阅。调阅是由医院端主动发起请求，区域卫生信息平台进行响应；而不是由平台主动将数据下发到医院端。医院端调阅数据的方式分为两种：医生工作站调阅和昆山卫生信息网内网调阅。下文将详细描述这两种方式的调阅方法。1.1.15.1 医生工作站调阅 区域卫生信息平台端将会提供专门的调阅控件给医院，医院需要将控件集成进内部系统，即可使用调阅功能。医生工作站的具体调

32、阅过程分为门诊调阅和住院调阅，如下图：患者在医院挂号后，医院的内部系统根据患者的信息（卡号）向区域卫生信息平台发起请求，如平台发现该患者的信息已存在于中心数据库，即向医院内部系统返回“有信息”标志，否则返回“无信息”标志。医院内部系统应记录下该标志。患者到医生处就医时，医生在内部系统中可以看到患者的基本信息，同时应能看到该患者的历史就诊资料是否在区域卫生信息平台已经存在，如果在区域卫生信息平台具有该患者的诊疗档案，则可发送请求到平台去调阅历史就诊信息，包括“就诊履历”，“检验报告”，“住院病案”等。平台提供的控件能将查阅的信息展示给医生前端工作站。对于患者住院的情况，其调阅诊疗档案的过程与门诊

33、相似。也是由医院内部系统根据医生的操作要求，发送调阅得请求到区域卫生信息平台，平台根据请求去查询该患者的历史就诊信息，包括“就诊履历”，“检验报告”，“住院病案”等。如果档案不存在，则平台返回“不存在”标志；如果存在，则平台提供的控件能将查阅的内容展示。医院在采用上述方式的流程进行调阅的同时，也可以根据自己的需求，将调阅患者诊疗档案功能整合到其他各种医疗的业务流程中。1.1.15.2 昆山卫生信息网内网调阅 医生在医院的前端工作站上启动 IE 浏览器，登录到区域卫生信息平台，在医生患者挂号医院内部系统查询是否有以往记录中心端系统下传患者概要数据显示基本信息患者就诊请求历史就诊信息输入查询要求请

34、求下传历史就诊信息按条件查询显示信息做出诊断患者发起患者身份请求通过了权限认证后，选择相应的“就诊信息查询”服务功能，输入查询条件（患者卡号、就诊时间段、就诊医院等），即可调阅到相关患者的历史诊疗档案。1.1.16 数据调阅的权限控制 昆山市卫生局将根据与各联网医院的协调，依据现有的法律法规，对联网医院的医护人员可以调阅的患者信息建立最为基础性的权限控制措施，并在系统运作的过程中不断完善相关的权限控制措施。目前考虑到的涉及在设计上需要加以注意的情况如下：1）对于联网医院的医生工作站通过 WEB 浏览器直接调阅某患者的病史资料时，需要首先在操作界面上录入操作人员在医院本地系统中注册的“用户名”，

35、首次登录将需要设置“密码”，今后将使用此密码。区域卫生信息平台将根据医院提交的医生字典，核实“用户名”，根据医院提交的医护人员名录中所设置的“科室”和具有的“职称”决定是否开放患者的有关病史信息或者决定开放信息的内容程度。对患者病史信息依据科室和职称可开放的内容范围由另行发布的相关管理规定予以具体界定。2）对于医生工作站的调阅方式，区域卫生信息平台要求医院本地系统负责授权控制，即由医院内部系统来决定是否可让该人员进行数据调阅。通过医院内部授权的人员在调阅数据资料时，除了发送调阅请求外，还应发送有关调阅者的基本信息（比如医生的工号），以便于区域卫生信息平台进行日志记录。医院方应认真做好内部人员的

36、权限控制工作，避免无关人员随意使用信息调阅功能。3）除上述基本权限控制措施外，区域卫生信息平台将对采取上述任意哪种方式进行患者病史资料调阅的情况记录操作流水日志和通行的审计措施。为此，需要医院本地系统在提交调阅请求时，将调阅操作的医生工作站（或者普通的联网计算机前端操作设备）的 IP 地址编号（或内部设备管理编号）作为参数发送区域卫生信息平台，以备在必要时可进行追溯。居民基础数据初始化 在中心系统完成建设之后，对现有居民基础数据进行初始化是个重要工作。居民基础数据的初始化就是针对各家医疗机构已有的居民信息，在中心系统中进行患者主索引的建立和自动归并。对于需要人工归并的居民信息则将信息返回给上传

37、医疗机构，各医疗机构系统管理员进行人工判断和归并，从而完成居民信息的初始化工作。初始化工作推进形式：为了避免数据的大量冲突，保证中心系统的运行准确性，在完成规则调研和接口联调之后，对于各家医疗机构的历史数据上传和试运行采用逐家进行，循序渐进，增量初始化的形式进行。初始化流程：考虑到患者主索引 EMPI 的全域唯一标识采用居民健康档案唯一编码，居民数据初始化的工作首先由社区开始，中心系统接收到医疗机构上传的数据，首先进行主索引的建立和自动归并，在自动归并中主要采用患者的主要信息进行匹配，如身份证件号码等，以保证主索引的建立和归并的数据交换相应速度，再进行扩展居民信息的二次数据清洗，保证居民数据的

38、正确性。把二次清洗的内容传至系统的人工归并库中，进行后续的人工归并确认、拆分和重新归并等工作。1.1.17 初始化调研 主要完成主索引系统初始化的必要信息调研。如中心系统的患者主索引建立规则、自动归并规则和手动归并规则的确定。从而保证中心系统准确快速地完成数据初始化工作。患者主索引建立规则：以居民身份证件号码为基本标识。在身份证件一致的情况下，认为是同一居民，进行主索引的自动归并。而对于没有提供身份证件号码的居民信息进行信息匹配，当满足手动归并规则时，将居民信息作为“疑似信息”传入人工归并库。当发现重复建档的情况，也将居民信息推送到人工归并库中。自动归并工作完成后，检查自动归并库的居民信息，当

39、发现身份证件一致而其他基本信息有差异时，把该居民信息写入人工归并库中。对于归并库中的居民信息则返回上传医院进行人工归并工作，确认为同一患者时，则进行归并；否则进行新建，并上传中心系统建立新的居民信息主索引。自动归并规则：以居民的标识性基本信息为基础，如身份证件号码和姓名等，进行居民信息与中心系统居民信息的匹配，当满足自动归并规则时，则进行自动归并，否则定为“疑似信息”，进行人工归并的判定。人工归并规则：以居民的其他基本信息（唯一性标识以外的信息）为基础，在接收到新的居民数据时，未能检测到数据的有效标识，该有效标识由系统管理员进行调研确定和维护，则进行其他信息的匹配。当匹配度达到手动归并规则的要

40、求时，则将数据推送至人工归并库。1.1.18 接口联调 在正式运行之前，事先进行联调工作，从而减少运行时的错误，保证正式运行时的业务正常进行。从实际情况出发，确定接口联调试点医疗机构：因为考虑到医院与社区的业务差异性，每家医院信息开发厂商负责的每个不同类别的医疗机构（医院或社区）各选取一家医疗机构进行联调。对于一家信息系统开发厂商只负责医院信息业务的，就只选择其中一家医院进行联调即可；而对于一家开发厂商负责医院和社区两种医疗业务的，则选取一家医院和一家社区进行联调；以此类似。以保证接口联调工作的有效性和代表性。搭建测试环境，进行接口联调：在联调初期，最好采用集中联调的形式进行，保证交流的及时性

41、和有效性等。在联调工作成熟的时候，尽量模拟正式环境的开展联调工作。从而减少正式上线试运行时的问题。1.1.19 历史数据上传 进行全市各家医疗机构的居民数据上传工作，完成各家医疗机构的居民信息的初步初始化。历史数据上传工作的开展是各家医疗机构按先后顺序进行的。从而使数据上传工作有条不紊地向前推进。根据接口联调情况进行正式环境下的接口部署和历史数据的批量上传。中心系统进行患者主索引的建立和自动归并工作，并把需要人工归并的信息返回给医疗机构进行试运行的验证和确认工作。历史数据的上传将完成初始化工作的大部分工作。1.1.20 试运行 在接口联调和历史数据的初始化工作之后，进行正式环境的部署和试运行，主要完成人工归并工作、验证拆分、重新归并等验证性工作和正常系统操作业务。人工归并：在正式环境上线试运行时，患者来院就诊时，根据系统人工归并库中的“疑似信息”判断患者信息，如果属于人工归并居民信息，则提示操作人员进行人工归并工作。验证拆分和重新归并：如果人工归并居民信息中，有重复档案或不是当前居民的信息记录，则进行验证，一旦验证情况属实则进行拆分和重新归并操作。拆分出来的信息返回中心系统进行重新判定。通过试运行将完成平台的数据初始化工作，保证居民信息数据的正确性和完整性。