Overview#

Fast Healthcare Interoperability Resources (FHIR) is the latest interoperability standard from HL7, following on from Version 3.
(Strictly speaking it builds on rather than replacing v3, but also pulls in ideas from other organizations such as openEHR or IHE). [2]

Fast Healthcare Interoperability Resources leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.

Fast Healthcare Interoperability Resources has built-in mechanisms for traceability to the HL7 RIM and other important content models. This ensures alignment to HL7’s previously defined patterns and best practices without requiring the implementer to have intimate knowledge of the RIM or any HL7 v3 derivations.

Fast Healthcare Interoperability Resources has the fundamental concept of "Resources", where a resource is the basic unit of interoperability – the smallest ‘thing’ that makes sense to talk about – such as a Patient, a Condition (Problem) or a Practitioner. Resources have a number of common characteristics, including:

  • A small number of ‘core’ properties that most (80%) of systems currently support. Each property is a specific datatype (although some resources allow more than one datatype to be used for a property)
  • A standard extension mechanism that allows implementers to add new properties in a safe and discoverable way. (This is the lesson of version 2)
  • An ‘identity’ by which it can be saved, located & retrieved
  • A human readable component that summarizes the data in the resource for a human to read (This is the lesson of CDA).
  • Resources can be re-used across interoperability paradigms. You could receive (or save) a resource via a REST service, and then package it in a Message or include it in a Document.
  • There is a built in versioning system. Each resource can have multiple versions, and there are mechanisms to retrieve the history of a specific resource, and/or a specific version.
  • The specification itself is on-line, and fully hyperlinked. You can link through from resource, to a property, to the datatype of that property. Where a particular terminology or code set has been defined for a property, you can hyperlink to that dataset. (Terminologies are a bit more tricky to link to).

Why should you care?#

Fast Healthcare Interoperability Resources has been build with the needs of the Implementer in mind. We try to be as simple as possible, but no simpler.
  • This extends to the use of connectathons, where developers can try out ideas before being included in the specification.
  • Standard tooling can be used.
  • You can use XML or JSON representation.
  • Each resource has a specific validation schema / schematron (again, a lesson from CDA)
  • All the artifacts (including the schema) are automatically built using a build process (similar to a software build). This significantly improves the overall quality of the specification.
  • Each resource has multiple examples that shows how the resource can be used. The resources themselves are ‘round-tripped’ from XML -> JSON ->XML and validated as part of the build process to ensure accuracy.
  • FHIR (especially the JSON representation) is great for Mobile Device development
  • There are number of open-source clients to make it even easier to use
  • There are also some test servers to test your work out on.
  • Lots of other people are looking very closely at FHIR

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-5) was last changed on 25-Jul-2017 09:16 by jim