临床检验结果共享互操作性规范

2
电子病电子病历历委员会系统委员会系统互操作性互操作性互操作性规范规范规范：：
4 临床检验结果共享
EHRSC Interoperability Profile: Clinical
6 Laboratory Test Results Sharing
8
文档号：EHR-SC-IP-001 Document No.: EHR-SC-IP-001
10
第0.8版，二零零七年九月十日
12 Version 0.8, September 10, 2007
14 电子病历委员会技术工作组
Technical Working Group, EHR Steering Committee
16
Document Revision History
18
文件修改记载 版本
Versio
n
Change Description 修改描述 编辑Editor 中文编辑 Chinese Editor 日期Date 0.1
Initial draft 原始草稿 YB 2006-12-29 0.2
Revised initial Chinese translation text and complete sections 1-4 YB TY 2007-3-3 0.3
LBL TY 2007-3-13 0.4
Delivered for EHR-SC review YB 2007-3-14 0.5 Removed terms “base standard” and “composite standard” Reorganized the section structure Editorial change to highlight that Chinese is the official version Completed Standard Gaps section Add Sequence Diagram in use cases YB 2007-4-11 0.6
Revised with inputs of Technical WG review YB 2007-5-12 0.7
Adopt the IP document to the new use case story structure YB 2007-6-25 0.8 Revised the document to integrate SC Tech WG feedback
discussed in July 2007 SC meeting YB 2007-9-10
20
Contents目录
22
1前言Foreword (4)
24
2临床检验结果共享系统互操作性规范引论Introduction (8)
2.1概述Overview (8)
26
2.2临床检验结果共享互操作性规范问题Problem (9)
2.2.1本规范的用例Use Case (9)
28
2.2.2Limitations本规范的局限 (11)
2.3本规范的解决方案概念Solution Concept (12)
30
2.3.1解决方案概要Solution Outline (13)
2.3.2解决方案的模式：基于文档 Solution Paradigm: Document Based (13)
32
2.3.3解决方案的前提假设 Solution Assumptions (14)
2.4Copyright Permission 版权许可声明 (16)
34
3本规范中引用的标准Standards References (17)
3.1List of Referenced Standards 本规范中引用的标准列表 (17)
36
3.2现有标准的空白 Standards Gaps (19)
4系统互操作性要求Interoperability Requirements (21)
38
4.1临床检验结果共享系统互操作性模型Lab Test Results Sharing Interoperability Model (21)
4.1.1模型概述Model Overview (21)
40
4.1.2临床检验结果报告发布用例Lab Test Result Report Publishing (24)
4.1.3临床检验结果报告定位用例Lab Test Result Report Locating (25)
42
4.1.4临床检验结果报告获取用例Lab Test Result Report Retrieving (26)
4.1.5临床检验结果报告就绪通知用例Lab Test Result Report Availability Notification (27)
44
4.1.6临床检验结果报告修订用例Lab Test Result Report Revision (29)
4.2交易包列表List of EHR-SC IPBB Transaction Packages (30)
46
4.2.1文档共享交易包Document Sharing Transaction Package (30)
4.2.2文档通知交易包Document Notification Transaction Package (30)
48
4.3独立交易列表 List of EHR-SC Independent Transactions (31)
4.3.1PIX 查询交易PIX Query Transaction (31)
50
4.3.2PDQ查询交易PDQ Query Transaction (32)
4.4组件列表List of EHR-SC Component (33)
52
4.4.1检验结果报告内容组件成Lab Test Results Report Content Component (33)
4.5互操作性规范构件的依赖关系 IPBB Dependencies (34)
54
4.6互操作性规范的约束 IPBB Constraints (35)
5用例动作和事件 Use Case Actions and Events (36)
56
6相容性要求Conformance Requirements (38)
7Appendix 附录 (39)
58
7.1Glossary 术语 (39)
7.2Audience 技术框架读者 (40)
60
7.3Conventions技术框架文体凡例 (40)
62
Open Issues:
64
7. Copyright of this document. Who owns the copyright of this document? This needs to be decided at
SC meeting. We need to identify sponsor of the EHR-SC
66
68
70
Closed Issues:
72
1. In this document, we introduced a new term Document Sharing Domain (DSD) to describe the
scope of participation organizations in sharing clinical document. This corresponds to IHE Affinity 74
Domain (AD) concept. Is it a right choice to invent the new concept DSD or we should use AD? –
We’ll use AD in English text, but call it 文档共享域 in Chinese text, or 共享域for short.
76
2. We reference PIX and PDQ IPBB as single transactions (IPT), to highlight that their direct use in
this IP is the query transaction. We assume that this is also most-likely used interface in other IPs.
78
Certainly, in order for the query transaction to work, the PIX manager / PDQ supplier needs other
transactions as defined in the IHE profile. The PIX and PDQ IPT will explain these conditions. Is this 80
is right handling or we should define these IPBB as IPPT to include the entire profiles? – We keep this IPBB structure for Lab IP.
3. IHE ATNA is an important profile. According to IHE XDS model, this is required for any actor
82
involved in XDS transactions. Our IPBB should include this statement (all IPBB: Document Sharing, 84
Document Notification, PIX, PDQ). We also mentioned this in the IP document. Should we do
anything more to highlight this requirement? If yes, how? – ANTA will be explicitly referenced in
86
each IPBB
4. The document is currently developed bilingual. Should we publish it bilingual or Chinese version 88
only? – Keep the IP document bilingual, but change the text organization to Chinese text first,
followed by English text.
90
5. We translated “Identifier” to 身份标识. Is the term 身份识别 better? – Use身份标识
6. We translated “Lab Report Locator” to 报告定位者, is the term 报告查寻者 better? – Use报告定92
位者
8. Dr. Zhang Lin asked to change “Clinical Laboratory Test Results” to “Laboratory Test Results”.
94
Should we do the change? Should we also change 临床检验结果to 检验结果in this text overall? – Keep use 临床检验结果. This corresponds to Clinical Lab Test Results.
96
1 前言Foreword
98
电子病历委员会（EHR SC）是由一些医疗保健服务提供者、专业机构、政府机构以及医疗信
息技术提供商在国家卫生部标准化小组领导下，于2006年共同发起成立的。

