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 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... organization. The first Draft Standard for Trial Use was available in 2014, and the first normative edition is planned for 2017.
FHIR stands for Fast Healthcare Interoperable Resource. This emerging standard combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services. With REST... plans to support four interoperability paradigms, which are distinct ways of utilizing An HL7 standard that is short for Fast Healthcare Interoperability Resources and pronounced “Fire”. The standard defines a set of “Resources” that represent granular clinical concepts. The resources provide flexibility for a range of healthca... 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.
- 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
- 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
- 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.
- 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.Tags: FHIR, Healthcare Interoperability