International Patient Access
1.0.0-preview - STU1 International flag

International Patient Access, published by HL7 International - Patient Care Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0-preview). This version is based on the current content of and changes regularly. See the Directory of published versions

International Patient Access

Official URL: Version: 1.0.0-preview
Draft as of 2022-08-10 Computable Name: InternationalPatientAccess

Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License

Where possible, new or updated content is highlighted in green for review. This highlighting will be removed prior to publication.

Welcome to the International Patient Access API Specification

This specification describes how an application acting on behalf of a patient can access information about the patient from a clinical records system using a FHIR R4 based API. The clinical records system may be supporting a clinical care provider (e.g. a hospital, or a general practitioner), a health data exchange, or other system managing patient records, including a national health record system.

The IPA specification is designed to help patients access their data. However, implementers can use the IPA profiles and the SMART App Launch specification to support clinician-facing and backend-access to patient records too.

Using this API, applications can access the following information about the patient:

Example Scenario

Salma Kahil uses a personal health record app to track her health and assemble her records from multiple healthcare providers. Her healthcare providers support the International Patient Access API, and Salma’s health record app provides a user-friendly IPA application to provide safe, quick, and reliable access to data. Because retrieving and updating her medical information from her healthcare providers is secure, fast, and simple, Salma is a more informed and engaged patient.

Using the International Patient Access API

The IPA specification is designed to help patients access their own data through any app of their choice. The underlying SMART App Launch specifications have also been deployed at scale for clinician-facing and backend access to patient records using EHR-integrated SMART apps. Note that this version of IPA is read-only, though specific implementations may choose to provide write access. In addition, IPA implementers are encouraged to re-use IPA profiles and support additional SMART App Launch capabilities, such as the “Clinician Access for EHR Launch” scenario or “Backend Services”.

IPA Actors

The following actors are part of the IPA IG:

IPA Requestor
An application that initiates a data access request to retrieve patient data. It can be thought of as the client in a client-server interaction. The terms “app”, “patient app”, and “client” are used interchangeably throughout this guide and are not meant to limit this actor to only patient and provider apps. Payers and other users can use the same technology. Consider these terms a short-hand notation for a “user application”.

IPA Responder
A product that responds to the data access request providing patient data. It can be thought of as the server in a client-server interaction. The terms “server”, “IPA FHIR server”, and “EHR” are used interchangeably throughout this guide and are not meant to limit this actor to electronic health record systems. HIEs, care coordination platforms, population health systems, etc., can use the same technology. Consider these terms a short-hand notation for an “interoperable healthcare platform”.

SMART on FHIR Authorization Server
A product that responds to authentication and authorization requests as defined in the SMART App Launch specification. It can be thought of as the server in a client-server interaction. The terms “Authorization server”, “SMART on FHIR server”, and “OAuth2.0 server” are used interchangeably throughout this guide.

IPA Sequence Diagram

The sequence diagram in the figure below outlines a successful interaction between a patient and an IPA server to query and retrieve the patient’s clinical data:


How To Read this Guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar.

  • Home: The home page introduces the IPA project and guide.
  • Conformance: This page describes the rules to claim conformance to this guide and defines the expectations for must-support elements in the IPA Profiles.
  • Using The API:
  • Security and Privacy: This page documents the IPA security requirements and discusses patient privacy and safety topics.
  • Artifact Index: These pages provides detailed descriptions and formal definitions for all the FHIR objects defined in this guide.
    • Profiles: The set of Profiles that a patient can access. They contain clinical and supporting information about the patient. In addition, each Profile page includes a narrative description, guidance, and a formal definition.
    • CapabilityStatements: This page defines the expected FHIR capabilities of an IPA client and server.
    • Operations: This page defines the $docref operation for retrieving generated documents on request.
    • Examples: The list of all the examples used in this guide. These examples show what data produced and consumed by systems conforming with this implementation guide might look like. Every effort has been made to ensure that the examples are correct and valuable. However, they are not a normative part of the specification, nor are they fully representative of real-world examples.
  • Support:
    • Downloads: This page provides links to downloadable artifacts that developers can use to help them implement this guide.

Relationship to National Specifications

This International Patient Access specification describes how to access patient records anywhere in the world. It provides a very minimal set of access methods and rules about the content that are true everywhere. Working healthcare systems may need additional rules about the access API to meet other use cases, and may make many additional rules about the content based on national laws, regulations and accepted practice in order to support the provision of health in their healthcare system.

Jurisdictions are encouraged to use this specification directly and may also publish their own patient access specifications that further refine the profiles in this implementation guide. 

This project intends to create and maintain a registry of FHIR implementation guides consistent with IPA as countries adopt it in their national FHIR standards.

Declaring support for IPA

As jurisdiction-specific FHIR profiles proliferate, specification authors should strive to build on top of IPA to better serve their implementors, care givers, and patients. A FHIR implementation guide declares a relationship with IPA by refencing IPA in its published CapabilityStatement. Similarly, systems can also indicate their support of IPA in their CapabilityStatement. An implementation guide or system can support IPA in two distinct manners:

  1. An implementation guide is compliant with IPA if it requires all that IPA requires, including support for SMART on FHIR and IPA’s profiles. Similarly, a system is compliant with IPA if it supports all of the requirements in IPA. In both cases, the CapabilityStatement communicates compliance by referencing the canonical IPA uri in its implementationGuide element
  2. An implementation guide is an instantiation of IPA if it requires some of IPA’s requirements. A system instantiates IPA if it supports parts of IPA. The CapabilityStatement communicates this by referencing the canonical url of the appropriate IPA CapabilityStatement url in its instantiates element.

Implementers and users of a system or specification which instantiates IPA, should take care to ensure that the desired functionality from IPA is what’s instantiated. The “instantiates” form of support for IPA is imprecise.

Relationship between IPA and IPS

The International Patient Summary (IPS) specifies a more extensive set of rules about the content that clinical systems may conform to.

  • IPA (this specification): a specification for access to a patient record with minimal expectations about the content
  • IPS: a specification that describes a package that contains a clinical summary for the patient

These specifications are doing different things - one is making provision for access to a record, and the other is making rules about the content found in the record.

The specifications do overlap, in that some systems that are required conform to both specifications - that is:

  • systems that are capable of producing a Patient Summary that meets the IPS rules, and
  • also provide access to the patient record as specified here

Such systems will produce content that has two different sets of rules applied - the minimal expectations in this specification, and the more extensive rules specified in IPS.

These rules are consistent; the content rules in this specification are a subset of the IPS content rules, and any system that meets the information requirements in IPS automatically conforms to the requirements on the content specified here.

Note that not all systems that conform to IPS are required to provide direct patient access, though many will. Also, many systems that provide access to patient as described by this specification will not be able to conform IPS, but some will.