电子病历委员会100
的使命是促进电子病历（EHR）在中国医疗卫生系统中的应用，以达到基于开放工业标准对患
102
者的长期、完整健康记录进行交换和存取的目的。

为了达到这一目的，电子病历委员会的近期
目标是为一个区域性健康信息共享模型开发在不同医疗信息系统和医疗保健服务组织之间的互
104
操作性标准规范。

这个区域性模型包括不同层次的医疗服务提供者（例如全科医生、服务站
（点）、社区服务中心、医院等），医疗服务消费者、医疗服务监管和决策机构和公共卫生管
106
理部门。

The EHR Steering Committee (EHR SC) was initiated by a group of healthcare providers, professional societies, 108
government agencies and IT vendors, under the leadership of the healthcare IT standard group of the Ministry of Health (MoH), in 2006. The mission of the EHR SC is to promote electronic health record (EHR) applications in 110
Chinese healthcare systems for interchange and access of longitudinal patient health information based on open industry standards. To achieve this goal, the EHR SC has set its near-term focus on a regional health information 112
sharing model by developing standard specifications for the interoperability across diverse healthcare information systems and organizations. The regional model includes various-level health service providing entities (e.g.,
114
general practitioners, service station, service centers, and hospitals), consumers, healthcare authority
organizations as well as public health agencies.
116
电子病历委员会不是一个为了在医疗卫生信息技术领域中开发制定新的标准的标准开发组织。

相反，它采用一个标准协调的方法来更有效和一致地利用现有的工业标准解决医疗卫生领域中
的系统互操作性问题。

