1. FHIR Solutions in Primary Care Overview, Opportunities and Risks
Rob Hausam MD
AMIA 2017 Annual Symposium
Washington, DC
November 4, 2017

2. FHIR Solutions in Primary Care
Overview

3. What is FHIR? Fast Healthcare Interoperability Resources
Pronounced as “fire” /ˈfī(-ə)r/
Next generation standards framework from HL7
Combines the best features of HL7's v2 , HL7 v3 and CDA product lines
Leverages the latest web standards
Applies a tight focus on implementability

4. More About FHIR
FHIR solutions are built from a set of modular components called "Resources”
Resources can be assembled into working systems that solve real world clinical and administrative problems
Suitable for use in a wide variety of contexts
Mobile apps, cloud communications, EHR-based data sharing, server communication, and more

5. Genesis of FHIR
Has been a need to share healthcare information electronically for a long time
Increasing pressure to broaden scope of sharing
Across organizations, disciplines, even borders
Mobile, Device & Cloud-based applications
Faster – integration in days or weeks, not months or years
Pre-History:
For example v2 is over 25 years old
My personal experience is in Public Health where there is a need to collect information from many organizations.
Currently takes too long and costs too much…

6. Genesis of FHIR (cont.) HL7 undertook a “Fresh look”
What would healthcare exchange look like if we started from scratch using modern approaches?
Web search for success markers led to RESTful based APIs
Exemplar: Highrise (
Drafted a healthcare exchange API based on this approach
What is an (restful) API (Application Programming Interface)? Set of services between machines ( like browsing the web only instead of a human at one end you have 2 machines communicating) In other words an API packages and ships information between places. This can mean if you publish your API you can open up you data and functionality to other developers both internally and externally. For example Amazon API can be used by a third party.
REST (REpresentational State Transfer) is an architectural style RESTful is an implementation based upon REST.

7. The Goals of FHIR Implementer Focus Target the 80% (common stuff)
Use today’s web technologies
Support human readability
Paradigm & architecturally agnostic
Open Source

8. Web Technologies
Same technologies that drive Google, Facebook & Twitter
HTTP
DataTypes W3C complaint
XML, JSON, RDF
REST API
HTTPS, OAuth, etc. for security functions
We try very hard to *not* invent stuff that exists elsewhere unless it’s really broken or totally unaligned with the FHIR principles.
Atom was used for collection of resources into a bundles - Replaced in DSTU-2 with FHIR bundle
RESTful implementation based upon REST.

9. Paradigm Agnostic
The Content is the same despite the interoperability paradigm
Lab System
Receive a lab result in a message…
FHIR Message
FHIR
Repository
FHIR Document
…Package it in a discharge summary document
National
Exchange
REST
…Update a patient record

10. Where can FHIR be used? Classic in-institution interoperability
Back-end e-business systems (e.g. financial)
Regional Health Information Organizations (RHIO)
National EHR systems
Social Web (Health)
Mobile Applications
Near
Term

11. Business Case for FHIR Predefined Resources & API
Analysis already done, and can be safely extended
All paradigms, All Architectures, All Clients
Thick client, browser, mobile, devices
Implementer friendly
Simple to understand and access with examples
Familiar tooling & familiar technologies – XML/JSON, HTTP, SSL, OAuth
James Agnew – HAPI
3)Benefits
a) reuse vs build from scratch
b) flexible ( extensions )
c) lower dev costs ( more accessible to developers and quicker to implement)
d) focus on other things that may be return on your investment
1) GUI
2) Customer Service
3) Marketing
4)Answer to the question " if we build it - will they come? "
a) key is documentation and ease of access over the technical specifications.

12. Business Case for FHIR (cont.)
Implementer friendly (cont.)
Simple to understand and access with examples
Mobile friendly
Concise, REST API & JSON
Don’t need to understand HealthCare domain to implement
Developers or Analysts
James Agnew – HAPI
3)Benefits
a) reuse vs build from scratch
b) flexible ( extensions )
c) lower dev costs ( more accessible to developers and quicker to implement)
d) focus on other things that may be return on your investment
1) GUI
2) Customer Service
3) Marketing
4)Answer to the question " if we build it - will they come? "
a) key is documentation and ease of access over the technical specifications.

