- For patients, greater access to health data empowers them to standardly and computably access and retain their digital health data.
- For regulators and national specification authors, the IPA specification provides a starting point to jumpstart a national health API ecosystem, with an emphasis on patient access. The IPA FHIR profiles are the result of an analysis of existing national base profiles, and is the lowest common denominator globally.
- For app developers, IPA outlines the global base set of access and security mechanisms and content format. This increases the size of the addressable market for apps, both in terms of geography and of systems.
- For systems vendors, IPA defines a base set of functionality, enabling less adaptation and custom work when the system is deployed to a new market. More apps and other systems are readily interoperable with the system.
- For healthcare systems, adoption of IPA means less expensive and more robust systems, as fewer market-specific customizations are required. Support of IPA will also enable healthcare systems access to a wide ecosystem of interoperable apps.
The IPA specification has two goals:
- Secure, simple authorized access to data. IPA defines how apps are authorized to access data using RESTful FHIR APIs and the widely deployed HL7 SMART on FHIR capability. By standardizing the security layer, IPA enables secure, modern authorization and authentication. By standardizing the RESTful FHIR APIs, IPA encourages commonality in different jurisdictions.
- Familiar data types and profiles. The IPA specification defines a minimal set of FHIR profiles which describe an international baseline and example clinical content. These FHIR profiles describe the content to be globally harmonized, based upon known existing country specific base profiles.
Spreading IPA on FHIR
The use of HL7 FHIR continues to grow in a number of countries. Many of the countries with significant or national base FHIR specifications are informing which content should be included in the IPA specification.
Figure 1: World map showing countries with national base FHIR specs that are informing IPA
Access Versus Summary: What’s the Difference?
HL7 has another specification with a similar name to the IPA. Where IPA establishes a standard for apps to be authorized to access data, the International Patient Summary specification (IPS) defines an interoperable set of data containing a patient summary for well understood clinical use cases. Although IPS doesn’t define many specific API interactions, it is adopting internationally usable terminologies.
Figure 2: IPA vs. IPS Comparison of Data Exchange
IPA doesn’t prescribe a specific use case. For example, one patient may simply want to backup their health data; on the other end of the spectrum, another may use a chronic disease management app interested in a very specific piece of data, and also be prepared to read it in many different methods and formats from different systems or regions. The IPA specification caters to both these needs. By enabling programmatic access to data, patients and developers can innovate.
How Can You Help?
- Talk to your representative about patient access to health data via modern, standard APIs.
- Are you familiar with your national FHIR profiles? Willing to compare and give feedback against the in-progress IPA profiles? Submit a jira ticket.
- Are you a national regulator, health IT interop architect, patient app developer? Get in touch! Participate in an upcoming HL7 FHIR Connectathon.
Argonaut 💗 IPA
In mid 2022, the HL7 FHIR Argonaut accelerator is bringing together providers, software developers, and others to collaborate on accelerating and advancing IPA. Get involved