它在各个专门临床领域应用中通过对现有标准的选择和规范，开发电子118
病历委员会系统互操作性规范（EHR-IP）。

每个EHR-IP都针对某个经过广泛论证的临床用
120
例，包括一组经过仔细规范的标准，以及它们在该EHR-IP环境中为解决它所针对的用例问题
如何使用和相互连接以达成信息流连续的详细规定。

122
The EHR SC is not a standard making group for developing new standards in healthcare IT. In contrast, it adopts a standard harmonization approach to make more efficient and consistent use of the existing IT industry standards 124
and solve the system interoperability problems in healthcare. The EHR SC develops Interoperability Profiles (IP) in specific clinical domains based on widely recognized use cases, by selecting and profiling the existing standards. 126
Therefore, an IP consists of a set of carefully profiled standards, detailed specifications of their application contexts and purposes, and as well as their interconnections for information continuum.
128
电子病历委员会对系统互操作性规范的开发包括以下几个步骤：
The EHR SC approach of developing an IP consists of a number of steps:
•确定临床领域中患者临床信息交换和存取的关键用例。

这些用例应当对提升患者价值130
和中国医疗卫生服务体系及其改革的业务需求具有重大的影响。

对每一个用例，电子132
病历委员会计划开发一个EHR-IP来解决相应的问题（如果将来用例内容得以扩展，我
们可能扩展已有的EHR-IP，或开发一个新的EHR-IP处理新的需求）。

134
Identifies the key use cases of interchange and access of patient clinical information in a clinical domain.
These use cases are recognized with a high impact on improving the patient value and business needs in 136
the Chinese healthcare delivery system and its reform. For each use case, an IP is planned (if a use case
is extended in the future, the existing IP can be expanded, or new IP can be added to address the new 138
needs).
•被选中开发EHR-IP的用例被细化归纳成一系列的工作流程步骤，并确定那些和医疗信140
息交换和共享以及其他互操作性任务有关的步骤（其他步骤和互操作性无关）。

所有
的互操作性任务都从整个医疗保健过程的普遍角度加以抽象来建立EHR-IP模型，从而142
可以在不同的用例中共享和再利用这些任务描述，用以建立其他EHR-IP的模型。

Refines the use case into a sequence of steps, and identify the steps related to healthcare information 144
interchange or other interoperability tasks. The tasks are described in an abstract manner from the entire
healthcare universal aspects to model the IP, and therefore can be shared / reused in different use cases 146
as part of the models of other IP(s).
•针对在需要开发的EHR-IP中确定的互操作性任务进行有关的医疗卫生信息化和通用信148
息技术工业标准的评价和论证，并选择恰当标准去解决每一个任务中互操作性问题。

如果需要，对所选择的标准为相应的任务背景开发扩展和限制（这叫做标准规范过150
程），以最好地满足这些互操作性任务。

这些互操作性任务的解决方案叫做互操作性
规范构件（IPBB）。

152
Performs an assessment and evaluation of the existing healthcare or general IT standards for the
identified tasks, and selects appropriate standards for the resolution of the interoperability problems in 154
each task. If needed, develop corresponding extensions and constraints to the standards (this is called
profiling process) in the specific task context for best fulfilling the task. These solutions to tasks are called 156
an Interoperability Profile Building Blocks (IPBB).
•如果标准评价和论证过程的结论是针对需要解决的问题没有合适的标准存在，确定现存标准的空白区域。

电子病历委员会处理标准空白区域的方法包括：1）描述记录现存158
标准的空白并定义推荐临时解决方案，2）确认最接近解决方案的现有标准并向该标准160
的制订组织递交修改意见，3）如果空白区域很大，没有临时方案可供选择，推迟计划
的EHR-IP开发。

