FHIR in FIVE minutes

HL7 V.2 has been so popular for years in Australia while HL7 V.3 has been established and adopted in U.S.. However, there are lots of comments and opinions about how it is difficult to implement system in V.3 as it sounds like an XML edition of HL7 protocol. Particular reason for the unpopularity of V.3 may be laying on whether it is worthy to migrate existing V.2 assets to V.3 format while existing systems are still supporting V.2 standard.

If you want to know more about how HL7 V.2 evolved to V.3, please read the PDF document via the link.

Let's take a look at the timeline of the development of HL7 standards:

Things are moving on and so does this standard. In recent years, new toolsets have been released and named as FHIR (pronounced "Fire"). Fast Healthcare Interoperability Resources (FHIR) defines a set of "Resources" that represent granular clinical concepts.

XML and then FHIR. Sounds complicated, isn't it? What's this set of "Resources" all about?

HL7 V.3 is about XML formatted messaging while FHIR is about the way to deliver it.

As long as we learn XML as the key message format of data exchange between the systems, we may not miss the term Web Service which actually encapsulates XML message with an envelope and then send it out to the other side of the receiving end.

One category of Web Service is using REST-ful (REpresentational State Transfer) API for communication. This type of Web Service makes data communication easier as it includes basic CRUD (Create, Read, Update, Delete) operations over HTTP/HTTPS protocol (standard web technologies). You can even open a browser and read the results in XML format via the pre-defined URL. After all, it's producing human readable messages like HL7 V.3.

For the feature like RESTful API, System Developers can surely create lots of possibility, especially for Mobile Apps (IOS, Android, etc.). System Integrators can bridge up the systems through the orchestration and collaboration of Web Services. All these can be summarised into a typical usage of Service Oriented Architecture (SOA).

In other words, through FHIR it is possible to produce a set of reusable resources in the form of URLs like:
http://pat.registry.org/Patient/2231
http://hospitalA.org/Practitioner/870
http://hospitalA.org/Organization/10
http://lab.hospitalA.org/Observation/3ff12
http://lab.hospitalA.org/DiagRep/4545

Common resource's identity would be like this:

The business logic on top of FHIR is the coding (Java, .NET, C++) to collaborate these web services in order to achieve the desired outcome. FHIR server is basically one kind of web servers but includes the engine to support RESTful operations for clinical data.

FHIR is still under active review and development so you may want to catch up with their progress via the URLs:

Current specification:
http://www.HL7.org/fhir

Repository of packages and tutorials:
http://gforge.hl7.org/gf/project/fhir/scmsvn/?action=browse&path=%2Ftrunk%2F

Demo (Grahame's test server):
https://fhir.healthintersections.com.au