13. Business Case for FHIR (cont.)
Already in use Internationally
70 Organizations, 20 Countries, all Continents (except Antarctica)
Involvement from Providers, Vendors, Payers, Governments
Large community for support
Results in faster, cheaper deployments that are more re-usable
James Agnew – HAPI
3)Benefits
a) reuse vs build from scratch
b) flexible ( extensions )
c) lower dev costs ( more accessible to developers and quicker to implement)
d) focus on other things that may be return on your investment
1) GUI
2) Customer Service
3) Marketing
4)Answer to the question " if we build it - will they come? "
a) key is documentation and ease of access over the technical specifications.

14. Future impact of FHIR Impact of FHIR on the market
Drive interoperability prices down
Higher Expectations
Sense of a community
Enormous interest from vendors and Legislators
How much integration do you need? Nx2 – twice what you have

15. Future impact of FHIR Overall Market focus Web based PHR Mobile
Device Data management
Healthcare repositories (MHD+)
Retooling existing connections (v2, CDA)
How much integration do you need? Nx2 – twice what you have

16. Resources: What are they?
The Content model
The “Thing” that is exchanged
Via REST ( FHIR Restful API), Messages, Documents
Informed by much past work inside & outside of HL7
HL7: version 2, version 3 (RIM), CDA
Other SDOs: openEHR, CIMI, ISO 13606, IHE, DICOM
vs FHIR REST paradigm - treat data as independently , retrievable resource using http - think of browsing on the web
FHIR RESTful API endpoints on a server and the stuff you can do to get them back
3) FHIR documents/ document paradigm = type of bundle vs CDA Document architecture using FHIR - Clinical document practice - profile on FHIR for CDA on top of that a ccda profile that expresses the dataelements in

17. Resources (selected examples) Maturity Model General: Care Provision:
AllergyIntolerance
AdverseEvent
Condition (Problem)
Procedure
ClinicalImpression
FamilyMemberHistory
DetectedIssue
Care Provision:
CarePlan
CareTeam
Goal
ServiceRequest
NutritionOrder
VisionPrescription
RiskAssessment
Medication & Immunization:
Medication
MedicationRequest
MedicationAdministration
MedicationDispense
MedicationStatement
Immunization
ImmunizationRecommendation
Diagnostics:
Observation
DiagnosticReport
SpecimenDefinition
Specimen
BodyStructure
ImagingStudy
ImagingManifest
Maturity model
Goto the spec – resource list
Maturity Model

18. The need for Profiles
Many different contexts in healthcare, but a single set of Resources
Need to be able to describe restrictions based on use and context
Allow for these usage statements to:
Authored in a structured manner
Published in a repository
Used as the basis for validation, code, report and UI generation.
Note Profiling is going to be very important
‘Message from the chair’

19. The need for Profiles (cont.)
Profiles can serve the same purpose as:
CDA templates & implementation guides
HL7 v2 “static” profiles
CIMI implementation guides
OpenEHR Archetypes & templates
Profiles aren’t mandatory for interoperability, but they improve the degree of it.
Profiles never change meaning of an instance

20. Profiling a resource For example...
Require that the identifier uses the NHI – and is required
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to another set of codes that extends the one from HL7 international
Add an extension to support “Iwi”
Constrain out animal element(card = 0..0)
Note: hardly any mandatory elements in the core spec!
Tools for creating profile being develop - Forge..

21. Extensions FHIR has a standard framework for extensions
Built into wire format
Every FHIR element can be extended
Including datatypes
Every extension has:
Reference to a computable definition
Value – from a set of known types
In FHIR, extensions are “normal”
Consequence of the 80% rule – keep the simple stuff simple
Extensions can exist anywhere
Resource, Element, DataType
Conformant systems can’t reject instances just because they contain unrecognized extensions
They could:
Display them
Should be in resource narrative
Store as a ‘Blob’
Make a conscious decision to ignore (unless ModifierExtension)
(Could lookup profile)

