Nov 9, 2017 | Aziz Boxwala
Interoperability of health IT systems has been and continues to be, a challenge. If you’re like most in healthcare, you’re constantly coming up with “workarounds” to get your EHR to provide or accept data to and from various systems. The results of these workarounds is often a less than ideal user experience for the people you’re trying to serve – your clinicians. How many of you out there have settled for creating a PDF and pushing it into your EHR via MDM? Fear not, you’re not alone, and help is on the way in the form of HL7 FHIR!
HL7’s FHIR specification was created to simplify how health IT systems exchange data with each other. FHIR was built on the foundation of RESTful APIs – a modern, web-based approach for computer systems to communicate with each other. RESTful APIs operate on the HTTP protocols, the same protocols that you use every day in your web browser to check email, read the news, and share your vacation photos. It may not sound big, but this is really big for healthcare. Healthcare is now thinking like the rest of the internet. We’ve opened up our talent pool to every programmer in the world who wouldn’t have touched HIT in the past. Prior HL7 standards were messaging-based (versions 2 and 3) or document-based (version 3). They used proprietary protocols, and were often open to different interpretations which not everyone followed (IHE anyone?) With so much confusion on which standard to use, and how to map different terminologies, interoperability was only achieved by a handful of players with “old school” programmers. With FHIR, the doors are open to almost anyone which means that anyone with a good idea can contribute new, and innovative, products to healthcare.
Now, it’s important to note that FHIR is in its infancy and still comes with it’s own workarounds, but they are far less, and much more manageable. What can FHIR do today? FHIR APIs allow authorized client programs to search for data using various parameters to fetch, add, update, and delete records. Data are exchanged as objects known as “resources”. FHIR defines resources for various types of objects such as Patient, Provider, MedicationRequest, Condition (aka Problem), etc. The scope of FHIR’s resources also includes definitional artifacts such as Questionnaire, CodeSystem, and PlanDefinition. The latter resource type is used for creating clinical decision support artifacts such as rules and order sets. I will cover definitional artifacts more extensively in future posts since my colleagues and I use them every day and we are significant contributors to the design of those resources.
The specifications for FHIR continue to grow and evolve rapidly. Many of the largest health IT vendors already provide support for FHIR. The Argonaut group is working to promote and to adopt FHIR for use in the US. In my opinion, the reason for the momentum in the adoption for FHIR (besides federal regulations) is the ease of implementing FHIR services and the ease of consuming those services. Many, if not most software developers, already know how to develop web-based applications using REST services. This makes it easy for them to create apps based on FHIR. The APIs make it simple not only for two systems to communicate with each other, but for innovators to create apps for needs that are not well met with existing products. The expanded FHIR ecosystem such as SMART-on-FHIR and CDS-hooks make implementation of such apps even easier. Elimu’s own SapphireTM product takes ease and speed-of-adoption many steps further by enabling clinical informaticians and analysts to create new FHIR apps using only drag-and-drop capabilities – no programming required at all. HL7’s FHIR roundtable meetings (the last “roundtable” was big enough for a large auditorium at Duke University) showcases many innovative apps including SapphireTM. Visit the FHIR roundtable’s site to see presentations from the last meeting. The next meeting is coming up in December in New Orleans. I’ll be there – FHIR me a note if you’d like to meet up! I forgot to mention FHIR’s one downside – the barrage of puns that its name inspires. But in all seriousness, if you have any questions or comments, I’d love to hear them.