A lesson on interoperability from the healthcare sector

For anyone involved in management of health IT, the collection, storage and safe sharing of healthcare information has always been one of the most important – yet difficult to achieve – parts of their job.

Part of the problem is that information is not only collected from many different systems, but the way data is represented and shared is often specific to each system.

And increasingly there are demands beyond the simple sharing of data within a facility. We are seeing:

• An increasing need for patients to be involved in their own care. They need access to their own information, and are expected to contribute to it.

• A big shift to the use of mobile devices as the means of access.

• Decision support, requiring highly structured – and consistently represented – information.

• Population health analytics.

• A vast increase in the range and quantity of data, driven largely by the increasing availability of devices that can collect this information, plus the increasing use of genetic information.

This means:

• There is an increasing range of organisations and developers who need to access health information – and often they are not experts in the healthcare domain.

• A requirement to use real-time Internet based protocols to access that data. Information needs to be delivered right now!

• A need to be consistent in the representation of health data, especially as the same ‘type’ of information can come from multiple sources.

Fundamentally there need to be standards in the way health information is represented, and made available to those who need it.

While there are existing standards designed for healthcare exchange, they were developed many years ago, are no longer really ‘fit for purpose’ for these new requirements.

HL7 version 2 is very widely used – and very successful in what it aims to do – yet uses technology almost 30 years old, and has not been implemented consistently. HL7 CDA is excellent at sharing documents for human use, but is only really applicable to the document paradigm, and is complex when attempting to extract coded information from them. Specialised standards such as DICOM remain important – but only within their specialised areas.

IHE – a profiling organisation rather than a Standards Development Organisation remains very relevant, but the standards they use are also in need of a refresh.

FHIR (Fast Healthcare Interoperability Resources) has been designed from the ground up to make it easy for implementers to develop and deploy solutions across the globe.

The result of these factors is that new implementations involving the manipulation of healthcare care:

• Are time consuming and expensive.

• Require highly qualified (and costly and scarce) people to design and implement.

• Often result in fragile implementations that are difficult to support and upgrade.

Related:The hybrid team leader: David Kennedy of Orion Health

The latest standard from HL7 – FHIR – promises to change that.

FHIR (Fast Healthcare Interoperability Resources) has been designed from the ground up to make it easy for implementers to develop and deploy solutions across the globe. In fact, it came about in the first place in response to the question from the HL7 Board: “If we were designing a health care interoperability standard today, what would it look like?”

Based on commonly used Internet standards as used by organisations like Google, Facebook and Amazon, it is designed with the Implementer in mind – and an Implementer who is not familiar with the healthcare domain.

It is based around the concept of Resources – small pieces of information that ‘make sense’ in the health IT world such as patient, encounter, medication, allergy and condition. Each resource is effectively a best-practice model of how the majority of systems think about – and exchange – healthcare data. Each resource is small – up to 20 or so individual elements, yet is capable of being extended to accommodate any required information in a manner that promotes discoverability.

Resources can then be combined in a ‘web’ of relationships, allowing the most complex of requirements to be represented. They can be exchanged in real-time (so-called RESTful exchanges), packaged in a document (like CDA) or a message (like HL7 V2).

While each resource is compact, there are profiling and extension mechanisms built into FHIR that allow them to be extended to represent any conceivable requirement in a manner that is understandable to others.

So a FHIR based implementation will be cheaper and faster than existing standards because:

• There are already resources defined for most of the commonly needed requirements;

• Implementation can be performed by a much wider range of implementers;

• There is wide interest from the existing vendor community, with many of them announcing support and providing test interfaces. It is very likely that FHIR interfaces will be supported by them within months rather than years;

• There is a world wide community of experts to give advice, using social media as a mechanism;

• The specification is available on-line, is fully hyperlinked and contains numerous examples;

• Open source libraries are available to kick start any development;

• ‘Connectathons’ – where application developers meet to learn and test the standard are regularly held around the globe;

• Test servers are available 24×7.

Drawbacks and deficiencies

But nothing is perfect – so where is FHIR deficient? Well, the biggest drawback is FHIR’s relative immaturity, it is yet to be ‘battle tested in real implementations over a period of time. And much of the focus of the developers has been on the real-time ‘RESTful’ capabilities to support mobile and browser based applications – while the standard has been designed to support messaging and documents, these capabilities are less developed and exercised.

So what should a prudent CIO do about FHIR? The first is to ensure that technical staff are familiar with FHIR, and ideally participating in the different practical events and forums being hosted around the world.

If current standards are meeting requirements, or there is such a heavy commitment that change is difficult, then a ‘watching game’ is probably best. But for developments that hit the ‘sweet spot’ of FHIR – mobile, device and real-time interactions – then give it a go! You will be surprised how easy and intuitive it is. (And the amount of support available when needed – answers are often received within minutes of asking)

At the time of writing, FHIR is approaching its second trial version. While it will not be ‘finished’ for another couple of years, there are already trial implementations in every continent in the globe (apart from Antarctica), and by almost every significant healthcare vendor globally.

It is no surprise then, that FHIR is taking the healthcare world by storm.

David Hay, is a medical doctor and product strategist at Orion Health. He is chair of HL7 New Zealand and a member of the international FHIR Management Group and the National Health IT Board’s Health Information Standards Organisation (HISO). He is the author of a blog on FHIR.

Send news tips and comments to divina_paredes@idg.co.nz

Follow Divina Paredes on Twitter: @divinap

Follow CIO New Zealand on Twitter:@cio_nz

Sign up for CIO newsletters for regular updates on CIO news, views and events.

Join us on Facebook.