Since it was first presented in Vancouver in May 2012, the interoperability and integration community has been buzzing about FHIR (Fast Healthcare Interoperability Resources), pronounced, “fire”. In a short period of time, particularly in the context of healthcare IT, the concept of FHIR gained a lot of traction and backing. 

So what is FHIR? FHIR seeks to take the best bits of current integration methodology and combine them into a single standard which promises to provide an easy, extensible and international standard method of achieving integration and interoperability between disparate healthcare systems. HL7 v2 is easy to understand and implement, but has no enforced structure, so is implemented differently by all providers, meaning there is no chance of plug and play interoperability. HL7 v3’s structure is enforced, but the standard is so complex and costly to implement that, with few exceptions, it has been ignored by the industry unless governments have mandated its use. The use of RESTful web services across many verticals is exploding due to the technology’s ease of implementation. Enter FHIR, which defines a set of resources, with their roots in the HL7 v3 RIM (Reference Information Model), that cover 80% of the data which needs to be shared in healthcare systems and provides a simple mechanism for transmitting them – REST. 

As already stated in another Insights article, the main downside with FHIR is that it enforces the mapping of each system’s data model onto a standard data model for wire transmission. This has the potential to result in leaky abstraction – features of the underlying implementation being necessary in order to use the abstraction – but if the goal of interoperability is to provide plug and play integration between different systems, some common data model is going to be a necessity. Aside from going down the route of providing web APIs and defining interfaces as required – an idea which I believe has a lot of merit – this course shows the most promise of being successful.

FHIR begins with the concept of “resources”, which are the basic unit transmitted between systems. These could be patients, problems, people, etc. The standard RESTful services are then implemented for these resources, meaning they can be Created, Read, Updated or Deleted using HTTP calls. Transmission of the resources is supported using either JSON or XML. The beauty of using HTTP, JSON and XML is that they are open standards, fully supported across the world, here to stay and understood by any developer worth their pay cheque. A FHIR implementation can be put together very quickly and, at least in theory, will be plug and play – at least to the point that the developers of the systems being connected have implemented the standard. Most importantly perhaps, as more developers become involved in health apps (for example, with the move towards wearable computing, pulse monitors and so forth), FHIR provides the tools for a healthcare application to query and be queried by a standards-based, non-healthcare application. As an example, it would be trivial for a SharePoint instance to implement a FHIR connector and query a clinical documentation system which implements a FHIR interface.

The real issue for the standard, as with any, is convincing people to make the switch or to start using it. While the people developing the standards have a tendency to be evangelists rather than hard-nosed business people (and the world needs both), the standard’s usage will be, for the most part, within software written, maintained and sold by profit-driven individuals and companies. If those responsible for integrating healthcare systems don’t see benefits with implementing the standard, it will remain an academic nicety – in the same manner as HL7 v3.

At present, with the standard at DSTU (Draft Standard for Trial Use) stage, FHIR is not a realistic interoperability method for software writers to rely on, but with the weight of effort being put behind it and the willingness of the community to find a more modern, reliable and useable solution to the interoperability conundrum, FHIR certainly has a future. Whether that future will see it become as ubiquitous as HL7 v2 will rely on convincing implementers that migrating to FHIR will allow them to provide a better return to their shareholders than carrying on with v2.

Dominic Green, Global Technical Sales Manager UK, Sláinte Healthcare

 

 

Dominic has responsibility for overseeing all aspects of interface work between Slaínte products, client sites and 3rd party systems, including scoping, designing and specifying interfaces, designing innovative methods of extracting and utilising data and managing the team which implements and supports the interfaces. Prior to joining Sláinte Healthcare, Dominic graduated from Liverpool University with a 1st class honours in Computer Science and began a career in the NHS, initially within senior programming roles and later moving into integration, interface development and project management. His primary responsibilities involved acquiring, administering and developing the hospital’s interface engine (Iguana), incubating and piloting innovative projects designed to drive efficiency and patient care, organising multi-disciplinary effort and managing the software development lifecycle for in-house developments.

LinkedIn: http://uk.linkedin.com/pub/dominic-green/10/222/aa0