This document discusses the journey of healthcare interoperability from buzzword to application programming interfaces (APIs). It provides context on what interoperability means in healthcare, outlines the history of efforts to achieve interoperability, and discusses some of the problems with previous approaches. The document advocates reframing interoperability efforts around a continuous API product development approach with user-focused design and adoption of open standards like FHIR to improve data sharing and access. Government policies are helping to drive adoption of APIs to further the goal of interoperability.

1. Healthcare Interoperability
From Buzzword to APIs
U.S. DIGITAL SERVICE // SHELBY SWITZER // JULY 2020

2. WHO I AM
• Shelby Switzer
• @switzerly
• US Digital Service @ the Department of Health and
Human Services (HHS): usds.gov // @usds
• Civic tech, healthcare interoperability, APIs
• Civic tech blog: civicunrest.com
@switzerly

3. WHY I’M HERE
@switzerly
Healthcare tech is still not
interoperable and user-focused.
This is a huge burden not only on
patients, but on the American public.

4. WHAT I’LL TALK ABOUT
@switzerly
• Interoperability and APIs in healthcare
• The journey to interoperability
• From “interoperability” to interoperable APIs

5. What is interoperability in
healthcare?

6. interoperability noun
: ability of a system (such as a
weapons system) to work with or
use the parts or equipment of
another system

7. In the modern software industry,
the conversation isn’t about
interoperability; it’s about APIs.

8. And APIs are products.

9. API PRODUCT LIFECYCLE
@switzerly

10. COMMON API PRINCIPLES
@switzerly
• It’s a continuous cycle of product development.
• Users (consumers) and their problems drive product
development.
• The “why” is present from beginning to end.
• Discovery and promotion -- developer experience,
marketing -- are important.

11. WHAT’S MISSING?
@switzerly

12. INTEROPERABILITY
@switzerly

13. TOOLS FOR API INTEROPERABILITY
@switzerly
• schema.org
• json-schema.org
• JSON-LD
• Hypermedia formats: JSON:API, collection+json, HAL, etc
• Semantic web standards: RDF, etc
• Open standards like Open Banking

14. In healthcare, interoperability != APIs.

15. HEALTHCARE INTEROPERABILITY
@switzerly

16. Foundational
4 LEVELS OF HEALTHCARE INTEROPERABILITY
1 3 4
Basic requirements to
securely
communicate data
between systems
Structural
Format, syntax, and
organization of data
exchange
Semantic
Common underlying
models and
codification of the
data, with shared
definitions and
meaning to user
Organizational
Includes governance,
policy, social, legal
and organizational
considerations
2
@switzerly Source: HIMSS, https://www.himss.org/what-interoperability

17. Foundational
4 LEVELS OF HEALTHCARE INTEROPERABILITY
1 3 4
VPN connection;
HTTP(S); SFTP/FTPS
Structural
HL7 v2.x, HL7 v3, CSV,
EDI, XML, JSON
Semantic
HL7 v2.x, HL7 v3,
FHIR, USCDI
Organizational
BAAs, MOUs, consent
forms, policy
compliance
2
@switzerly Source: HIMSS, https://www.himss.org/what-interoperability

18. To achieve all four levels of
interoperability, you don’t even need
an API.
@switzerly

19. @switzerly
While CSVs over SFTP are better than
this:

20. Simply automating or digitizing
manual processes and data exchange
isn’t enough.
@switzerly

21. The journey to
interoperability

22. • 1989: HL7 v2 created
• 2004: Creation of the Office of the National
Coordinator for Health IT (ONC)
• 2009: HITECH Act establishes Meaningful
Use
• 2009: ONC issues funding to states to
create Health Information Exchanges
(HIEs)
• 2011: CMS establishes Medicare and
Medicaid EHR Incentive Programs (a.k.a.
the Promoting Interoperability Programs)
• 2011: Initial draft of FHIR published
• 2014: Project Argonaut launches as a
multi-stakeholder partnership to advance
FHIR
• 2018: CMS launches Blue Button 2.0 FHIR
API
• 2020: ONC & CMS Patient Access and
Interoperability rules
BRIEF HISTORY
@switzerly

