Page History

Context

FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is the next generation standards framework created by HL7 International. FHIR combines the best features of HL7's v2 , HL7 v3  and CDA  product lines while leveraging the latest web standards and applying a tight focus on implementability.

This page will attempt to collect the most relevant factual arguments in an effort to bring some clarity and alignment for Canadian implementers.

Executive overview

Coming out as the winner of the “Fresh Look Initiative" project at HL7 International, Fast Healthcare Interoperability Resource (FHIR®) was born in 2011 as the standard to change it all. It was intended to build on lessons learned from all its predecessors with a distinct focus on keeping end users in mind, reducing the complexity at point of service, moving it down into the service providers that understood and were able to afford to manage it.

FHIR describes data formats and elements (known as "Resources") and an Application Programming Interface (API) for exchanging personal health information. An open specification, FHIR has four principal elements:

1. A Comprehensive Data Model for defining personal health information and administrative data.
2. An API-Based Mechanism that simplifies the preparation and handling of information and data using ReST-ful (Representational State Transfer) protocols.
3. Open Source Tools to implement and test FHIR applications.
4. FHIR-Configured Servers that interact with the APIs to facilitate the information availability.

Through these four elements, FHIR aims to simplify and facilitate implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy-to-implement yet rigorous mechanism for exchanging data between healthcare systems.

Embracing modern web technologies during design rather than an afterthought, FHIR has come a long way. Its core philosophy is to focus on the most common 80% of clinical use cases having Resources created to model them, while allowing for extensibility through Extensions.

The Standard is developed by referencing its own building blocks and any statements made within are supposed to by machine processable. A team of standards, programmers and domain experts build FHIR the very same way modern applications are built: with open source control repositories, build & validations scripts and test servers ensuring that content is testable and implementable.