162
Identify the standard gaps, if there is not appropriate standard existing for an interoperability task. The
EHR SC may handle the gaps in a number of possible ways: 1) document the gaps and recommend 164
workaround in the IP if the gap is not substantial, 2) submit change request(s) to the standard making
group who owns a standard which is most close the required one, 3) postpone the IP development if the 166
gaps are substantial (workaround does not work).
•在统一的电子病历委员会技术框架内，通过引用目标用例中所涉及的互操作性任务的168
解决方案（IPBB）和定义这些任务解决方案在本IP的背景下的相互连接关系，来开发
定义相应的EHR-IP。

170
Develops the IP by referencing these task solutions involved in the target use case, and by defining the
interconnection of these task solutions in the IP context in the unified technical framework.
172
在每一个EHR-IP中，EHR-SC对所选定的用例的各参与方规定系统互操作性要求，使它们能在共同的语意下交换信息。

但是，EHR-IP既不要求也不限制各方内部的功能行为，除非某个174
功能行为和系统互操作性要求如此紧密相关，以致于它事实上是系统互操作性要求的一部分。

如果一个EHR-IP由于系统互操作性要求的完整性必须规定各参与方的功能行为，这种功能要求在EHR-IP中应当限制在最小程度。

176
In an Interoperability Profile, the EHR-SC specifies the system interoperability requirements for various parties 178
involved in the identified use case for them to interchange information with the commonly agreed semantics. But the Interoperability Profiles neither require nor restrict functional behaviors inside of the parties, unless a functional 180
behavior is so tightly bundled with the interoperability requirements, that it actually becomes part of the
interoperability requirements. If an Interoperability Profile must specify some functional behavior in order to
182
complete the interoperability requirements, the functional specification shall be restricted to minimum.
电子病历委员会的每个系统互操作性规范通过引用IPBB对在目标用例中确定的互操作性问题184
定义解决方案。

每个EHR-IP事实上代表着一组技术文档。

EHR-IP技术规范（本文）是EHR-IP的最高层文档，它描述了该EHR-IP中所有引用的IPBB，它们在目标用例中的应用背景、186
条件和相互之间的关系，以及它们如何协同工作对目标用例提供解决方案。

关于IPBB的具体技术定义和要求，EHR-IP技术规范引用IPBB自己的技术规范文档。

IPBB的技术规范则包含了对一个或多个现有工业标准的进一步规范和限定。

图一显示了EHR-IP技术规范、IPBB技术188
规范和被引用的工业标准之间的关系。

EHR-IP的实现者或其他读者需要阅读一个EHR-IP所引
用的相应的IPBB技术规范文档，以理解该目标用例中各个互操作性任务的要求和解决方案的190
技术细节
192
Each EHR-SC Interoperability Profile specifies a solution set to the interoperability problem(s) identified in the
target use case by applying the solutions to each interoperability task in the case as developed in the IPBBs. The 194
EHR-IP document actually represents a suite of technical documents. The technical specification of the EHR-IP (this document) is the top-level document of the EHR-IP to define the application context and the interrelationship 196
of these IPBBs in this use case, and how they work together to provide the solution set on the use case level. It references the IPBB’s own technical specification for the detailed technical definition of each IPBB, which is
198
specified by profiling one or more selected standards. Figure 1 shows the relationship of all documents defining an EHR-IP. An implementer needs to read the corresponding IPBB specification documents referenced in an EHR-IP 200
to understand the technical details for the requirements and solution of each individual interoperability task
involved in the use case.
202
图一：EHR-IP所包含的技术文档和它们之间的关系
standard (called Base Standard in this document, e.g., HL7 V3, DICOM, SNOMED CT, etc.) or a piece of
224
information interchange and access , or other interoperability specification in some derived standards (called
Composite Standard in this document, e.g., HL7 or other standards Implementation Guides, IHE, etc.). The EHR 226
SC IPBB documents will list these (base or composite) standards, and their profiled specifications in the EHR SC technical framework. An IPBB can be:
228
•一个经过规范的标准消息内容（加载在消息交易过程中）， 一组从某个行业标准术语系统中选出的代码，一个安全措施的定义，等等。

