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 APIs
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. INTEROPERABILITY FROM A MODERN SOFTWARE PERSPECTIVE
@switzerly
• APIs
• Standards-based
• Usable data
• Secure
8. In most modern software industries, the
conversation isn’t about interoperability;
it’s about APIs.
And it’s about API strategy and lifecycle
management.
@switzerly
9. @switzerly Source: Red Hat, https://developers.redhat.com/blog/2019/02/25/full-api-lifecycle-management-a-primer/
API LIFECYCLE MANAGEMENT
10. API THEMES
@switzerly
• It’s a continuous cycle of product development.
• The “why” is present from beginning to end (strategy
and monetization).
• Users (consumers) are part of the cycle.
• Discovery and promotion matter.
12. 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
18. • 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 (now
known as 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
19. • 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
20. 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
21. WHAT ARE SOME PROBLEMS?
• One-off integrations between custom, on-prem (and, later, cloud)
systems are expensive and lengthy processes.
• Integrations are often not real-time.
• Neither structure nor semantics are shared between systems,
increasing burden of integration and risk of data quality and
consistency issues.
• Patient cannot usually (and in some cases, ever) access their own
data electronically or in a machine-readable or usable format.
• The focus on moving data between systems takes precedent over
making data usable and actionable, resulting in multiple, complex
screens of information providers end up ignoring.
@switzerly
22. 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
23. 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’s
care.
@switzerly
24. WHAT ARE SOME PROBLEMS?
• One-off integrations between custom, on-prem (and, later, cloud)
systems that expensive and lengthy processes may still exist because
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 cannot usually (and in some cases, ever) access their own
data electronically or in a machine-readable or usable format.
• The focus on moving data between systems can still take precedent
over making data usable and actionable.
@switzerly
26. 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
27. REFACTOR INTEROPERABILITY INTO 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
28. • 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
29. • 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
30. We are on the journey to better
health outcomes and value for
patients.
31. Let’s reach our destination through
user-focused, patient-centered,
standards-based APIs.