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 - Grant
An executive overview of what FHIR is for those not living it on a daily basis.
Strengths - Anne
What is it that makes FHIR great? Listing it's core strengths will help define best practices to capitalize on these.
- Modern, web development paradigms for information exchange (RESTful, JSON, XML) and access control (OAuth) accelerating adoption.
- Easy to retrieve, human and machine readable Resources.
- Easy PoS integration to solutions exposing properly formed ImplementationGuides.
- Core model closed and governed by an SDO leading to predictable and controlled growth.
- 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:
- 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.
- 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.
- 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.
- Lack of tooling supporting the entire life cycle of FHIR implementations.
- 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.
- 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.
- 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.
The stakeholder perspective - Attila (Yaron)
List the various stakeholders categories and what FHIR looks like from their perspective.
Project Sponsors
Modellers
System implementers
Integrators
PoS applications
Government
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.
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 - Attila
A place to collect useful information for stakeholders and maybe exploring a roadmap of how this could evolve in the future.
FHIR Eco-system - Attila
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.