230
A profiled message content (payload carried on in a message transaction), a set of codes drawn from an
industry standard vocabulary system, an arrangement of security measures, etc.
•一个IHE集成规范中的一个交易，一个或多个IHE集成规范中的一组交易，等等。

如232
果需要EHR SC的IPBB可以对这些复合标准中施加另外的约束和扩展。

234
A profiled use of a transaction of an IHE Integration Profile, a group of transactions in one or more IHE
Integration Profiles, etc. If needed, EHR SC IPBB may apply additional constraints or extension to these 236
composite standards.
电子病历委员会IPBB技术文档仅引用它们所使用的标准。

IPBB技术文档直接说明的是这些标238
准在电子病历委员会相关用例中具体的应用背景，和为满足该应用背景在相应的电子病历委员会IPBB而引入的限定。

IPBB技术文档不会重复这些引用的标准的技术定义。

关于这些标准的240
细节，读者可以参考它们自己的技术文档。

如果没有明确指出，所有对这些标准引入的限定都应当和原有标准兼容，即定义在原有标准的技术容忍范围以内。

242
The EHR SC IPBB documents only reference the base / composite standards that they use, and include only the EHR SC Use Case specific application context of these standard IPBB, and additional constraints developed to the 244
base / composite standards to satisfy the use case requirements. They do not duplicate the technical specification of these referenced standards, and the reader is referred to their own documents for details of these standards. If 246
not explicitly pointed out, all constraints added to the referenced standards shall be compliant to these standards.
2 临床检验结果共享系统互临床检验结果共享系统互操作操作操作性规范引论性规范引论Introduction 本文根据电子病历委员会的临床检验结果共享用例文档 [EHRSC-UC-001] 中所列出的要求，定248
义了在医疗保健系统之间相互交换和共享临床检验结果报告的解决方案。

本节将讨论该解决方案的概念性描述，以及它所支持的临床检验结果共享用例和尚需将来填补的空白。

详细的技术250
规范和要求将在第四节讨论。

This document specifies a solution set for healthcare systems to interchange clinical laboratory test results report, 252
according to requirements stated in the EHR SC Lab Test Results Sharing Use Cases document [EHRSC-UC-001]. This section provides a conceptual description and general assumptions of the solution set, the requirements of 254
the use case document that has been addressed, as well as the gaps that need to be filled in the future IP work.
Detailed technical specification and requirements will be discussed in Section 4.
256 电子病历委员会的临床检验结果共享用例文档定义了一组在不同应用目的使用者之间分送和共享患者临床检验结果的用例，包括当前下达的临床检验检查要求和既往病史中临床检验要求。

258
临床检验结果共享用例不涉及与检验项目的下达、标本处理与追踪、检验的完成和认证等相关的工作流程。

260
The EHR-SC Laboratory Results Sharing Use Cases document describes a set of use cases about the dissemination and sharing of the lab results to different receipts for their own application purposes. This includes 262
the results of currently ordered lab tests as well as the historical records of the previous lab test results. Lab test
related workflow issues (like lab order, specimen management and track, order fulfilling, etc.) are out of the scope 264 of these use cases.
2.1 概述Overview 266
电子病历委员会的临床检验结果共享用例文档描述了两段检验结果共享的故事情节： The EHR-SC Laboratory Results Sharing Use Cases document describes two stories of lab test results sharing: 268 • 故事情节1：患者的社区医生在社区中心下达了患者的检验项目医嘱。

该检验项目在和社区中心建立了业务关系的实验室执行。

检验完成后，实验室直接将结果发给下达270
检验医嘱的医生。

Story #1: A test order for a patient is placed by his physician in a community healthcare center. The test 272
is performed by a test laboratory which has established business relationship with the center. After the
completion of the test, the laboratory sends the test results directly to the ordering physician.
274 • 故事情节2：患者参加了社区医疗中心的慢性病管理计划，所有的检验结果都保存在中心的电子病历系统中。

社区中心和一家医院在共同商定的治理政策下建立了患者转276
诊和健康信息共享的业务关系。

当患者在另一段医疗场景内在医院就诊时，医院的医生需要调看患者以前的检验结果。

278
Story #2: A patient participates in the chronic disease management program of a community healthcare center, and has all lab tests performed in the center stored in its EHR system. The community center has 280
established business relationship with a hospital for patient referral and health information sharing under agreed governance policies. When the patient is admitted in the hospital for another care episode, the 282
physician in the hospital needs to review the results of his historical tests orders. 另外，电子病历委员会用例文档还包括了二段与检验结果共享有关，但不包括在本规范范围的284
故事情节（详见[EHRSC-UC-001]）： In addition, the use case document also discussed two other stories of lab test results sharing, which are not 286
included in the scope of the current EHR-IP, but may be addressed in future EHR-IP work (see [EHRSC-US-001]
for detail):
288
•故事情节3：医生要求患者进行一项医生自己的机构没法执行的检验。

于是，患者自290
己决定在一家医院或医疗服务中心找另外医生作此检验，检验医嘱下达的医生和真正
要求该检验的医生没有任何关系。

最后的检验结果需要提供给最初要求检验的医生
（下达检验医嘱的医生可能对结果根本没有兴趣）。

292
Story #3: A patient is requested by a physician to perform a lab test but the physician is unable to order 294
the test. The test is then ordered by another physician in a separate hospital or service center. The test
results need to be made available to the physician originally requested the test (the ordering physician in 296
this case may be not interested in the results at all).
•故事情节4：医疗保险公司为其客户提供个人健康记录（PHR）服务。

保险公司的PHR 298
系统从全国不同的医院收集检验报告，向它的客户提供各自的检验结果长期记录。

Story #4: A health insurance company provides a Personal Health Record (PHR) service to its customers. 300
The PHR system collects the lab test results from different hospitals, and presents them to the customers
as a longitudinal set of records.
本规范定义了一套基于在多个参与方之间共享文档的概念的解决方案（详情见第2.3节）来满302
足这些故事情节的要求。

第2.2节讨论了一般的抽象化的用例描述本方案的典型应用场景。

整304
个用例基本上围绕故事情节2展开，但也覆盖故事情节1的要求。

而且，如果所有有关医院都能加入共同的文档共享域，本规范所定义的解决方案也能应用于故事情节4中的PHR系统。

306
由于检验结果源和检验结果用户之间不存在业务关系的事实，本规范不包括对于故事情节3的解决方案。

308
This EHR-IP specifies a solution set based on the concept of document sharing across a number of participating parties (see Section 2.3 for details of the solution concept), which addresses the requirements of these in-scope 310
stories. In Section 2.2, a generalized use case is created to describe the typical application scenarios supported by the solution. The whole use case is basically organized around story #2, but covers story #1 too. In addition, if all 312
hospitals can join into the same domain of document sharing, the solution specified in this EHR-IP can be also
applied to story #4. Because of the fact that there is no business relationship between the lab results source and 314
the consumer, this EHR-IP does not include a solution to story #4.
基于文档共享的方案并不能处理所有可能的临床检验结果分发使用场景（包括那些电子病历委316
员会的临床检验结果共享用例文档没有描述的场景），或者可能以一种变通的方式处理某些场景，可能也可能不满足那些场景的要求。

第2.2.2节会讨论这些局限。

电子病历委员会将来的318
工作会扩展本规范的范围或开发新的规范克服这些局限。

The document-sharing based solution cannot address all possible use scenarios of lab test results dissemination 320
(including those not covered in the EHR-SC Laboratory Results Sharing Use Cases document) or can address
some scenarios in an alternative way which may or may not satisfy all of the original requirements of these
322
scenarios. These limitations are discussed in Section 2.2.2, and future EHR-SC work may expand the scope of this IP or develop new IP to overcome the limitations.
2.2 临床检验结果共享互操作性规范问题Problem
324
本节讨论本规范所支持的用例和本规范尚未涉及的局限。

326
The section discusses use cases supported and the limitations not addressed in this IP.
2.2.1 本规范的用例Use Case
328
在本规范中定义的互操作性方案由一系列信息交换交易组成。

以下例子流程描述了本规范致力于满足的抽象情节展板，它覆盖了电子病历委员会检验结果共享用例文档中的所有故事情节的330
互操作性要求。

该流程也具体说明了本规范中的交易是如何相互合作来解决跨越不同系统界限共享检验结果的问题的。

332
The interoperability solution defined in this IP includes a number of transactions (IPBB). The following example
flow describes an abstract storyboard that this IP devoted to address. The storyboard covers the interoperability 334
requirements of all stories in the EHR-SC Laboratory Results Sharing Use Cases document. The flow also shows how the transactions of this IP collaboratively operate to solve the problems of sharing a patient’s test results
336
across the boundaries of various systems.
•患者唐霞娣被陈其康医生（她的社区点初级保健医生）转诊介绍给市人民医院的方进338
安医生。

方进安医生给唐女士开出全血细胞计数的化验单，并要求让陈其康医生在化
验结果出来后得到结果。

市人民医院的化验申请单管理系统把这个检验项目发给精密340
实验室，并在那里完成检测。

注：患者的转诊和检验项目申请的过程没有包含在本互操作性规范中。

342
Patient Tang Xiadi was referred by Dr. Chen Qikang (her community site physician) to the Municipal
People’s Hospital. Dr. Fang Jingan placed a Complete Blood Count (CBC) test order for Ms. Tang, and 344
requested that Dr. Chen should receive the test report when it is available. The order management
system of the Municipal People’s Hospital routed the order to Precision Laboratory, which performed the 346
test.
Note: This step of patient referral and test ordering process is not covered in this IP.
348
•精密实验室完成了该检验项目，并用其检验结果数据生成了一个临床检验报告。

由于该报告是由实验室技师认证，还没有经过临床检验大夫的认证，所以检验报告被标记350
为初步报告。

精密实验室根据市人民医院临床文档共享域规定的安全和管理政策发布
了该报告供共享域中医疗保健服务提供者所共享。

352
Using the test results data, the Precision Laboratory created the lab results report. Since the data had
been verified by a lab technician but not yet by a staff physician, the report was marked as Preliminary 354
Report. The Precision Laboratory published the Preliminary Report for sharing across providers under
the local security and administration policies.
356
•根据检验项目医嘱中的要求，精密实验室发送通知给方医生，告知他所下达的检验项目结果初步报告已完成，可以被参考使用了。

358
According to the request in the test order, the Precision Laboratory sent a notification to Dr. Fang that the
preliminary results of the ordered test had been available for review.
360
•方医生使用他的电子病历系统向市人民医院的临床文档查询系统要求查阅并获取唐女士最近的的临床检验结果报告。

通过显示阅读该检验报告，方医生知道这个检验报告362
的检验结果是初步结果，它需要被最后认证。

看过报告之后，为了给唐女士制订治疗
计划，他需要调阅唐女士更多的既往全血细胞计数结果和其他相关检验结果。

于是，
他再次查询临床文档查询系统，并获得了这些检验结果供参阅。

364
Dr. Fang used his EHR application to query the Document Locator service in Hospital Well Health and 366
retrieve the report for display. By reviewing the report, Dr. Fang noticed that the report contained
preliminary results of the lab test, which needed final verification. After reading the report, he decided that 368
more historical data of the CBC and other related tests would be needed for making a care plan for Ms.
Tang. He then queried the Document Locator service for these previous lab test results and retrieved 370
them for review.
•第二天，精密实验室完成了初步报告中检验结果的最后认证。

两项检测数据被修正，372
精密实验室的医生签发了全部结果。

然后实验室发布了此项化验的新版结果报告作为
最终检测结果报告。

新版报告被正式标记成项检验的最终报告，同时替代事先发布的374
初步报告。

In the second day, the Precision Laboratory had finished the final verification of the test results reported 376
in the Preliminary Report, two measurement data items had been revised and the report was finally
signed by a staff physician in the laboratory. It then published the Final Report as a new version of the
378
results of the same lab test order, which replaced the previously published Preliminary Report, was
marked as Final Report.
•与通知初步报告就绪的方式类似，精密实验室向市人民医院的方医生发送了唐女士的380
检验结果最终报告（修正版）就绪的通知消息。

由于方医生在最初下达检查项目医嘱382
时也同时要求将最终结果报告送给社区点的陈其康医生，同样的通知消息也发送给了
陈医生。

384
In the similar way of notifying Dr. Fang about the availability of the preliminary report, the Precision
Laboratory sent a notification message went to Dr. Fang about the availability status of the final test
386
report. In addition, in his original test order placement, Dr. Fang also requested to make the final results
available to the primary care provider of Ms. Tang (Dr. Chen Qikang). Since this is the final report, the 388
same notification message was also sent to Dr Chen at the community site.
•在临床文档查询系统中，初步报告被最终报告所代替。

虽然初步报告仍然可以被上级390
主管机构以及其他被授权的机构查看（例如，出于质量控制和质量保证的目的），但
是对于普通用户的查询要求，临床文档查询系统自动返回唐女士该检查项目的最终报
告作为这次全血细胞计数的唯一被发布的结果。

392
In the Document Locator service, the Preliminary Report had been (logically) replaced with the Final 394
Report. Though the Preliminary Report would be still available for administrative or other specifically
privileged use (e.g., for QC/QA use), the only results of the CBC test of John Doe would be available 396
through the Final Report.
•方医生查询并收到了最终检验报告。

用这个被确认的检验报告，方医生就可以为唐女士调整治疗方案了。

398
Dr. Fang queried and retrieved the Final Report. With the final verified lab test results, He might adjust 400
some of the care plan to Ms. Tang.
•唐女士回到了她所居住的社区。

陈医生已经下载了她在医院的检验结果，并继续为唐402
女士提供社区初级医疗服务。

Ms. Tang returned to the community where she lived. Dr. Chen had already retrieved her test results in 404
the hospital and continued to provide the primary care services to Ms. Tang.
上述流程中包括了检验结果共享过程中的一些可选步骤。

这些步骤在不同的医院或社区中心里406
可能需要，也可能不需要。

例如，在一些医院里在检验结果最终审签以前，不会发布初步报
告。

另外，在检验报告产生管理者与检验报告使用者之间有其他通信传输机制的情况下，检验408
报告的就绪通知也可能不需要使用。

The flow given above includes a number of optional steps in the process of publishing lab test results for sharing, 410
which can or cannot be needed in different hospitals or community centers. For example, in some hospitals, a
preliminary report will not be released before it becomes final. The report availability notification may not be used if 412
there are other mechanisms for the communication between the test results producer / manager and the desired report recipients.
的局限
2.2.2 Limitations本规范
本规范的局限
414
第2.2.1节所描述的基于文档模式的流程能够支持检验结果共享的许多使用场景，但并不一定覆盖临床实践中与检验结果分发有关的所有要求。

特别是，本规范尚不直接支持下列使用场416
景：
418
The flow of the document-based paradigm described in Section 2.2.1 supports many use scenarios of test results sharing, but not necessarily covers all possible requirements in the field related to lab test results dissemination. In 420
particular, the following use scenarios are not directly covered in this IP:。