工作组: FHIR Infrastructure 标准状态: Informative

FHIR标准是作为一个接口规范来设计的,它规定了医疗行业软件之间交换的数据内容与格式,并描述了如何实现与管理这些交互。包括以下5种交互方法:

以上的方式都可以独立的用于数据交换,它们各自都有着自己的适用场景和优缺点。请注意,软件系统之间的数据资源交换可以使用其他任意的方法,本规范中描述的这5种方法是最常用的,它们的运用已经很成熟并有标准的用法。

Most implementers focus on RESTful API. This is a client/server API designed to follow the principles of RESTful design for Create, Read, Update and Delete operations, along with Search and Execute (Operations) support.

The RESTful API is a general-purpose interface that can be used to push and pull data between systems. Which is appropriate depends on architecture and deployment considerations. The RESTful API also supports Asynchronous Use and GraphQL.

In addition to the RESTful API, a messaging exchange framework is documented, which supports exchange between systems by sending routed messages from system to system. This exchange can be implemented on the RESTful API or using some other messaging technology.

Implementers should note that the messaging framework is not provided to fill any functional deficiency in the RESTful API (or vice versa), these frameworks are provided to allow implementers to choose how to exchange content based on their own architectural and deployment considerations. Messaging may be more suitable for exchange between disparate organizations with low levels of process integration and/or trust.

This specification also defines a document based exchange framework, where content to be exchanged is wrapped by a Composition that provides the context of the content, and that has a fixed presentation for a human reader. The document framework is provided to help with computer-assisted human to human communication uses - which are not uncommon in healthcare.

通常,文档交换用于跨临床管理边界的临床信息交换(主要用于机构之间的数据交换),而RESTful API是基于数据的交换,它适用于临床管理统一的情况(主要用于同一机构或医共体内的数据交换)。

In addition, this specification describes the use of FHIR in a services framework(e.g. a SOA). Note that any use of any of the above approaches in production is a 'service' by some or many definitions. The services description provides context regarding the use of FHIR (and particularly the RESTful API) in a wider enterprise architecture.

利用“中间库”也可以实现FHIR资源的数据交互,即将FHIR资源存储在本地数据库或持久性存储中,不同的应用程序或系统模块通过数据库读写资源。以这种方式使用资源的介绍请参见 在持久化存储中使用FHIR

All forms of data exchange should be appropriately secured. This requires the following:

  • Only the parties to the exchange can access the communication
  • The parties are authenticated and authorized as required
  • Access control always checks that the only the appropriate data is exchanged
  • Appropriate patient consent has been obtained for the exchange

This subject is described further in the Security Page.

With regard to the RESTful API, implementers should always consider the Smart App Launch protocol as part of the overall secure API approach

RESTful API This is stable and currently being balloted as Normative. No breaking changes are expected. No significant development is planned, but HL7 will continue to respond to user experience
Messaging Messaging has only be implemented in a few projects; some of the infrastructure has not yet been used in production. It is not clear whether significant development will be needed or appropriate
Documents Documents have mostly only been used in prototype projects, though there is considerable impetus around implementation at this time. No significant development is planned, but HL7 will continue to respond to user experience
Services At this point in time, it's not clear whether further work is required or appropriate in terms of service orientated architecture / enterprise integration. HL7 will continue to monitor implementer experience and feedback
Database / Persistent Storage This is a new area with considerable action at this time, and many production implementations, though RDF itself is not getting much use. At this time, HL7 is monitoring implementer experience and feedback to see whether additional standardization is required

Trial-Use Note:

Note to balloters: There's some interest in standardizing the use of ProtocolBuffers directly in the specification itself (basis ). Ballot comments are welcome.