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

Compare with Current View Page History

« Previous Version 6 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.

Brief overview of FHIR

An executive overview of what FHIR is for those not living it on a daily basis.

Strengths

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

  1. Uses modern web development paradigms for information exchange (RESTful, JSON, XML, OAuth) accelerating on-boarding
  2. Easy to retrieve, human browsable Resources
  3. Easy PoS integration for solutions exposing properly formed ImplementationGuides
  4. Core model closed and governed by an SDO hence predictable growth

 

Challenges

Known and foreseeable obstacles threatening successful adoption. These are some considerations to inform the audience on 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 variants 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 universal tooling that supports the entire life cycle of FHIR artifacts forming an interoperability story.

The stakeholder perspective

List the various stakeholders categories and how FHIR supports their problem space.

Project Sponsors

Modellers

System implementers

Integrators

PoS applications

Government

Best practices

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.

Develop a set of recommendation and best practices for implementation work using FHIR, such as:

-          Community engagement for creating and using FHIR artifacts (consider governance by adoption) – best practices and pitfalls

-          Guidance and training track on creating properly formed, complete FHIR solutions

-          Stimulate solution sharing with a central registry of reusable FHIR artifacts (incentivize sharing of people’s work)

-          Find practical means of solving for frequent problems (e.g. URI, ValueSets, pan-Canadian top profiles, etc.) – develop guides

Longitudinal record of the project requiring a FHIR implementation (Business Requirements to Specifications) – cater to all stakeholder groups not just developers so that decision makers can also understand what an IG has delivered

Supporting networks and resources

A place to collect useful information for stakeholders.

Showcase

Examples of successful development and adoption while exploring a roadmap of how this could evolve in the future.

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