1 of 29

International Patient Access

2024

isaac vetter, epic

2 of 29

3 of 29

Comparison of different national core profile specs

​

​

​

4 of 29

International Patient Access

  • RESTful APIs: SMART, search parameters
  • Minimal profiles, reflect current state
  • Terminologies specified locally

​

5 of 29

IPA

certified

6 of 29

Can an app work anywhere in the world?

There are challenges.

​

  • Differences do exist in what should be available. E.g.
    • Is patient race a mandatory or a forbidden element?
    • Different code sets and vocabularies.

​

​

​

7 of 29

What we can do:

​

​

  • A promise for app developers, systems vendors, and profile authors�on what is supposed to work internationally

​

  • Lowest common denominator
  • Build IPA as the base layer
  • To be further constrained by country or domain specific definitions, for example:
    • CA-baseline
    • Nordic Profile
    • IPS
  • We’re still figuring some of this out!

​

8 of 29

What’s in it?

  • Rules for apps
  • SMART on FHIR for access
    • How modular should we be?
  • Some core profiles
    • Based on known country-specific core profiles

9 of 29

What’s in it for Patients?

​

  • Greater access to health data empowers patients to standardly and computably access and retain their health data.

​

​

10 of 29

What’s in it for app developers?

​

  • Guidelines for developers new to health it, or FHIR.

​

  • Lowest common denominator, globally.

​

  • Base layer of interoperability.

​

11 of 29

What’s in it for regulators & nations?

​

  • A starting place for governments to jumpstart a national health API ecosystem, with an emphasis on patient access.

​

  • The promise of a broader choice of health apps for your citizens.

​

12 of 29

What’s in it for FHIR servers?

​

  • Enables reusable technology that conforms with regional requirements.

​

  • Enables reusable technology that works with existing apps.

​

  • Discourages regional, regulated incompatibilities.

​

​

13 of 29

What’s in it for Profile Authors?

​

  • Greater alignment with regional requirements globally

​

  • More FHIR servers, app and data will be conformant

​

14 of 29

15 of 29

Current Status & Next Steps

​

  1. STU1 Published
  2. Increased Alignment with IPS
  3. Socialization & Adoption
  4. ?
  5. Global Interoperability!

​

16 of 29

STU1 Published!

Publication Request

17 of 29

IPA & IPS

Learning

Conformance

Links

18 of 29

International Exchange Supported by IPS and IPA

Standards Based Data�(IPA & IPS)

Users

Data Exchange

System of Record

IPS Content Profiles

IPS Content Profiles

IPS Content Profiles

IPS Document

IPA Content Profiles

IPA Content Profiles

IPA Content Profiles

Search & Query �(FHIR-based APIs)

Consumer �Device

Medical �Apps

May be HIE or patient-mediated exchange

Human readable + structured terminology**

Clinician

Patient

Patient

Clinician

Focus on structured data but content/terminology vary by geography and use case

Conforms to*

* Pending final ballot reconciliation of IPA and updates to IPS

** IPS primarily uses the SNOMED IPS Terminology where most appropriate

† - infographic credit to John D’Amore

19 of 29

Understanding IPA vs. IPS Differences

​

IPA (International Patient Access)

IPS (International Patient Summary)

Primary scope �& use case

  • RESTful access to patient data �(often used within borders)
  • Baseline for client applications
  • Patient summary for “cross-border” care
  • Implementation of ISO 27269 standard
  • Key Recipient: Healthcare professional
  • Baseline for consumers of information

Profile definitions

  • Minimal based on what’s generally �available internationally
  • Extensive based on what’s expected as part of ISO 27269 standard
  • Usage of Composition to create documents

Terminology

  • Minimal HL7 terminology bindings
  • Example bindings for clinical content
  • No IPA developed terminologies
  • HL7 terminology bindings
  • Preferred/Required bindings including extensive use of SNOMED IPS Terminology
  • Several IPS developed terminologies

Search & generation API interactions

  • API guidance included
  • Search requirements and recommendations defined by profile
  • $docref operation defined
  • SMART on FHIR recommended
  • Minimal API guidance
  • No search parameters included
  • $summary operation defined

Human readable narrative (text)

  • Optional within resources
  • Optional within resources
  • Required for Composition resource�(i.e. can be used to create viewable document)

20 of 29

21 of 29

AU National Core Relationship to IPA

22 of 29

Finnish Base

inherits from IPA

22

https://fhir.fi/finnish-base-profiles/

23 of 29

Argonaut IPA

Public website coming Q1, 2025

  • Education of benefits of patient access, FHIR (and IPA)
  • Funded by the Argonaut Project FHIR Accelerator
  • Consumer, regulator-facing

24 of 29

Resources

Learning

Conformance

Links

25 of 29

IPA Blog Post from HL7

https://blog.hl7.org/international-patient-access

Article Highlights

  • Benefits for patients, regulators, app developers, systems vendors and healthcare systems
  • Simple authorized access (SMART on FHIR) and familiar data types and profiles
  • Many nations informing IPA
  • Access vs. Summary: What’s the difference?
  • IPA doesn’t prescribe any specific use-case
  • How to get involved?

26 of 29

5 Minute Intro on Youtube

27 of 29

Inferno Tests

​

  • Server test suite
  • You need some example data

​

https://inferno.healthit.gov/suites/

28 of 29

Source, Specification, and Notes

29 of 29

Q&A

What questions do you have?