FHIR常见场景
作为一项框架标准，FHIR定义的是一种用于解决各种医疗保健服务问题的通用方法，并且还提供了一套可采取许多不同方式加以利用的资源。本页面描述的是如何利用FHIR所定义的这些能力来实施某些常见的应用场景。这里所提供的这些场景仅仅是应用示例，但无论如何都并非详尽无遗。应用FHIR的情况可以有且也将有多种多样。
目录
个人健康档案（Personal Health Record，PHR）
在PHR场景当中，电子病历系统（Electronic Medical Record system，EMR）负责提供一种RESTful API，从而让患者能够通过常见的网络门户或移动应用程序（通常由第三方提供）来访问自己的病历资料。在此场景下，PHR提供方负责：
- 为患者提供用于标识身份的相应登录账户（或者，将病历链接到OpenID、Facebook、Google之类所提供的外部身份标识之上）
- 针对相应的登录账户（也可能是PHR提供方自己所提供的），利用合适的OAuth服务器对客户端加以身份验证，并使客户端仅限于查阅与当前特定患者相关联的记录（在分配了合适的访问权限的情况下，亦可访问多位患者的资料）
EMR还公开提供了一个FHIR服务器，而后者则支持针对下列资源的search（搜索）和read（读取）操作：
- 患者资源patient：用于向客户端提供患者的基本信息（人口统计学信息）。如果客户端在搜索患者时并不采用搜索条件，则会获得一张其具有相应访问权限的所有患者的列表。
- 文档引用资源DocumentReference：对于这种资源的search（搜索）和read（读取）操作，将会提供对于PDF之类形式的通用患者文档的访问能力（首选PDF格式）
- 临床类资源（clinical resources）：对于这套资源进行search（搜索）和read（读取）操作
如下则是本场景的符合性声明（conformance statement）：
XML或
JSON
同时，EMR还可以选择提供额外的功能，如让患者亲属/照护人员共享对于相应患者记录的访问权限，从而让患者能够上载自己的文档、用药声明（medication statement）和观察结果（如来自于患者的监测装置）和/或允许患者安排预约事宜。这些额外的功能将涉及到要实施和公开提供额外的API能力。EMR服务器还可以选择为患者特有的记录公开提供针对安全性事件资源（Security Event）的search（搜索）、read（读取）和history（历史）操作，从而让患者能够审查记录访问权限。请注意，在安全性事件资源SecurityEvent之中，应当对RESTful API的所有使用情况进行日志记录。
文档共享（Document Sharing，XDS）
对于形形色色来源的医疗保健服务信息，一种常见的集成方法就是，围绕患者的病历，建立一个文档存储库。这种构建文档存储库的方法，允许不是那么严格地遵循相应的政策、操作规程以及记录保管和信息学方面的标准。
在组织机构、区域/地区、州/省市自治区或者国家/地区范围内，采纳最为广泛的文档共享框架就是IHE的跨机构文档共享规范（Cross-Enterprise Document Sharing，XDS）。XDS允许或者说考虑到了利用配备有注册库（registry）的邦联式存储库体系（federated system of repositories）来提供对于医疗文档的访问能力。
FHIR提供有与XDS等价的功能，可用于在已有的XDS.b接口背后实施XDS，从而为已有的XDS生态系统提供更为简单的移动友好型接口（mobile-friendly interface），或者是将文档共享链接到采用FHIR接口所提供的其他功能当中。
XDS功能当中涉及到下列FHIR资源：
- 文档引用资源DocumentReference 用于描述位于别处的文档。文档注册库（document registry）指的是用于维护一套文档引用信息的系统。
- XDS概貌资源（XDS profile）旨在为较为通用的文档引用资源DocumentReference提供具体的XDS实施细节
- 二进制资源Binary 可用于在FHIR服务器上存储实际的文档。文档存储库（document repository）指的是用于存储二进制文档以及文档引用信息（有时没有后者）的系统
- 患者资源Patient、执业人员资源Practitioner 及组织机构资源Organization 提供的则是对于人员和组织机构身份标识的支持
- 安全性事件资源SecurityEvent负责跟踪记录文档注册库和存储库的使用情况
目前，IHE正在与FHIR项目团队开展合作，旨在将FHIR技术规范用于移动式访问健康文档（Mobile access to Health Documents，MHD，移动式健康文档）。
决策支持
医疗保健信息系统的一种常见用途就是，将某种形式的决策支持软件集成到临床系统当中。临床决策支持（clinical decision support，CDS）的常见用途包括：
- 药物-药物相互作用检查以及更为广义的处方安全检查
- 提出常常缺失的诊断数据解释（包括差别检查）
- 开展患者监护（surveillance），以便早期预警患者健康的恶化（包括在急诊照护和流动照护方面）
- 为改善服务/治疗效能，确定适合作为备选的治疗计划/方案
注意，除了临床决策支持，同时在基础结构/基础设施方面也有运用，如对于访问控制方面的管理。
各种形式的决策支持分别涉及到不同的交互模式，因此，在FHIR技术规范当中，并没有什么单一的决策支持实施方式。总体而言，这些交互模式分为如下几类：
- 决策来自于完全隐藏在特定系统接口背后的某个引擎，并且对于数据交换没有任何直接的影响
- 决策支持引擎利用已有数据并产生关于患者状态的警示消息，而这些消息在FHIR接口上是可见的
- 对于决策支持引擎的查询是借助于某个经过描述的接口；该引擎接受关于特定决策的请求，并返回某项决策
根据特定系统视角/观点的不同，任何决策支持都可能同时归属多个类别。
- FHIR技术规范当中并没有要求任何具体的支持，尽管将会对资源内容进行持续不断的审核，以便保证它们能够为常见的决策支持实践活动提供合适的支持。
- 目前，还没有适合于这一用途的资源。警示资源Alert旨在用于关于当前患者的临床记录（clinical notes），而并非用于决策支持目的。正在为当前用途而准备的是一种称为警告“Alarm”的资源。
- 关于特定决策支持的请求则被理解为利用具名查询（named _query）的搜索操作search ，而这种具名查询又要采用一套参数。参见下文。
对于决策的明确请求
当为了做出一项决策而开始特定查询时，适合考虑下列事项：
请求
- 关于特定决策的请求的提出将利用的是为搜索/查询（search/query）操作所描述的那些交互模式之一：RESTful搜索、投递到邮箱/Mailbox之中的查询、查询消息（query message）或者是异步式查询模式（Asynchronous query pattern）
- 查询具有一个查询参数 _query，且该参数用于标识当前所请求的决策
- 请求还具有一套参数取值。这些参数取值可以是用来描述所做决策的数据，或者也可能是对那些其中包含当前请求的具体资源的引用。总体而言，决策请求越是复杂，越是可能某种完整的资源是合适的，尤其是因为这样就提供了一种现成的方式，可以用来记录和管理此类请求本身。
- 在某些查询交互模式中，可以利用相应请求，将参数取值之中所标识的那些资源捆束起来。在其他查询交互模式中，则只能传递那些引用。
- 究竟哪种查询模式最为合适，这要取决于决策支持输入的复杂性以及预期相应决策所要花费的时间长短。随着后两者的增加，较为复杂的查询模式就会变得更为合适。
响应
- 如果决策支持引擎无法提供所请求的决策，则它会返回一个操作结局资源OperationOutcome，用于描述当前的问题事项。
- 否则，该引擎就会返回一个用于表达相应决策的资源，并按照该资源或适用概貌的描述，同时配以其他作为支持型信息的资源。
- 原则上，决策提供方可以选择通过正常的RESTful接口，为所返回决策资源提供一份副本；但也可以选择不这么做。这项决策可以受到适用概貌、政策决策或相应查询内在性质的制约。
- 如果决策提供方或者是请求方选择为当前决策保留的一份副本，则他们必须保证，在使用该决策的时候，会适当地考虑到该决策的现时性（currency）或者说其缺乏现时性。
由此，那些可能获得请求的决策就需要至少定义一种响应资源，并且可能还有一种请求资源。如下表格概括总结了当前已经定义了相应资源的已知决策。
| 决策 | 资源 | 调用 |
| 当前患者应当接受哪些免疫接种？ | 响应：免疫接种建议资源ImmunizationRecommendation | 目前尚未定义调用这种决策的确切方法 |
允许实施者将已有资源用于此处并未记载的决策，但并不保证这些资源就会合适。在FHIR技术规范试行期间，决策支持方面的改进将是持续进行的开发编制工作的一个关注焦点。
原文链接
- 2.12 Common Scenarios in FHIR - Continuous Integration Build （访问时间：2014/10/14）
参阅
