Is FHIR truly the holy grail of interoperability in Healthcare? Learn about common pitfalls in real-world enterprise-scale FHIR implementations and how to approach them pragmatically — also a look at some exciting new developments in the works.

1. Anish Arora
Senior Director, Product & Interoperability, McKesson Corp.

2. 17+ Years in
Healthcare IT
12+ Years in
Integration/
Interoperability
Epic
Software Developer
Integration Engineer
8 years
Consultant for
Sutter Health – 7
years
Epic implementation – 25
hospitals, 6 medical
foundations
Lead a team of Interface
Analysts + Developers –
rolled out hundreds of
interfaces
Helped Sutter Health
launch their first API
Portal with deep Epic
integration
Healthcare Startups
Careskore (population
health)
ReferralMD (referrals
management)
Suki (voice + AI based
digital assistant for
doctors)
McKesson
Product &
Interoperability
Switched from
Engineering to
Product
Building next
generation of EHR in
the Oncology space

3. “Cheap, flexible, and interoperable:
when developing healthcare software,
you can only have two of these”
 Grahame Grieve
 (The father of
FHIR)

4. Gartner Hype Cycle

5.  An API Standard?
 A Data Model?
 A Secure Framework for Data Exchange?
 Plug and Play Interoperability?

6. It’s a Suggestion that has the
potential to become a Standard

7. THE 5
PITFALLS

8. Putting All Your Interoperability Eggs in
the FHIR Basket
 Real world FHIR works best for
synchronous flows
 For asynchronous and large volumes
of data HL7v2 and other forms of file
transfer may be the best option you
have
 Real world FHIR has limited coverage
and adoption
 Sometimes vendor APIs may be a
better fit for your needs
Tip: Consider all options before picking the right
solution (hint: it may not be FHIR)

9. SEMANTIC
INTEROPERABILITY
Definition of S.I. according to HIMSS:
“The ability of two or more
systems to exchange
information and to interpret
and use that information”
a.k.a. the problem you will inevitably run into when
you scale beyond one Integration partner

10. 1. Existing, popularly used or incentivized coding systems
 ICD-10
 SNOMED
 CPT
 LOINC
 RxNorm
2. value lists that need to be defined
 Vital signs (height, weight, blood pressure, etc.)
 Allergies
 Smoking history
 Demographics such as race, ethnicity, address, age, socio-economics
 Encounter types
Tip: consider a “Data Management” Layer in your
Integration stack to normalize data across multiple
integrations

11. PITFALL #3 – NOT ALL FHIR
IMPLEMENTATIONS ARE
EQUAL
 Differences in vendor implementations of FHIR and their data models creates
challenges
 Vendors’ interpretations of FHIR resources vary broadly
 Scope of FHIR capabilities varies broadly across vendors and products
This Photo by Unknown Author is licensed under CC BY-ND
Tip: consider a “API Orchestration” Layer in your Integration
stack

12.  EHR vendor APIs generally follow a service-oriented
architecture
 EHR vendor APIs are primarily designed to answer specific
questions that cover common workflows or data exchange
requests - e.g.“for a given provider, give me certain details
of his booked appointments for a given date range”.
 FHIR is designed around locating resources and has
relatively limited search capabilities
 Trying to mix-n-match Vendor and FHIR APIs to create an
integration solution isn’t as straightforward as you think.
This Photo by Unknown Author is licensed under CC BY-ND

13. EHR
AppPatients API
Appointments API
Visit Notes API
MRN: 1234567
Visit ID: 23679876
FHIR DocumentReference
(Create)
Patient’s FHIR ID
Encounter FHIR ID
FHIR Patient
FHIR Encounter

14. EHR
VENDOR
COSTS
AND FEES
EHR vendor App
marketplaces
Epic App Orchard
Cerner CODE
Allscripts ADP
Athenahealth
MDP
FHIR pricing is often usage
based. Sometimes other options
(like HL7 v2) might be more cost
effective as you scale
Tip: Consider vendor-imposed
costs and fees while pricing your
product

15. Recent initiatives gaining traction

16.  Obtaining data: from an EHR for
population-based research and
training data for a machine learning
algorithm or quality metrics.
 Moving data: in bulk between
servers (migrations/conversions)
 Extracting data: entire data sets on
patient groups for analytics –
patients on a clinical trial or under
Case Management.
Reference: https://www.hl7.org/documentcenter/public/calendarofevents/himss/2018/HL7%20FHIR%20Bulk%20Data%20API.pdf

17.  This will be by far the single largest reason to switch away from HL7 v2
 Makes asynchronous data flows possible
 Few EHR vendors already working on it

19. https://wiki.hl7.org/index.php?title=Open_Source_FHIR_implementations

20.  https://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing

21.  FHIR has a real potential to become the standard – the momentum is palpable
 Keep your options open (at least for now) – HL7v2, Vendor APIs
 But be opportunistic in developing FHIR based integration solutions
 Pay attention to vendor-imposed marketplace costs and usage fees
 We are all part of the solution as much as the problem – FHIR needs us!

22. “Interoperability is all about the people”
-Grahame Grieve