Research focused industry leaders are building FHIR servers that provide test beds and drive development of open source reference implementations on major programming platforms and languages (Java, .NET, C#, Delphi, JavaScript, Swift).

At the same time developers are encouraged to use the Standard for Trial Use (STU) Resources and provide feedback on their shortcomings. Connectathons are organized to bring early implementers together in venues where interoperability for key scenarios can be tested.

The combination of these practical interactions informs reactive enhancements to the Standard that lead to a refinement of the core FHIR Resources which are starting to reach maturity. About 10% of the posted Resources are maturity level 4-5 on a scale of 0-6 (as of the STU3 release - March, 2017), with another 25% being close behind (level 3).

While FHIR is still a long way away from becoming fully Normative, the fact that core Resources are already stable enough for describing significant interactions means that more and more solution vendors have started using FHIR for its convenient technology as well as a market differentiator.

We are seeing global industry rallying together (in US as a side effect of the Meaningful Use program) in defining common FHIR interfaces that allow for basic EHR transactions between their systems. SMART on FHIR was created as a common launching method for Applications with context derived from EHRs.

There are other examples from Europe, Australia and even Canada where new implementations reach for FHIR as the underlying standard for their solutions.

While there are still challenges to overcome, there is a marked, voluntary industry engagement which is only expected to intensify as FHIR matures and the market demand increases.

Strengths

What is it that makes FHIR great? Listing it's core strengths will help define best practices to capitalize on them.

1. Modern, web development paradigms for information exchange (RESTful, JSON, XML) and access control (OAuth) accelerating adoption.
2. Easy to retrieve, human and machine readable Resources.
3. Easy PoS integration to solutions exposing properly formed ImplementationGuides.
4. Core model closed and governed by an SDO leading to predictable and controlled growth.
5. Extensibility, core design element of the Standard.
6. Community, there is a very active national and international community that is freely contributing to FHIR's naturally evolution and are available through online channels. When in doubt seek them out.
7. Tooling, an increasing number of FHIR specific tooling is starting to emerge, some for modelling, some for publishing others for development. These can easily be sought out through community channels.
8. Public Connectathons, venues where implementations can be tested for interoperability with other FHIR solutions. These are available at every HL7 International WG meeting (three times a year) and through national events such as Mohawk - FHIR North.

Challenges

There are still some challenges that need to be considered when developing or implementing using FHIR. These should not deter from using the standard, rather need special considerations:

1. Significant degree of structural change for some Resources caused by an overall low maturity level. Backwards compatibility is only guaranteed for levels 5 and higher, consequently, early implementers should expect disruptive upgrade paths for their implementation interfaces.
2. High level of version variation for Resources - increases in early adoption of the Standard which in itself is evolving at a very high pace are expected to flood the market with a large number of profiles developed on different versions of FHIR builds. Direct effects are incompatibilities in rendering and/or exchange.
3. Profiles and Extension variations - By design FHIR promotes the use of StructureDefinitions (aka. profile) and Extensions. Uncontrolled and ungoverned spread resulting from the abuse of this paradigm can inevitably grind FHIR interfaces to a halt because different profiles can break interoperability. Whenever possible, the recommended approach is to develop using international FHIR Registries.
4. Insufficient formal guidance on modelling using FHIR Resources - the complexity of the healthcare domain did not disappear with the arrival of FHIR. Proper solution design is still an absolute requirement to successful spread of solutions using the standard. There is a gap in training and guidance on modelling using FHIR Resources, as a result training is highly recommended.

Best practices

The following is a list of best practices collected from the Canadian implementer community that have prior FHIR experience:

• Upfront consideration should be given to short and long term technological needs. Examples are web and mobile apps, cloud services, API based integration for vendors of EMR and other health apps, support for innovative solutions by startups, etc. FHIR exposes native support for modern web technologies making it a very good candidate.

• Large-scale project should consider level of complexity, learning curve and cost of implementation for future adopters, not just project participants. Considerations of future adopters' (e.g. small vendors, healthcare organizations with small IT departments, etc.) limited budgets and resources require shifting the complexity as much as possible to the implementation side (e.g. server/backend) making integration work as simple and inexpensive as possible. FHIR, along with a well-defined architecture can offer a good fit..

• FHIR implementations employing incremental agile approach with frequent delivery and feedback iterations over traditional waterfall approach are more likely to be successful.

• Microservices models with modular architecture exposing well-defined APIs should be chosen over large monolithic systems. FHIR RESTful architecture offers direct support for this approach.

• Optimize database and data services of your FHIR based system for front-end performance and move all the complex data preparation and calculations to the offline back-end processes.

• Employing reusable FHIR components such as open source libraries, tools, models and reference implementations will lead to faster, less expensive implementation. There is an increasingly growing number of supporting resources to utilize (e.g. Furore's Forge and IG Publisher to create FHIR specs, ClinFHIR to communicate FHIR models with clinical/business teams, HAPI & FHIR.js libraries for the actual back-end & front-end coding,  Simplifier.net - FHIR Registry, etc.). Get educated in availability and usability or various tools and components.

• It is recommended to execute test and validation cycles of FHIR resources against open FHIR servers (e.g. Grahame Grieve test server, UHN (James Agnew) test server, Spark and others).

• Getting engaged in consulting work done in Canada and internationally: InfoAPI, US Core, Argonauts project, NHS, Australia, large vendors (e.g. Epic, Cerner, etc.) and others.

• Utilize the FHIR support community, which is a great asset to any project: FHIR chat (most questions answered in minutes), InfoCentral forum.

• Participate in FHIR connectathons, both Canada and Internationally.

• For early adopters designing systems around draft (non-normative) FHIR resources, a recommended pattern could be to define a JSON store as a set of name/value pairs rather than directly adopt FHIR data element names, since all data element and resource names are subject to change until FHIR becomes normative.

• When adopting a draft (non-normative) version of FHIR, choice should be given to a stable version (e.g. official DSTU2 or STU3) over interim versions (e.g. 2016 September STU3 candidate). Many open source libraries and tools would offer no or very limited support for interim versions. If necessary, new data elements should be temporarily pre-adopted as extensions.

• Participate in community engagement for creating and reusing FHIR artifacts such that successful models become ubiquitous rather than redefined over and over again leading to very poor if not impossible semantic interoperability

• Guidance and training activities are very important for creating properly formed, complete FHIR solutions

• Stimulate solution sharing by posting to and adopting from registries of reusable FHIR artifacts

• Find practical means of solving for frequent problems (e.g. URI, ValueSets, Top Canadian Profiles, Top Canadian Extensions, etc.) and properly represent those in developer guides

• Strive towards creating a longitudinal record of the FHIR implementation projects (Business Requirements to Specifications) – such that stakeholders can understand what your solution offers - key ingredient for reuse

Stakeholder perspective

While FHIR brought the much needed innovation to the HIT standards space, it is undeniable that the promised benefits and interests look very different depending on the stakeholder category one belongs to. The table below highlights typical stakeholder areas of interest, teasing out where the true value of FHIR is realized.

To cater to all stakeholder groups, Infoway has created a network of tools that combine publishing, discovery and technical sharing. Consider the Standard Selection Framework for posting projects that you have completed or browse it when starting new projects. Significant cost savings could be achieved from reusing existing content that is supported by tools such as the TerminologyGateway (for ValueSet management), FHIR Registry for sharing of Canadian FHIR artefacts, InfoAPI for Swagerrized rendering of FHIR interfaces and API generation (work in progress, sample here).

FHIR Environment

Successful scaling and adoption of FHIR based solution is predicated on semantically interoperable components. A couple of strategies to achieving this include reuse and solution interfacing. To illustrate this consider the following diagram:

The greatest benefit of FHIR is in the ease of information exchange. For this to work however, the exchanged information needs to be semantically correct and predictable. FHIR models that ensure that this is so are the CapabilityStatement, StructureDefinition, ImplementationGuide. Using these constructs core resource profiles can be set up for reuse or as extensions. This great flexibility can lead to an unbound proliferation of semantically divergent resource models making the solution integrator's job a living nightmare. One way to curb this uncontrolled expansion is by providing a FHIR registry of existing solutions where through discovery, FHIR resource definitions can be repackaged and interacted with through standardized programmatic interfaces. Combining this architecture with appropriate tracking and metadata, it is possible to identify existing implementations, who the implementers are, endorsements that an interface has received, number of downloads, likes, etc. This level of clarity can lead to a natural adoption curve that promotes best of breed adoption leading to an organic filtering of content as in a practical "governance by adoption". The following pictures illustrate this:

FHIR Registry - list of services		FHIR Registry - internal architecture

Supporting networks and resources

There are a number of places and tools that early adopters are using when it comes to FHIR. A classification, description and link to them could help build solution stacks to serve the stakeholder perspectives listed above.

Reference: HL7 International, FHIR Site, FHIR Foundation for international release content, InfoScribe for links to Canadian assets

Modelling: XML editors, Excel Spreadsheets, JSON editors, IGuide build tool, Forge profile editor, Art Decor, Trifolia

Project publishing: InfoScribe

FHIR Registry: Canadian FHIR Registry

Technical Publishing: IGuide build export, Simplifier.net

Know-how: FHIR.org Zulip, InfoCentral FHIR WG 

Discovery: Simplifier.net, InfoAPI (work in progress) for known Canadian interfaces

APIs: HAPI-FHIR (UHN), InfoAPI (roadmap item - client code)

Supporting systems: Terminology Gateway, URI registry (identified roadmap item)

Testing: Grahame Grieve's test server, UHN test server, Spark, Aegis

Platforms: SMART on FHIR, Argonaut

Solution showcase space

There is an increasing number of FHIR based solutions popping up in the Canadian market. This space is reserved for showcasing some of the more notable ones that are of interest to the broader market. In case you'd like your solution listed here get in touch through the InfoCentral Forum.

Medication Dispenses

Read only FHIR interface for hospital information systems, physicians’ EMRs, regional viewers. The project included conversion of two legacy systems databases into FHIR resources. One of these systems collects claims from pharmacies for patients, whose drugs are covered by one of the provincial programs. Another system collects narcotics dispenses information.
The next phase of this project is to get direct feeds from pharmacies as FHIR POST transactions.

Immunizations

A FHIR based web interface for public, e.g. parents, to retrieve all immunization records of their children, virtual yellow card (the immunizations paper) and to submit missing immunizations. The second phase for the project is to build a FHIR interface for healthcare providers to access and submit immunizations. This part is based on FHIR API which allows EMR and pharmacy vendors to retrieve and submit information directly from their products.

Conclusion

Being the most disruptive health information technology standard of its kind, FHIR is a guaranteed mainstay. It's great capabilities, relative light weight and reliance of modern programming paradigms is setting it up as the most serious contender to healthcare information exchange. All technology leaders in this space should take FHIR seriously and start formulating their adoption roadmaps because judging by the speed of its spread it will likely displace most other technologies currently in use. FHIR is the future, however, wise and considerate approach is recommended throughout its adoption. Best practices should be followed and mainstream channels should be obeyed such that solutions built on FHIR will offer a brighter, more interoperable future.