If you went to HIMSS this year one thing was abundantly clear – FHIR was everywhere. HL7’s latest draft standard is rising up the hype curve quickly. As more US based vendors invest in FHIR based data exchanges, Canada needs to understand how those investments will translate into new capabilities and what we need to do to ensure they are available to us.
What is FHIR?
FHIR is the latest standards family from HL7. The core FHIR standard defines a set of “resources” that define “chunks” of data that can be passed around individually or combined into more complex structures such as a message or document. Resources are generic and support a wide number of contexts and uses (e.g. human, veterinary, in-patient, out-patient, public health, research, claims, etc.), while focusing on what is common to implementers around the world. An extension and profiling framework supports handling data elements specific to particular countries, disciplines and implementation environments.
Why is it gaining so much attention?
There’s a lot of reasons why developers are flocking to FHIR. For starters it’s easy to access; anyone can go to www. hl7.org/fhir and access all the supporting documentation, tools, and other implementer resources without needing a membership or even registering an email and password. FHIR is based on modern web technologies, including a RESTful interface. Its wire format can be expressed in XML or JSON. Finally, there are reference implementations in a variety of languages, numerous publicly available test servers and other supporting tooling that developers need to quickly create applications.
The vast majority of data elements that comprise FHIR resources are optional and the majority of vocabularies are not constrained. This gives implementers a lot of flexibility in designing their implementations. However, this also means anyone working with FHIR needs to profile their constraints on the base resources to reflect the needs and expectations for their particular interoperability environment.
Recognizing the power of FHIR, the US Office of the National Coordinator (ONC) has sponsored work to create profiles that identify the constraints on the FHIR clinical and administrative resources to meet US Meaningful Use requirements. They call these profiles the Data Access Framework (DAF). DAF profiles create a base level of interoperability for systems that comply with those profiles.
It’s important for Canadians to know that these are US centric and require the use of value sets such as Rx Norm for medications, and extensions such as capturing ethnicity in patient resources, that don’t necessarily apply in the Canadian context.
Why do Canadians need to care about DAF profiles?
HIS vendors such as Cerner, Epic, and Allscripts, are using the DAF profiles with another framework called SMART that enables people to create “apps” that can plug into EHRs, HISs and other solutions.
SMART is a means of setting up an app based ecosystem around healthcare vendors’ products in a similar manner to the smart phone app environment. SMART on FHIR uses the DAF profiles to provide a common API that developers can use to create apps that can be used on different products and gain access to patient data. This allows organizations to create custom views of data and new functionality w/o having to pay the vendor to customize their products. It opens up new opportunities for deploying tuned user interfaces, support for clinical trials and numerous other capabilities.
If we want these SMART enabled systems to work in our Canadian environment we will need the equivalent of the DAF profiles to support Canadian requirements. To increase our chances of having US vendors provide this capability in Canada we will need to be conservative in where we make changes in order to minimize the differences with the DAF profiles. One approach would be to focus our attention on differences that are required primarily to meet legislative and regulatory requirements in Canada. A good starting point for identifying those requirements are the pan-Canadian EHR standards from Infoway.
Is FHIR right for you?
FHIR is in the “Standard for Trial Use” phase of its life-cycle, meaning HL7 considers it to be production ready, but will not lock it down until there is more implementation experience. Portions of the standard are likely to progress to “normative”, which will bring backwards compatibility rules into force some time in 2018. As well, every resource has a maturity scale documented in the standard that allows you determine how stable it is.
Unlike its predecessor standards though, the vendor community is finding that the potential costs of migrating from one version of FHIR to another are outweighed by the ease and speed of developing something FHIR-based rather than building something custom. Implementers are rolling out FHIR solutions in North and South America, Asia, Europe and Australia. The FHIR implementer support chat now has over 500 participants. So FHIR certainly appears to be “ready” for implementation. As well, it is ideally suited for interoperability in the mobile, social and device spaces.
That said, selecting any standard for your implementation requires following an evaluation methodology and researching the candidates for use. There are abundant free and paid training materials available. Connectathons such as FHIR North (fhirnorth.ca) and the ones held in conjunction with HL7 Working Group Meetings provide a hands-on opportunity to gain hands on experience and insight into the subtle nuances of the standard.
Given the speed of market adoption in other jurisdictions, it is highly recommended that implementers attend some of the FHIR education sessions available from HL7 and ask their developers to start playing with it to inform future standards selection decisions.