I have written a couple of blogs previously to introduce FHIR, including 5 Things to Know About HL7 FHIR and Review of the HL7 FHIR Session at HIMSS13. This standard is evolving steadily within the HL7 organization. The first Draft Standard for Trial Use was available in 2014, and the first normative edition is planned for 2017.
HL7 FHIR plans to support four interoperability paradigms, which are distinct ways of utilizing FHIR to best accommodate varying workflows. The four paradigms and when they might be used are:
-
rest – small, light-weight exchanges with low coupling between systems -
messages – communicate multiple resources in a single exchange
-
documents – focus is on persistence when data spans multiple resources
-
services – use a custom service when capabilities of other paradigms don’t fit requirement
regardless of the paradigm, the content is still based on resources. the resources are just bundled into different data sets depending on the paradigm. below, i outline some of the key differences among the paradigms.
paradigms defined
rest
- simple, out-of-the-box interoperability
- leverage http: get, post, etc.
- pre-defined operations
- create, read, update, delete
- works best in environments where control resides on client side and trust relationship exists
messages
- similar to hl7 v2 and v3 messaging
- a bundle of resources
- allows request/response behavior
- event-driven (e.g., send lab order, get back result)
- can be asynchronous
documents
- similar to cda
- a bundle of resources
- root is a “composition” resource that acts like a cda header
- one context
- can be signed, authenticated, etc.
services
- custom resource packaging and intelligence/individual resources or bundles
- ultra-complex or ultra-simple workflows
- use http or other protocols
- only constraint is that fhir resources are passed from one system to another
one key element to point out is that regardless of the paradigm, the content is the same. this means that it is straightforward to share content across these paradigms.
for example, an application might receive a lab result message and turn around and package it in a summary of care document. in addition, constraints can be shared across paradigms. for example, a profile can be established for blood pressure and used in all of the domains discussed above.
fhir is meant to be flexible to use and easy to implement. fhir does not care about the architectural design of the systems. it works equally well for light (mobile) clients and heavy (infrastructure) clients. it can be used for push-based requirements or query-based requirements.
fhir is promising in many different ways and it will be interesting to watch as it develops and more folks voice their praises and concerns.
