This page is part of the International Patient Access (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
Official URL: http://hl7.org/fhir/uv/ipa/ImplementationGuide/hl7.fhir.uv.ipa | Version: 1.0.0 | |||
Active as of 2023-02-01 | Computable Name: InternationalPatientAccess | |||
Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License |
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. In addition, implementers can use the IPA profiles and the SMART App Launch specification to support clinician-facing applications and backend access to patient records.
Applications that conform to IPA can access the following information about the patient:
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.
The IPA specification is designed to help patients access their data through patient-facing applications. The underlying SMART App Launch specifications have been deployed at scale for clinician-facing and backend access to patient records using EHR-integrated SMART apps This version of IPA is read-only. However, 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”.
The following actors are part of the IPA IG:
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:
This Guide is divided into several pages listed at the top of each page in the menu bar.
This International Patient Access specification describes how to access patient records worldwide. It provides a very minimal set of access methods and content rules that are true everywhere. Working healthcare systems may need to make additional rules about the access API to support other use cases and their national laws, regulations, and accepted practices.
Jurisdictions are encouraged to use this specification directly and may also publish their 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.
As jurisdiction-specific FHIR profiles proliferate, specification authors should strive to build on top of IPA to better serve their implementors, caregivers, and patients. A FHIR implementation guide declares a relationship with IPA by referencing 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:
Because the “instantiates” form of support for IPA is imprecise, implementers and users of a system or specification that instantiates IPA should ensure that the desired functionality is instantiated.
The International Patient Summary (IPS) specifies a more extensive set of rules about the content that clinical systems may conform to.
These specifications are doing different things - one is making provision for RESTful access to a record using modern authorization standards; the other is making rules about the content found in a summary of the record. Although some considerations are appropriately given to these distinct use-cases, the content rules in this specification are generally a subset of the IPS content rules, systems that meet the information requirements in IPS will typically conform to IPA and can also provide access to the patient record as specified in IPA.
This Implementation Guide was made possible by the contributions of the Argonaut Project member organizations and the Patient Care Work Group,
Authors:
Individual Contributors: