You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

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.

 While the standards is still in its infancy, not having reached Normative status yet, there is an increasing number of early adopters that are rushing in to capitalize on its promise - easier and faster integration. There is ample written material on the web that both praises FHIR and warns against reckless adoption practices. This site will attempt to collect the most relevant factual arguments in an effort to bring some clarity and alignment for Canadian implementers.

Executive overview - Grant

As healthcare delivery becomes more complex and increasingly digital, and as patients become more mobile, their personal health information needs to be more readily available to facilitate timely and quality diagnosis and care.
The health informatics community in Canada is actively working to support this availability through the use of FHIR (Fast Healthcare Interoperability Resources) so that health information is appropriately structured and standardized to facilitate its automated exchange and other related machine-based processing. So, what is FHIR?
FHIR is a rapidly emerging information standard informed by years of lessons around requirements, successes, challenges and lessons learned. 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.
A further advantage of FHIR is that it can be used alone, but also in partnership with existing widely used standards. The FHIR specification is also in-line with the rapidly emerging mobile and web-based exchange of health information. Widely adopted, FHIR has the potential to reduce the risk, timeline and cost of developing the next generation of healthcare applications.

Strengths - Anne

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

  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.

Challenges - Anne

Known and foreseeable obstacles raising threats to successful adoption. Some of the considerations that inform the audience on the immediate challenges faced when developing or implementing with FHIR.

Things to consider:

  1. Significant degree of structural change for most Resources caused by an overall low maturity level - FHIR defines a Resource's maturity level on a scale of 0 - 5, lowest to highest. Backwards compatibility is only guaranteed for levels 4 and 5, consequently, early implementers should expect disruptive upgrade paths for their implementations.
  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 FHIR builds. Direct effects are incompatibilities in rendering and/or exchange.
  3. Unbound proliferation of like Resource profiles and Extensions - FHIR makes it all too easy to define a StructureDefinition (aka profile) or an Extension for any particular Resource and then use these in an implementation. Uncontrolled and ungoverned growth resulting from the overuse of this paradigm will inevitably grind FHIR interfaces to a halt because no two Resources will ever be the same. A Patient is not a Patient is not a Patient.
  4. Lack of tooling supporting the entire life cycle of FHIR implementations.
  5. Deployment models - a large number of early FHIR solutions are using the RESTful paradigm, however, FHIR also supports the Document, Messaging and Services models. There is little experience in the field using these latter models, early implementers should exercise caution in design and adoption.
  6. Insufficient formal guidance on modelling using FHIR Resources - the complexity of the healthcare domain did not disappear with the advent of FHIR. Proper solution design is still an absolute requirement to successful proliferation of solutions using the standard. There is a significant gap in training and guidance on modelling using FHIR Resources that could threaten large scale adoption.
  7. Lack of a mature international marketplace for sharing - there is a recognition in the international standards community that ungoverned growth of FHIR implementations could lead to an overwhelming variability of solutions, significantly hurting large scale interoperability. There are thoughts about establishing FHIR solution registries at national or even more desirable, international level to encourage reuse of Profiles and Extensions. In these early days however, these resources are still lacking making solution discovery and reuse problematic at best. 

Best practices - Igor

This is the place to draw on collective wisdom and list what it is that the recommended best approach is for FHIR development to lead to predictable and scalable adoption. We may even be able to break this down per stakeholder category.

  • 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 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 - adopted FHIR resources, 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 and 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), forum, Infoway’s 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, pan-Canadian top profiles, etc.) and properly represent those in developer guides
  • Strive towards creating a longitudinal record of the FHIR implementation project (Business Requirements to Specifications) – such that stakeholders can understand what and how your solution delivers to its requirements encouraging reuse.

The stakeholder perspective - Attila

List the various stakeholders categories and what FHIR looks like from their perspective.

Project Sponsors

Modellers

System implementers

Integrators

PoS applications

Government

FHIR Eco-system - Attila

Supporting networks and resources - Attila

A place to collect useful information for stakeholders and maybe exploring a roadmap of how this could evolve in the future.

Solution showcase space - Shamil, Igor

Conclusion

This should be no longer that 2-3 paragraphs and it should draw out the essence of what those considering getting involved in FHIR should know.

  • No labels