1. Introduction to FHIR (and the role of Connectathons)
FHIR = Fast Healthcare Interoperability Resources (Pronounced “Fire”)
The goal of the FHIR project is to make interoperabilty an order of magnitude cheaper. Preliminary indications suggest that this might be the case. Grahame will describe existing and potential implementations and consider their likely impact on the healthcare process
Why we started FHIR
Approach – borrow the best ideas
Ethos
Timelines
Purpose / Goal
Adoption
The hype curve
The trough + clinical interoperability
Grahame Grieve
FHIR Product Director for HL7
May
Sydney
Copyright © HL7. Licensed under Creative Commons (CC0)
FHIR® and the FHIR icon are trademarks of HL7, inc (

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 (
Describes how to exchange information about healthcare
Adds healthcare knowledge to web standard infrastructure
Read this slide, then explain that this because we needed a globally unique acronym, and that this works really well for implementers

3. 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)

4. 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)

5. 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

7. What is FHIR?

8. 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
Introduction to the technical side of FHIR – what it is – an programming interface to a system that stores and manages a set of health records, using RESTful approach (explain that later – it just means ‘the web way’)
We allow for information to be found and read, and also written back the store of information. Which is useful because the store has processes around it of *doing something* for the patient.
Because client and server use the same interface, they can be used interchangeably – this is what creates the capabilities to do interesting things with health
The important thing about FHIR is – there’s lots of RESTful specifications out there, lots that do health – but only FHIR is deeply connected and committed to the whole, existing healthcare, to catering for general requriements

9. 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

10. What’s a Resource? 100-150 total -goal Administrative
Examples
Non-examples
Administrative
Patient, Practitioner, Organization, Location, Coverage, Invoice
Clinical Concepts
Allergy, Condition, Family History, Care Plan
Infrastructure
Document, Message, Profile, Conformance
Gender
Too small
Electronic Health Record
Too big
Blood Pressure
Too specific
Intervention
Too broad
And few systems will ever see more than 40-50
total -goal

11. 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

12. 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
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)
This is a set of tools that we use to create a community that is tightly connected and committed to interoperability.
Tools encourage adoption, and open collaborative adoption.
Importance of connectathons to the FHIR process for both building community and getting the specification nailed.

14. 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”

15. Ethos: Freely available
Known address:
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
Was a bigger deal before HL7 decided to open up all IP
full legal text towards bottom of FHIR home page

16. Ethos: Community http://fhir.org – Home for FHIR Implementation FHIR
– Discussion Forum
– Dedicated Instant Messaging
– Implementation questions
- public change proposals
– Wiki for Community Documentation
All these are places where people gather. Demonstrate chat.fhir.org.

17. Making FHIR work

18. Localization Managing localization is a central problem
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
A little bit of history around this for HL7, stake holders. Some illustrations of problems with schema, extension to v2 CDA. Explanation of how it works in FHIR, and why we think it’s important (the walls come down in the web age).

19. 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| |Q^57|4.30^uL
Foreign namespaces in CDA/V3
Break schemas
Simple choice – design for absolutely everything or allow extensions

21. 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.

22. 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)

23. 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)

24. 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)
hosts
Hold regular connectathons
Connect with wider community
Australia channel on
How it’s worked well in other countries – so suggestions for Chinese options

26. 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,

27. 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?

28. 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