23. • Patient’s care team
• Provider
• Provider staff
• Hospital administration
• Provider / health system billing dept
• Social workers & case managers
• Public health department
• Long-term care facility
• Centers for Medicare & Medicaid Services
(CMS) and other gov agencies
• Payor (insurance)
• Researcher
• Pharma
• Labs
• Device manufacturer
• Software vendors
• The patient
USERS & STAKEHOLDERS (A SAMPLE)
@switzerly

24. INTEROPERABILITY, PHASE 1 (1990’S-TODAY)
Web
portal
HL7 v2.3
HL7 v2.5
HL7 v2.3 with
nonstandard
elements
Paper
Web
portal
CSV
Email
HL7 v3
Fax
@switzerly

25. WHAT ARE SOME PROBLEMS?
• One-off integrations
• Integrations often not real-time
• Neither structure nor semantics are shared between systems
• Patient often can’t access their own data in a machine-readable or usable
format
• Moving data between systems takes precedence over making data usable
and actionable
@switzerly

26. INTEROPERABILITY, PHASE 2 (2000’S-TODAY)
Web
portal
HL7 v2.3
HL7 v2.5
HL7 v2.3 with
nonstandard
elements
FHIR
HL7 v3
Email
HIE/HIN
Interface
engine
FHIR
FHIR
CSV
FHIR app
Paper
@switzerly

27. WHAT ARE SOME OF THE BENEFITS?
• Access to normalized or cleaned up data makes integration and use easier
and faster.
• New players can more easily enter the market by using intermediaries.
• Software developers and stakeholders can focus on adding value rather
than exchanging data.
• Hopefully better quality and more consistent data improves patient care.
@switzerly

28. WHAT ARE SOME PROBLEMS?
• One-off integrations
• Use of HIE/HIN or interface engine may not be mandated or show clear
enough value to convince an organization to connect.
• Integrations may still not be not real-time
• Neither structure nor semantics are shared between systems, unless
intermediaries provide (and sell) this value.
• Patient still can’t access their own data in a machine-readable or usable
format.
• Moving data between systems can still take precedence over making data
usable and actionable.
@switzerly

29. From “interoperability” to
interoperable APIs

30. WHERE WE’RE TRYING TO GO
@switzerly

31. WHERE WE NEED TO GO
@switzerly

32. THE DREAM
@switzerly

33. THE 1990’S AREN’T GOING ANYWHERE ANYTIME SOON
• Modernization takes time and investment.
• While we modernize, we must invest in open, standards-
based infrastructure like open source software and FHIR
APIs.
@switzerly

34. REFACTOR INTEROPERABILITY INTO INTEROPERABLE API STRATEGY
@switzerly
• Continuous API product development
• Understand the “why” beginning to end
• Users are part of the cycle, and patients are top and center
• Discovery and promotion matter:
o Stop building silos
o Invest in developer experience

35. • FHIR is being increasingly adopted and learning from
adoption
• Multi-stakeholder groups and public/private partnerships are
valuable in pushing forward standards and committing to use
• CMS is at the forefront in implementing APIs using new FHIR
standards, and we should continue collaborating with the
FHIR community as we learn by doing
DESIGN STANDARDS WITH USERS (IMPLEMENTERS)
@switzerly

36. • CMS Patient Access Rule and ONC Cures Act Final Rule (2020)
◦ Standards-based Patient Access API & Provider Directory API
◦ Payer-to-Payer Data Exchange
◦ Improving the Dually Eligible Experience by Increasing the Frequency of
Federal-State Data Exchanges
◦ Public Reporting and Information Blocking
• CMS APIs: Blue Button 2.0, Data at the Point of Care, Beneficiary
Claims Data API
• VA Lighthouse API
GOVERNMENT DROVE INTEROPERABILITY; IT IS DRIVING APIS
@switzerly

37. We are on the journey to better
health outcomes and value for
patients.

38. Let’s reach our destination
through user-focused,
patient-centered, standards-
based APIs.

39. Thank you!
USDS.gov/apply