GBT21715.4-2011健康信息学患者健康卡数据扩展临床数据.pdf 21页

'ICS35．240．80L67a雪中华人民共和国国家标准GB／T21715．4—2011健康信息学患者健康卡数据第4部分：扩展临床数据Healthinformatics--Patienthealthcarddata—Part4：Extendedclinicaldata2011-07-29发布(ISO21549—4：2006，MOD)201I-12-01实施宰瞀鹳紫瓣警糌瞥星发布中国国家标准化管理委员会“”’ 目次GB／T21715．4—2011前言⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯ⅢBI言⋯⋯-⋯⋯⋯-----···⋯·⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··-···-⋯⋯⋯⋯-----⋯-⋯⋯⋯⋯··Ⅳ1范围⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯12规范性引用文件⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯13术语和定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·14缩略语⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·一35健康数据卡的基本数据对象模型⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯”35．1患者健康卡数据对象结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯35．2供引用的基本数据对象⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·36卡信息中扩展临床数据的功能要求⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯46．1用途概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯46．2医疗保健方之间的临床消息传递⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯47扩展临床数据⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯47．1概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯47．2临床事件描述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯57．3映射的临床消息⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一67．4扩展急诊数据⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·7附录A(规范性附录)ASN．1数据定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯8附录B(资料性附录)扩展临床数据结构的基本原理⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯10附录c(资料性附录)临床事件的类型与子类型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯··13参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯17 刖昌GB／T21715．4—2011GB／T21715(健康信息学患者健康卡数据》分为七个部分：——第1部分：总体结构；——第2部分：通用对象；——第3部分：有限临床数据；——第4部分：扩展临床数据；——第5部分：标识数据；——第6部分：管理数据；——第7部分：用药数据。将来还可能增加新的部分。本部分为GB／T21715的第4部分。本部分修改采用ISO21549—4：2006《健康信息学患者健康卡数据第4部分：扩展临床数据》(英文版)。本部分与ISO21549—4：2006相比，其技术差异为：——修改了图1中类之间关系的描述，用合成关系替代了关联关系，使图1中类之间的关系更明确；——在5．2．2中增加了GB／T2260--2007的示例，ISO21549-4仅给出了ISO3166-1(GB／T26592000)的示例。本部分与ISO21549-4：2006相比，其编辑性差异为：——表1～表4增加了一列中文名称；——在参考文献中增加了GB／T2260--2007《中华人民共和国行政区划代码》和GB／T2659—2000《世界各国和地区名称代码》两项标准。本部分的附录A为规范性附录，附录B和附录c为资料性附录。本部分由中国标准化研究院提出并归口。本部分起草单位：中国标准化研究院。本部分主要起草人：董连续、陈煌、石丽娟。Ⅲ GB／T21715．4—2011引言随着流动人口的增加，更多的医疗服务发生在社区以及患者家中，因而对高质量流动医疗服务的需求不断增长，便携式信息系统和存储器也随之得以迅速开发和利用。通过移动的医疗记录文件，这些设备可实现从身份识别到患者便携式监控等一系列系统功能。这些设备的功能是携带可识别的个人信息，并与其他系统之间进行传递；因此，在工作期间，它们可能与许多功能和性能有很大差异的不同技术系统一起共享信息。医疗保健管理越来越依靠类似自动化的识别系统。例如，对处方进行自动处理，患者可通过使用便携式可读计算机设备实现在不同地点之间的数据交换。医疗保险公司和保健提供方越来越多地涉及到跨区域治疗中。在这种情况下，理赔可能需要在很多不同的保健系统之间自动交换数据。可远程访问数据库及其支持系统的出现带动了“保健受益人”识别设备的开发和利用，这些设备能执行安全功能并且能经由网络向远程系统传送数字签名。随着使用日常保健服务中数据卡的日益增多，有必要对数据格式进行标准化以实现数据交换。数据卡携带的与人相关的数据可分成3种主要类型：标识数据(设备本身的标识数据及设备所携带的个人标识数据)、管理数据和临床数据。需要特别指出的是，实际使用的健康数据卡应包含设备本身的标识数据及其携带数据所涉及的个人标识数据，而管理数据、临床数据、用药数据和链接数据是可附加的。设备数据包括：——设备本身的标识；——设备功能和能力的标识。标识数据可包括：——设备持有者的唯一标识或者所有其他与该设备所携带数据相关的人的唯一标识。管理数据可包括：——个人相关的补充数据；——保健资金的标识，表明其是有支付的还是自付的，以及他们的关系，即保险公司，保险合同和保险单或者保险费的类型；——保健服务所必需的其他数据(不同于临床数据)。临床数据可包括：——提供健康信息和健康事件信息的数据项；——保健提供者对他们的评价和标注；——已计划的、要求的或者已经执行的临床行为。因为数据卡本质上是给明确的查询提供具体的答复，同时有必要通过消除冗余来优化使用存储空间，所以在定义健康数据卡数据结构时使用了高层次的对象建模技术(OMT)。本部分使用UML、纯文本和ASN．1来描述和定义患者持有的健康数据卡所使用或引用的扩展临床数据对象。本部分仅引用和应用GB／T21715第2部分定义的一般对象，不对其进行描述或定义。Ⅳ 健康信息学患者健康卡数据第4部分：扩展临床数据GB／T21715．4—20111范围GB／T21715的本部分规定了扩展临床数据对象中所含数据的基本结构，但没有规定或指定用于存储在设备中的专门数据集。本部分适用于由患者健康卡记录或传递的数据，该患者健康卡与GB／T14916中定义的各类ID-1卡的物理尺寸一致。为了促进互操作，一旦建立了用于医疗保健领域且符合GB／T21716的应用，则该应用所需的数据项应取自第6章和第7章所给出的对象列项(其中某些对象是可扩展的)。这些数据项与GB／T21715其他部分所定义的数据联合使用。本部分不适用于下列服务的详细功能和机制(即使它的结构可供其他地方规定的合适数据对象使用)：——自由文本数据的编码；——可由数据卡用户按照具体应用所规定的安全功能和相关服务，例如，保密性保护，数据完整性保护，以及与这些功能相关的个人和设备的身份鉴定；——依赖于某些数据卡类型的访问控制服务，例如微处理器卡；——初始化和发布过程(个人数据卡工作周期的开始，并且使数据卡为后续通信中为其传递符合本部分要求的数据做准备)。本部分也不包括以下内容：——用于特定类型数据卡的实际功能的物理或者逻辑解决方案；——如何处理在两个系统接口间的消息；——数据卡外部的数据所使用的格式，以及在数据卡或其他地方用以可视化地表达这类数据的方式。2规范性引用文件下列文件中的条款通过GB／T21715的本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。GB／T14916--2006识别卡物理特性(Is0／IEC7810：2003，IDT)GB／T21715．2—2008健康信息学患者健康卡第2部分：通用对象(ISO21549—2：2004，IDT)GB／T21715．3—2008健康信息学患者健康卡第3部分：有限临床数据(ISO21549—3：2004，IDT)3术语和定义下列术语和定义适用于GB／T21715的本部分。】 GB／T21715．4—20113．13．23．33．43．53．63．73．83．92临床信息clmicalinformation医疗保健方所记录或负责的关于医护主体与健康和治疗相关的信息。注I：临床数据／信息与个人健康或医疗保健有关，这些信息取自接受医疗保健服务的个人或与之相关。它包括保健提供方对患者身体或精神健康状况的客观检查或主观诊断、个人健康史和家族健康史、诊断分析、诊断原理、诊断过程、发现、疗法、所开药方、治疗反馈、症状描述以及与患者健康相关的社会经济和环境因素．[ASTME1769，CPRI]注2；可包括医护主体的保健环境信息或相关人的信息。数据对象dataobject自然分组并且可标识为一个完整实体的数据集合。[GB／T21715．1--2008／ISO21549一l：2004]健康卡持有者hcalthcardholder持有健康数据卡的个人，该卡中包含了标识此人为主的相关记录。[GB／T21715．2--2008／ISO21549—2：2004]健康数据卡hcaithcaredatacard用于健康领域且符合GB／T14916的机器可读卡。[GB／T21715．1--2008／ISO21549一l：2004]医疗保健方hcalthcareparty对个人或群体提供直接或间接医疗服务的组织或个人。注：医疗保艟方是医疗保键代理中的一个子集。[EN14720—1]链接linkage对两个或两个以上实体或部分进行连接。注：链接可以是实物的、电气的或关系的。[GB／T21715．3--2008／ISO21549—3：2004]记录record所采集数据的集合。[GB／T21715．1--2008／ISO21549一I：2004]被记录人recordperson与一条可标识记录对应的个人，该记录包含与该人相关的数据。[GB／T21715．1--2008／ISO21549—1：2004]中继代理relayingagent被授权在医疗保健请求方和被请求方之间双向传输消息的中介，该传输是在被请求的医疗保健方 CB／T21715．4—2011标识未知，不能直接通信时进行，且该授权由个体患者决定。4缩略语下列缩略语适用于GB／T21715的本部分。AsN．1抽象语法记法，版本1AbstractSyntaxNotationversionlEN欧洲标准EuropeanNormHCP保健受益人HealthcarepersonHDC健康数据卡HealthcaredatacardIEC国际电工委员会InternationalElectrotechnicalCommissionISO国际标准化组织InternationalOrganizationforStandardizationUML统一建模语言UnifiedModelingLanguageUTC协调世界时间CoordinatedUniversalTime5健康数据卡的基本数据对象模型5．1患者健康卡数据对象结构GB／T21715设计了一组能灵活地存储临床数据的基本数据对象，并允许将来增加特定应用。通过有效利用存储空间的方式，实现已存储数据的通用附加特性。有效利用存储空间，也是大多类型数据卡共有的重要特征。基本数据对象由基于面向对象模型的类结构组成，该模型的UML类框图如图1所示。固1患者健康卡数据的总体结构该面向对象的结构的内容在下面描述，也可能需要用到本部分没有定义的其他数据对象。注：在保持特定语境标记时有可能需要获取数据对象并重新组合它们，在保持互操作性时也可能需要定义新的对象。除具有用简单的构筑模块建立起复杂的聚合数据对象的能力外，GB／T21715还允许在某些对象之间建立起关联，以便使信息可以共享。例如，该特征主要使一套附加属性可以用来为若干个所存储的信息对象提供服务。5．2供引用的基本数据对象5．2．1概述GB／T21715已经定义了一系列普遍有用的数据类型，虽然这些定义本身没有内在的值，但是GB／T21715可以用其来定义其他对象。可以在与其他有关的信息对象相关联的情况下对这些对象进行相应操作来“附加值”。这些对象在GB／T21715．2—2008中已经给出了正式的定义。 GB／T21715．4—20115．2．2代码型数据代码值的含义是由其对应的编码方案来决定的。GB／T21715的本部分的一般原则是：当这些代码作为参数时，除非在本部分里做了特别规定，否则不刻意要求使用特定的编码方案。例如，可以使用2659--2000规定的国家代码和GB／T2260--2007规定的我国行政区划代码。某个特定的编码方案一旦在本方案中确定，就不再允许使用其他任何编码方案。但对任何未按上述形式引用的编码方案，将来都可对其进行独立于本标准其他部分的修改调整。数据对象。CodedData”(代码型数据)应按照GB／T21715．2—2008的定义来构建。5．2．3设备和数据的安全一性用于健康领域的数据卡中存储的数据对个人来说可能非常敏感。因此，本部分使用了在21715．2—2008中定义的一系列安全属性。实际数据内容(值)和使用这些数据元素的机制不在本部分的范围内。需强调的是，如果数据卡中没有实施合适的安全功能和安全机制，则安全属性将不能满足特定的安全需求。“访问”权限由与各离散数据项相关的特定个体来决定。该权限由应用程序开发者定义，并且由自动化系统(如健康数据卡)来控制。这种权限可以在应用层定义，因而提供了应用和潜在的国家特异性。数据对象“securityservice”(安全服务)用来存储实现这些安全功能和机制所需的数据。这些数据能附加在单个数据元上，从而当数据对象在不同形式的数据卡问传送时，能够保持源作者的安全需求。因此，这种机制能够保证数据在从主动媒介传向被动媒介，然后再返回主动媒介的过程中重建出原始的安全需求。这种能力有助于精确地复制数据卡，用于诸如健康卡失效后重建等情况。5．2．4附加一性按照GB／T21715．2～2008中的定义，数据对象“AccessoryAttribute”(附加属性)应由一组有序的数据组成，这组数据对于记录下有关对信息发送方和信息到达接收方的方式的审计跟踪是至关重要的。6卡信息中扩展临床数据的功能要求6．1用途概述21715的本部分主要用于健康数据卡(HDc)：——在松散结合的医疗保健方(如未能建立网络联系或还没有可信的第三方医疗保健方)之间携带临床消息(医嘱、转诊、报告)；——在紧密结合的医疗保健方(如已建立网络联系或已有可信的第三方医疗保健方)之间携带临床消息的链接和访问密钥；——携带扩展的有限临床数据集(见GB／T21715．3)的诊断和过程的代码型概要，这些概要可以是有限临床数据在国家层面或机构层面上的扩展。6．2医疗保健方之间的临床消息传递设计HDC用于医疗保健方之间传递临床消息时，应考虑HDC能作为中继代理的安全数据媒介。该HDC无需预先确定目标医疗保健方就可接收临床消息，也有鉴别该医疗保健方获取这些临床数据的资格的作用。7扩展临床数据7．1概述扩展临床数据(ExtendedClinicalData)具体分为三个独立的数据对象(其数据定义见附录A)：临4 GB／T21715．4—2011床事件索引(ClinicalEventDescription类)、映射的临床消息(MappedClinicalMessage类)和扩展急诊数据(ExtendedEmergencyData类)。由于它们分属不同组类，这些对象可以具有不同的安全设置，包括由附加属性(AccessoryAttributes类)中所含条款决定的访问权限。扩展临床数据集的结构如图2所示(其基本原理参见附录B)。表1给出了扩展临床数据集中单个实体的具体说明。图2扩展临床数据集的结构表1扩展临床数据集中各单个实体的规格说明对象类中文名称对象类型可出现频次说明该类包含在HDC中注册的临床CIinicalEventDescription临床事件描述类0．．n事件描述该类包含映射的临床事件消息，MappedClinicalMessage映射的临床消息类0．．n该消息携带的是已注册临床事件的信息ExtendedEmergencyData扩展急诊数据类0．．n该类包含代码型扩展急诊数据7．2I临床事件描述“clinicalEventDescription”对象应由临床事件标识符、临床事件类型和子类型(控制代码)、临床事件发生日期、时间、地点组成(参见附录c)。这些属性的定义和说明见表2。该对象可包含“Accessory—Attributes”这一可选元素。该对象用来支持相关临床消息的选择过程。临床事件描述数据集的结构见图3。图3I临床事件描述数据集的结构根据图3，临床事件描述实例可以引用所映射的临床消息实例和附加属性实例。也可见表2。 GB／T21715．4—2011表2临床事件描述数据集中各单个实体的规格说明对象类中文名称对象类型可出现频次说明该属性用于标识一个I临床事件，允许eventID事件m八位字符串1相关临床消息发起方唯一标识该事件该属性用于标识临床事件的类型(医eventType事件类型编码数据1嘱、转诊、出院、临床调查结果等)该属性用于标识管理所需的临床事eventSubtype事件子类型编码数据0．．i件子类型(新建医嘱、取消医嘱等)该属性用于标识临床事件的日期及eventDateTime事件日期时间协调世界时间0．．1时间该属性用于引用临床事件发生或注eventPlace事件地点引用指针0．．1册的地点或系统的标识符clinMessPointer临床消息指针引用指针0．．1该属性用于引用映射的临床消息accessoryAttributesPointer附加属性指针引用指针0．．1该属性用于引用附加属性7．3映射的临床消息“MappedClinicalMessage”对象应携带临床事件的信息。该信息包含在临床消息中，临床消息由该事件触发，并由服务请求方指向服务提供方，或反向进行。该对象相关属性的定义和说明见表3。其关系结构见图4。图4映射的临床消息数据集的结构根据图4每一个“MappedClinicalMessage”的实例都将被一个描述临床事件实例引用，见表3。表3映射的临床消息中各单个实体的规格说明对象类中文名称对象类型可出现频次说明该属性用于标识消息发起方传messagingStandardName消息传送标准名代码型数据1送消息所使用的标准名称该属性用于标识消息发起方传messagingStandardVersion消息传送标准版本代码型数据0．．1送消息所使用的标准版本该属性用于标识消息发起方所messageEncodingRuIes消息编码规则代码型数据0．．1使用的编码规则该属性用于标识消息的首选messageLanguage消息语言代码型数据0．．1语言当消息写入HDC时，该属性标messageMappingRules消息映射规则代码型数据0．．1识了卡应用所使用的映射规则mappedMessage映射消息八位字符串1映射消息的本身accessoryAttributesPointer附加属性指针引用指针0．．1该属性引用了附加属性 GB／T21715．4—20117．4扩展急诊数据“ExtendedEmergencyData”对象应携带GB／T21715第3部分所定义的有限临床数据的补充信息。该信息包含代码型临床数据。其属性的相关定义及结构见表4和图5。图5扩展急诊数据集结构表4扩展急诊数据中各单个实体的规格说明对象类中文名称对象类型可出现频次说明该属性是过程、患者症状或诊断emergeneyltem急诊项概念描述符1的代码型描述符协调世界该属性是过程、患者症状或诊断onsetDateTime发作El期时间0．．i时间等发生的日期和时间 GB／T21715．4—20118附录A(规范性附录)ASN．1数据定义ClinicalEventDescription：：一SET(eventIDrO]OCTETSTRING，eventType[1]CodedData，eventSubtype[2]CodedDataOPTIONAL，eventDateTimer3]UTCTimeOPTIONAL，eventPlacer4]RefPointer0PTIONAL，——指向存储于任何地址的个人／地点标识符的指针clinMessPointerr5]RelPointerOPTIONAL，——指向存储于任何地址的临床消息的指针accessoryAttributesPointer[6]RefPointerOPTIONAL——指向存储于任何地址的附加属性的指针)MappedCliniealMessage：：一SET{messagingStandardName[o]CodedData，messagingstandardVersion[1]CodedDataOPTIONAL，messageEncodingRules[2]CodedDataOPTIONAL，messageLanguage[3]CodedDataOPTIONAL，messageMappingRulesE4]CodedDataOPTIONAL，mappedMessage[5]OCTETSTRING，aeeessoryAttributesPointer[6]RefPointeroPTIONAL}ExtendedEmergencyData：：=SET(emergeneyItem[o]conceptDescriptor，onsetDateTimer1]UTCTime．aceessoryAttributesPointer[2]RefPointerOPTl0NAL——指向存储于任何地址的附加属性的指针)ConceptDeseriptor：：一SET{eonceptCode[o]OCTETSTRING，conceptName[1]OCTETSTRINGOPTIONAL，codingSchemePointer[2]RefPointer，——指向存储于任何地址的编码方案的指针conceptoriginalText[3]OCTETSTRINGOPTIONAL，conceptTranslation[4]SETOFConceptDescriptor， conceptQualifier)QualifierRole：：=SET{qualifierNamequalifierValuequaIifierInverted}[5]SEQUENCEOFQualifierRole[o]CodedData，[1]conceptDescriptor[2]BOOLEANGB／T21715．4—20119 GB／T21715．4—2011B．1概述附录B(资料性附录)扩展临床数据结构的基本原理临床医嘱或转诊的请求通常伴有临床信息的相关子集，这些临床信息是由医疗保健专业人员所持有的患者(医嘱或转诊的主体)信息。医嘱或转诊的接收方通常报告该请求服务的进程或结果。当请求服务已经完成或处于其他关键节点时要产生这些报告。这些传送的信息以及医疗保健专业人士之间的报告通常构成了患者的管理和临床记录的一部分，这些报告由通信各方所持有。这些请求和报告的电子传送减少了人工数据输入的需求和抄写错误的风险。这也提高了效率，并促成了医疗保健服务的改善。HDC可以通过几种途径使得医嘱、转诊和报告的电子传送更加便利。首先，他们可以在松散结合的医疗保健方(如未能建立网络联系或还没有可信第三方的医疗保健方)之间携带临床消息(医嘱、转诊、报告)。HDC也可以在紧密结合的医疗保健方(如已建立网络联系或已有可信第三方的医疗保健方)之间携带帷床消息的链接和访问密钥。根据ENV13607，可将HDC及其关联的适当卡应用(卡系统)看作一个中继代理。见图B．1。蹰。／＼1．。捎息接口卡接口图B．1作为中继代理构件的HDC在临床医嘱和转诊情形中，当被请求的医疗保健方身份未知而导致无法直接通信时，允许中继代理充当相关媒介，以便在请求和被请求的医疗保健方问双向交换消息，这依赖于患者自身的选择(见图B．2)。该中继代理也可受委托，无需预定义请求方即可从请求方接收新的医嘱或转诊。中继代理也可用来鉴别对应的被请求方的资格以实现扩展临床数据的检索。10圈B．2充当请求方与被请求方问媒介的中继代理 CB／T21715．4—2011为了让中继代理能存储医嘱、转诊和报告，HDC除了能够携带急诊数据集、用药数据、标识和管理数据之外，还能携带扩展临床数据。相关标准应能定义HDC在目前使用的许多系统间携带的扩展临床数据的结构。这些标准实现会促进了医嘱、转诊以及报告在松散和紧密结合的医疗保健方之间的电子交换，减少了人工数据输入的需求和抄写错误的风险。同时也会提高工作效率，促成了医疗保健服务的改善。B．2扩展临床数据结构的构建GB／T21715所提出的扩展临床数据对象源自电子医嘱／转诊／报告交换标准的相关数据对象的定义，这些标准如下(但不局限于此)：——EN14720-1l——HL7版本2第4章医嘱录入，第7章观察报告，第11章患者转诊；——HL7临床文件架构(HL7CDA)；——UN／EDIFACT消息MEDREQ和MEDRPT；——DICOM3．0。这意味着这些标准中所定义的消息相关部分将映射到或映射自所提出的扩展临床数据结构。该映射可由作为媒介的卡应用系统来完成(见图B．1)。可在不同的消息结构层面来实现：消息层面、消息局部层面、消息元素层面(见图R3)。洧息层洧息部件层消息元素层图B．3消息结构层面几年以前，ASCX12N也面临一个类似问题，即构建医疗保健声明附件的临床数据结构的问题。该委员会采纳了HL7第2版在第一消息层临床医嘱消息的映射：整个ORU(自动生成的观察报告)消息全部嵌入在二进制段BIN中。此方法极大地简化了标准的实施和维护任务。如果HDC的存储量比较小，就无法携带所映射的临床消息。但新型HDC的内存可达数几百兆字节，该问题并不重要。HDC不仅应含嵌入的临床消息，还应包含所支持的数据结构。该结构可由图B．4所示的协作图导出。 GB／T21715．4—2011至墨至}二笔竺13：resuhofseⅣice3：requestforservice()18：resu]tquery()21：r龄ult∞tselection(、20：resultsetlist()22：resultofservicd)ServiceProvider：HealthcarcInformationSystemlO：s6。：r鬻v要是嚣‰、Iccsdsdc“onr、15：resultof_service()：。≮n删teffa蛐ceL_—二主1r———————一165=：u”pd”atei“n“de“xo“f毽events()f|＼8：servicesetI”Ⅱ)12：requen如㈣l∞()邕卦——型画图B．4健康信息系统和携带临床消息的HDc之间的交互服务请求方可直接向服务提供方发送服务请求(医嘱或转诊)，或通过卡应用接口将该请求放到HDC中。当患者(HDC持有者)访问服务提供方(如看病或体检)时，患者授权给提供方使用HDC。HDC可携带许多服务请求，因此服务提供方应首先查询相关的请求，然后从返回的列表选取适当的请求。服务请求方也应经过类似的程序，接收所请求服务的信息结果。卡应用则从HDC中读取相关临床事件索引或遍历嵌入的临床消息以创建索引。由于HDC可携带大量临床数据和消息，遍历消息会很耗时，这种方法不可取；因此，HDC应既含嵌入的临床消息，又含与这些临床消息相关的事件索引。如果HDC的存储量不足以携带这些临床消息，则该卡可只含事件索引。即使卡中缺乏相关消息，了解事件的相关事实也是有用的。有了事件ID，医疗保健方可利用网络或仅通过电话向消息发起方咨询详细的临床信息。HDC也可携带患者症状、诊断、过程的代码型概要。该概要扩展了GB／T21715第3部分所定义的有限临床数据集。该概要对于急诊会很有用。该概要的每一条都含有相关临床分类或编码系统所构建的代码型词组短语，如IcD、CPT、SNOMEDInternational、SNOMEDRT、SNOMEDCT。Concept—Descriptor类型的定义源自ISO21090(起草中)中CD数据类型的定义。墓小器㈣ 附录C(资料性附录)临床事件的类型与子类型GB／T21715．4—2011C．1概述根据本部分所述，事件的类型与子类型为代码型数据。在HL7第2版中，事件类型在HL7表0003——事件类型中有所定义，因此它们的代码系统名称应为H70003(见表C．1)。医嘱管理代码(HL7表0119)可视为事件的子类型，因此它们的代码系统名称应为H70119(见表C．2)。本附录包含HL7表0003和HL7表0119的子集，分别作为事件类型和子类型代码的推荐值。c．2事件类型表C．1HL7衰0003的子集——事件类型事件类型说明A03ADT／ACK--Discharge／endvisit出院／就诊结束A13ADT／ACK--Canceldischarge／endvisit取消出院／就诊结束C01CRM--Registerapatientonaclinicaltrial注册临床试验CRM--Cancelapatientregistrationonclinicaltrial(forclericalmistakesonly)取消临床试验的注册(仅C02由于出现文字错误)C03CRM--Correct／updateregistrationinformation纠正／更新注册信息C07CRM_Correct／updatephaseinformation纠正／更新阶段信息C08CRM--Patienthasgoneoffphaseofclinicaltrial患者已离开临床试验阶段C09CSU--Automatedtimeintervalsforreporting，likemonthly自动报告的时间间隔，如每月C10CSUPatientcompletestheclinicaltrial患者完成临床试验C11CSU--Patientcompletesaphaseoftheclinicaltrial患者完成某临床试验阶段C12CSUUpdate／correctionofpatientorder／’resultinformation更新／纠正患者医嘱／结果信息112REF／RRI--Patientreferral患者转诊113REF／RRI--Modlfypatientreferral变更患者转诊114REF／RRI--Cancelpatientreferral取消患者转诊115REF／RRI--Requestpatientreferralstatus请求患者转诊状态001ORM--Ordermessage医嘱消息002ORM--Orderresponse医嘱应答019OMG--Generalclinicalorder一般临床医嘱020ORG／ORL--Generalclinicalorderresponse一般l临床医嘱应答021OML--Laboratoryorder实验室医囊 GB／T21715．4—2011衰c．1(续)事件类型说明ORL--GenerallaboratoryorderresponsemessagetoanyOML对任何OML的一般实验室医嘱应答022消息PCIPPR--PC／problemaddPC／问题(症状)增加PC2PPR--PC／problemupdatePC／问题更新PC3PPRPC／problemdeletePC／问题删除PC6PGL--PC／goaladdPC／目标增加PC7PGL--PC／goalupdatePC／目标更新PC8PGL--PC／goaldeletePC／目标删除PC9PGL--PC／goalqueryPC／目标查询PCAPPV—Pc／goalresponsePC／目标应答PCBppP--PC／pathway(problem-oriented)addPC／路径(面向问题的)增加PccPPP--Pc／pathway(problem-oriented)updatePC／路径(面向问题的)更新PCDPPP--PC／pathway(problem-oriented)deletePC／路径(面向问题的)删除PCGPPG--PC／pathway(goal-oriented)addPC／路径(面向目标的)增加PCHPPG--pc／pathway(goal-orlented)updatePC／路径(面向目标的)更新PqPPG--PC／pathway(goaboriented)deletePC／路径(面向目标的)删除R01ORU／ACK--Unsolicitedtransmissionofanobservationmessage自发传送观察消息R21OUL--Unsolicitedlaboratoryobservadon自发的实验室观察T01MDM／ACK--Originaldocumentnotification原始文件通知T02MDM／ACK--Originaldocumentnotificationandcontent原始文件通知与内容T03MDM／ACK--Documentstatuschangenotification文件状态变更通知T04MDM／ACK--Documentstatuschangenotificationandcontent文件状态变更通知与内容T05MDM／ACK--Documentaddendumnotification文件附录通知T06MI)M／ACK--Documentaddendumnotificationandcontent文件附录通知与内容T07MDM／ACK--Documenteditnotification文件编辑通知T08MDM／ACK--Documenteditnotificationandcontent文件缩辑通知与内容T09MDM／ACK--Doeumentreplacementnotification文件替换通知T10MDM／ACK--Documentreplacementnotificationandcontent文件替换通知与内容T1lMDM／ACK—Documen‘cancelnot“ication文件取消通知。．V04VXUUnsolicitedvaccinationrecordupdatetJ发免疫记录更新ORU--Waveformresult，unsolicitedtransmissionofrequestedinformation波形结果，请求信息的自发WOi传送14 C．3事件于类型表C．2HL7表0119--医嘱管理代码GB／T21715．4--2011值说明AFOrder／servicerefillrequestapproval同意重新请求医嘱／服务CACancelorder／servicerequest取消医囊／服务请求CHChildorder／service于医嘱／服务CNCombinedresult组合结果CRCancelledasrequested应请求而取消DCDiscontinueorder／servicerequest中止医m／服务请求DEDataerrors数据错误DFOrder／servicerefillrequestdenied拒绝再次医嘱／服务请求DRDiscontinuedasrequested应请求而中止FUOrder／servicerefilled．unsolicited自发再次执行医嘱／服务HDHoldorderrequest保留医嘱请求HROnholdasrequested应请求而保留LILinkorder／servicetopatientcareproblemorgoal将医嘱／服务与患者保健问题或目标相链接NANumberassigned分配的号码NWNeworder／service新医嘱／服务ocOrder／servicecancelled取消的医嘱／服务0DOrder／servicediscontinued中止的医嘱／服务OE0rder／servicereleased发布的医嘱／服务0FOrder／servicerefilledasrequested应请求而再次执行的医嘱／服务0H0rder／serviceheld保留的医嘱／服务oKOrder／serviceacceptedandOK接受的医嘱／服务0RReleasedasrequested应请求而发布PAParentorder／service父医嘱／服务PRPreviousResultswithneworder／service舍新医嘱／服务的先前结果REObservations／PerformedServicetofollow跟踪观察／执行服务RFRefillorder／servicerequest再次提出医嘱／服务请求RLReleaseprevioushold发布先前保留的内容ROReplacementorder医嘱替换RPOrder／servicereplacerequest医嘱／服务替换请求RQReplaced∞requested应请求而替换．．RRRequestreceived收到请求RUReplacedunsolicited自发替换SCStatuschanged状态变更15 GB／T21715．4—2011表C．2(续)值说明SNSendorder／servicenumber发送医曩／服务号SRResponsetosendorder／servicestatusrequest对发送医嘱／服务状态请求的应答SSSendorder／servicestatusrequest发送医嘱／服务状态请求UAUnabletoacceptorder／service无法接受医嘱／服务UCUnabletocancel无法取消UDUnabletodiscontinue无法中断UFUnabletorefill无法再填写UHUnabletoputonhold无法保留UMUnabletoreplace无法替换UNUrdinkorder／servicefrompatientcareproblemorgoal取消医嘱／服务与患者保健问题或目标的链接URUnabletorelease无法发布UXUnabletochange无法变更XOChangeorder／servicerequest变更医嘱／服务请求XRChangedasrequested应请求而变更】a【Order／servicechanged，unsolicited自发变更的医嘱／服务16 参考文献GB／T21715．4—2011[13GB／T2659--2000世界各国和地区名称代码E23GB／T2260--2007中华人民共和国行政区划代码[3]GB／T9387．2—1995信息处理系统开放系统互连基本参考模型第2部分：安全体系结构E4]GB／T15843．1—1999[5]GB／T16264．8—2005[6]GB／T18794．2—2002框架[7]ASTME1769--1995cordSystems信息技术安全技术实体鉴别第1部分：概述信息技术开放系统互连目录第8部分：公钥和属性证书框架信息技术开放系统互连开放系统安全框架第2部分：鉴别StandardGuideforPropertiesofElectronicHealthRecordsandRe一[8]ENV13607：2000Healthinformatics--Messagesfortheexchangeofinformationonmedi—cineprescriptions[9]EN14720—1：2005Healthinformatics--Servieerequestandreportmessages--Part1：BasicservicesincludingreferralanddischargeElO]ISO3166—1：2006Codesfortherepresentationofnamesofcountriesandtheirsubdivi—sions--Part1：Countrycodes[11]ISO6093：1985Informationprocessing--Representationofnumericalvaluesincharacterstringsforinformationinterchange[12]ISO／IEC6523一I：1998Informationtechnology--Structurefortheidentificationoforgani—zationsandorganizationparts—Partl：IdentificationoforganizationidentificationschemesE13]ISO／IEC6523—2：1998Informationtechnology--Structurefortheidentificationoforgani—zationsandorganizationparts—Part2：Registrationoforganizationidentificationschemes[143ISO／IEC8825(allparts)Informationtechnology--ASN．1encodingrules[15]ISO／IEC8859—1：1998-04Informationtechnology--8一bitsingle-bytecodedgraphicchar—actersets—Part1：LatinalphabetNo．1[16]ISO／IEC8824(allparts)Informationtechnology--AbstractSyntaxNotationOne(ASN．1)[17]EN14720—1Healthinformatics--Servicerequestandreportmessages--Part1：Basicser-vicesincludingreferralanddischargeE18]HL7Version2Chapter4OrderEntry，Chapter7ObservationReporting，Chapter11Pa—tientReferral[19]HL7ClinicalDocumentArchitectureE20]UN／EDIFACTMessagesMEDREQandMEDRPTr21]DICOM3．0'