Introduction to FHIR
(and the role of
Connectathons)
FHIR = Fast Healthcare Interoperability Resources
(Pronounced “Fire”)
Grahame Grieve
FHIR Product Director for HL7
May 26 2017
Sydney
FHIR® and the FHIR icon are trademarks of HL7, inc (http://hl7.org)
Copyright © HL7. Licensed under Creative Commons (CC0)
2
What is FHIR?
• Fast Health Interoperable Resources
• A Community
• Meets under the umbrella of HL7
• Dedicated to making it easier to exchange healthcare information
• Uses web infrastructure to solve problems about healthcare
• A specification
• Freely available on the web (http://hl7.org/fhir)
• Describes how to exchange information about healthcare
• Adds healthcare knowledge to web standard infrastructure
Why FHIR?
In 2011:
‣ Interoperability requirements are increasing dramatically
‣ Vast increase in the amount, type and source of data
- e.g. Devices, Genomics
‣ Analytics, population health
‣ Implementer survey’s showed HL7’s existing course didn’t
match these requirements
‣ Existing standards too incoherent (documents / messages
different)
What is FHIR?
• Use modern Web technology for healthcare
• Add best bits from existing healthcare standards
• REST: a pattern for using web technologies to manage
information
• Scalable – performance, and community
• Agile Standards Development
• Make it free (Open Standard)
4
Best bits
• Web – ease of use, scale, technology stacks
• HL7 v2 – directness, modularity, base core
• HL7 v3 – consistent grammar, terminology methodology
• CDA – Narrative, simple summary consistency
• DICOM – stability, extensibility, conformance statements
• XDS – storage mediated sharing, security lessons
• openEHR – formalism, community, openness
What is FHIR?
FHIR
• A standard for a RESTful API based access to healthcare
records
• Both read and write supported
• Different servers all provide the same API
• A client can use different servers without having to be
rewritten
• Connects API to wider context of health
Not just RESTful
• RESTful APIs are a most popular approach
• But not everything can be done by tightly integrated APIs
• Existing architecture (e.g. SOA)
• Very decoupled systems (messaging)
• Content rules delegated to end-users (documents)
• FHIR supports all these approaches
What’s a Resource?
Examples
Non-examples
• Administrative
• Gender
• Patient, Practitioner, Organization,
Location, Coverage, Invoice
• Clinical Concepts
• Allergy, Condition, Family History,
Care Plan
• Infrastructure
• Document, Message, Profile,
Conformance
10
• Too small
• Electronic Health Record
• Too big
• Blood Pressure
• Too specific
• Intervention
• Too broad
100-150 total -goal
Architecture
• Standalone FHIR Server
• A FHIR Server in front of an existing application (e.g. SQL)
• FHIR as front end to an XDS server (“MHD”)
• An interface engine that ‘speaks’ FHIR
• A tablet/mobile phone application
• Web portal uses FHIR to access other systems
• EHR plug-in framework
• Internal use of FHIR as a modularization tool kit
11
Application extensibility framework
• SMART-On-FHIR deals with many deployment questions
• Integrate FHIR Interfaces into Common Application problems
• EHR plug-ins for extensibility
• Integration of User authentication/authorization
• Clinical Decision Support Infrastructure (cds-hooks)
• Most/Many implementations will use Smart-on-FHIR
13
Ethos: Make it work
• Publicly available test servers
http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing
• Many open source libraries available (integrated with the specification
community)
• Java, C#, Swift, Javascript, Pascal – more coming
• Connectathons/hackathons
• Education/verification
• Many series of connectathons in many countries
• Examples
• Free tools (validators, testers, utilities, code generators)
Clinical Interoperability
Accepted definition for semantic interoperability:
“The ability of two or more systems or components to
exchange information and to use the information that has
been exchanged”
Who cares? We need Clinical Interoperability:
“The ability of two or more clinicians or care teams to transfer
patients and to provide seamless care to the patient”
Ethos: Freely available
• Known address: http://hl7.org/fhir
• License: Creative Commons Public Domain (CC0):
• “No Rights Reserved”
• You can copy, modify, distribute and perform the work, even
for commercial purposes, all without asking permission
• Anyone can do anything with the content
• No disputes about ownership of rights to do anything with the
FHIR content : HL7 waived it’s rights
15
Ethos: Community
•
•
•
•
•
•
http://fhir.org – Home for FHIR Implementation FHIR
http://community.fhir.org – Discussion Forum
http://chat.fhir.org – Dedicated Instant Messaging
http://stackoverflow.com – Implementation questions
http://gforge.hl7.org/gf/project/fhir - public change proposals
http://wiki.hl7.org/index.php?title=FHIR – Wiki for Community Documentation
16
Making FHIR work
Localization
• FHIR is an international standard
• All jurisdictions, all kind of functionality
• Countries, Vendors, Projects have to use FHIR
• Create their own rules – profiles, value sets, mappings,
extensions
• Managing localization is a central problem
• Everyone needs to customize their solution
• Everyone hates it when that happens
• FHIR tames Localization FHIR
• Built in extensibility framework (engineering level)
• Define, publish, find localizations, Use them
• Conformance tooling for managing this
• This tames the overall specification
Adapting FHIR to your needs: Profiling
• Need to be able to describe ‘usage of FHIR’ based on context
• Allow for these usage statements to:
• Authored in a structured manner
• Published in a registry & Discoverable
• Used as the basis for validation, code, report and UI generation.
• 3 main aspects:
• Constraining a resource - remove element, change multiplicity
fix values
• Change coded element binding
• Adding a new element (an extension)
• Profiling adapts FHIR for specific scenarios
20
The Case for Extensions
• Extensions are often problematic in existing HL7 specs
• Z-segments in v2
• What does this mean?
• ZSB|20080117|Q^57|4.30^uL
• Foreign namespaces in CDA/V3
• Break schemas
• Simple choice – design for absolutely everything or
allow extensions
Extensions
• FHIR has a standard framework for extensions
• Every FHIR element can be extended
• Every extension has:
• Reference to a computable definition
• Value – from a set of known types
• Every system can read, write, store and exchange
all legal extensions
• All extensions are valid by schema etc.
2
1
Governing Extensions
• Extensions are not a silver bullet
• FHIR expects a sliding scale governance for
extensions
• Local Projects
• Domain standards (e.g. Best Practice Cardiology)
• National Standards (e.g. Standard Finnish Extensions)
• HL7 published extensions (corner cases with
international scope)
2
2
Making FHIR work
• International Specification defines overall framework
• Countries / Regions publish adaptations to local culture/regulations
etc
• Individual projects use conformance resources to describe the project
rules
• Terminology usage rules
• Extensions
• Rules about elements, usage, content flows
• All of this can be published in the FHIR Registry (coming)
Mapping / Implementation Support
• Concept Map / Transform
• Mapping between terminologies and structures
• Both competing standards and local custom content
• Reflection
• Strong conformance layer with good community and tooling support
• Testing
• Publicly available + open source systems (integrated into production)
• Automated test support (script / report)
• Strong testing culture
25
Making it work for Australia
• Active local community
• Learning from local approaches (e.g. AS 4700.X, MyHR)
• http://fhir.hl7.org.au hosts
• Hold regular connectathons
• Connect with wider community
• Australia channel on http://chat.fhir.org
Role of Connectathons
• Face to Face meeting of the Community
• Pragmatic Solution focused community
• Test Specification & Implementation Guides
• Prioritise Activities of the community
• Build impetus and social media presence
• Who can host/sponsor connectathons?
• HL7, Affiliates, Other SDOs, National Programs, Commercial Vendors,
Universities, Professional Associations,
Adoption
• IHE: gradually reworking existing specifications
• US Adoption
• ONC projects (DAF, SDC, CQF) + Argonaut (front-running meaningful use) +
HSPC (full clinical plug’n’play)
• Europe
• National EHRs (Northern Europe) + UK Clinical repository
• Australia
•
•
•
•
Several Vendors in production, or close to production
National Program gradually adopting FHIR
National Clinical Terminology Service
Argonaut-for-Australia?
FHIR Team Purpose
• Reduce the cost of interoperability (10%)
• Commoditise common exchanges
• Build and extend the communities
• Modularise healthcare applications
• tear down the walls
• Enable and foster Clinical Interoperability