22. Extensions (cont.)
Every system can read, write, store and exchange all legal extensions
All extensions are valid by schema, etc.
In FHIR, extensions are “normal”
Consequence of the 80% rule – keep the simple stuff simple
Extensions can exist anywhere
Resource, Element, DataType
Conformant systems can’t reject instances just because they contain unrecognized extensions
They could:
Display them
Should be in resource narrative
Store as a ‘Blob’
Make a conscious decision to ignore (unless ModifierExtension)
(Could lookup profile)

23. Opportunities AND RISKS
FHIR Solutions in Primary Care
Opportunities AND RISKS

24. SMART on FHIR®© – Open Platform Architecture
Mobile Apps
Web Apps
+launch
+launch +embed
OAuth2
+authz
+authn
REST API
MU-oriented FHIR Data Profiles
+data
Underlying Health IT Systems
Your system here.

25. SMART on FHIR®© App

29. Web Links SMART on FHIR®© Argonaut Project
App Gallery
Argonaut Project

30. Risks with FHIR FHIR is new FHIR is cool FHIR is coming
Be ready to migrate
Caution for mission critical applications
FHIR is cool
Be realistic about what’s achievable
Work with others (HL7, IHE, etc.) to build profiles
FHIR is coming
At minimum, monitor
Consider whether to pilot for building experience
Still in STU
No backward compatibility guarantee
Some content missing
Limited production experience
Change is likely
Near the top of the hype curve
FHIR won’t fix all interoperability issues
Consensus, terminology, legacy burdens still exist
FHIR provides a framework and platform
Hard work still in profiling
Mitigations
Be realistic about what’s achievable
Work with others (HL7, IHE, industry groups) on the profiles you’ll need
Momentum is high – it will disrupt the health IT environment
Strong interest from regulators (e.g. ONC)
Strong interest from major vendors
Hitting at all points in the market chain
Plan what you could do, decide conditions for entry

31. What About Security? FHIR is not a security standard Security tags
Leverages existing standards
SMART (OAuth2)
Security tags
Specialized resources
Provenance, AuditEvent

32. Does My Vendor Support FHIR?
Well, it depends by itself isn’t enough
Vendors (servers or clients) don’t have to support all of FHIR, as long as they say what they do support
Implementations (the details) are up to the implementers
The FHIR specification doesn’t mandate implementation architectures, security protocols, etc.

33. I Can Get Data Out, But Can I Put Data In?
SMART on FHIR®© apps so far tend to allow read, but not write
That isn’t a limitation of FHIR or SMART, but of vendor and institution procedures and risk management
Many of the most useful applications, especially clinical decision support, will require some type of write capability (either with the clinician in the middle, or not)

34. What FHIR Can and Can’t Do
FHIR can’t solve all of the problems in primary care health IT
That requires insightful and effective system implementations and governance
Newer isn’t always better, even if it can be
FHIR can provide new opportunities and tools for vendors, implementers, managers and clinicians to access and exchange clinical data in ways that will be able to solve many of the problems that primary care clinicians have been facing

35. FHIR Ballot Timeline Release 4 (Expected)
Draft for Comment – January 2018
Mixed Normative/Standard for Trial Use (STU) – May 2018
2nd Normative/STU (“2nd chance” ballot) – September 2018
Publication of FHIR Release 4, including partial normative content, by mid-December 2018

36. And Finally, What About Regulation?
FHIR is still rather new, with no normative content yet (but coming soon!)
For a standard to be cited in regulation typically requires normative status
FHIR mentioned 178 times in ONC 2017 Interoperability Standards Advisory (ISA)
Clinical decision support, reporting, EHR
Only “Push Patient-Generated Health Data into Integrated EHR” listed as a “Federally required” Emerging Implementation Specification?

37. FHIR Referenced in Regulation
So use not required at the moment
But becoming available as an alternative
And expect more to come!

38. Time to Hear From You Questions? Ideas? Problems encountered?
Concerns?
Contact me at: