Personal Health Records
1.0.0-ballot2 - STU 1 ballot International flag

Personal Health Records, published by HL7 International / Patient Empowerment. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/personal-health-record-format-ig/ and changes regularly. See the Directory of published versions

Plain Language Summary goes here

Getting Started

Official URL: http://hl7.org/fhir/uv/phr/ImplementationGuide/hl7.fhir.uv.phr Version: 1.0.0-ballot2
IG Standards status: Trial-use Maturity Level: 1 Computable Name: PatientHealthRecordsIG

The purpose of this implementation guide is to help the reader implement a Personal Health Record (in a programming language of their choice). The notion of a Personal Health Record (PHR) grows out of the concept of an Electronic Medical Record (EMR). The major difference being in ownership. The PHR being owned by the patient; and the EMR being owned by the hospital. Whereas an EMR is the digital chart maintained within a single organization, an Electronic Health Record (EHR) is the broader, interoperable longitudinal record shared across organizations; this guide uses the term EHR generically hereafter.

The following document will offer design guidance and standardized APIs for helping you develop your application; based on the healthcare industry standard of Fast Healthcare Interoperability Resources (FHIR). The scope of this document does not attempt to prescribe how you, the implementor, ought to go about programming your software. What it does provide, is guidance on how to successfully exchange data with other PHR and EHR apps. In effect, it documents widely supported (and government recognized) data standards and file formats for importing/exporting data into your software.

What is a Personal Health Record?

Nearly two decades ago, the Markle Foundation's Personal Health workgroup convened to discuss the state-of-the-art in managing personal health information. The workgroup defined the PHR as "an electronic application through which individuals can access, manage and share their health information, and that of others for whom they are authorized, in a private, secure, and confidential environment." Their early vision was that PHRs would enable individuals to access and coordinate comprehensive, lifelong health information and exchange necessary parts of it.

VennDiagram.png

The diagram above shows the intersection of the data collected by the patient, compared to the data collected by clinical EHRs or insurance systems. The core of the Personal Health Record should be medical grade, and able to incorporate records from any clinical source or setting; and which the patient can then carry from one healthcare provider to the next. This specification establishes standard mechanisms for a PHR to interoperate with other systems (clinical and otherwise), thereby facilitating sharing of information obtained by the PHR from healthcare encounters, personal documentation and measurement, and other sources.

For more details on functionality of a personal health record system, the reader is encouraged to review the HL7 PHR System Functional Model.

Relevant Law

Country Initiative / Law Type FHIR/API Integration
Netherlands MedMij Framework Policy/Standard + Certification Yes (HL7 FHIR) – MedMij defines FHIR-based APIs; all certified PHRs use these standard APIs.
  PGO Personal Health Environments (apps) Private PHR Platforms (gov’t backed) Yes – Must be MedMij-certified; patients access data via DigiD login and FHIR APIs.
Australia My Health Record (MyHR) Government-run National PHR Partial – Transitioning from CDA to FHIR-based APIs via FHIR Gateway for consumer access.
  National Digital Health Strategy Policy/Strategy Yes – Emphasizes HL7 FHIR alignment; publishes FHIR implementation guides.
Japan MynaPortal Health Access Government portal & APIs Yes – APIs link MynaPortal with private PHRs; using FHIR for new infrastructure.
  Medical DX/Data Health Plans National Policy Yes – Standardizing EHR data and enabling patient access; includes SMART Health Cards (FHIR).
  Personal Information Protection Commission National Law Not specifically. Only specifies handling of personal data and patient data ownership.
  Act on the Protection of Personal Information National Law Not specifically. Only specifies handling of personal data and patient data ownership.
United States 21st Century Cures Act & ONC/CMS Rules Federal Laws/Regulations Yes – Mandates HL7 FHIR APIs (US Core profiles); SMART on FHIR widely implemented.
  Blue Button 2.0 / Apple Health Records Government & Private Platforms Yes – FHIR-based APIs for claims and provider data; app ecosystem supports FHIR APIs.
Canada Connected Care Act (Bill C-72, 2024) Proposed Federal Law Yes (Planned) – Would mandate interoperable systems; aligns with Pan-Canadian FHIR specs.
  Provincial Portals / Pan-Canadian FHIR Profiles Patient portals / Standards Partial – Web portals exist; FHIR-based standards in adoption phase.
UK (England) NHS App & GP Record Access NHS-operated Digital Services Yes – NHS APIs (e.g., GP Connect) use FHIR; patients access data via NHS App.
  CareConnect FHIR Profiles / Patients Know Best National Profiles / Private PHR Yes – Profiles define FHIR structures; private apps integrate via NHS APIs.
Germany Patient Data Protection Act (PDSG) / ePA National Law & PHR Platform Partial – Currently uses CDA/IHE XDS; migrating to HL7 FHIR (ePA 2.0, Basisprofil DE).
Finland Kanta PHR Government PHR platform Yes – Fully HL7 FHIR-based with open APIs; apps write to/read from PHR using Finnish FHIR profiles.
Taiwan My Health Bank National PHR Portal (NHI) Partial – APIs/SDK provided; transitioning toward FHIR from legacy HL7 standards.
India Ayushman Bharat Digital Mission (ABDM) National Health IT Framework Yes – HL7 FHIR adopted as primary exchange standard; personal consent-based PHR model.

How to Use This Implementation Guide

This Implementation Guide provides three main areas of guidance:

  1. File Formats — The .phr and .sphr file extensions for portable personal health records (see Record Keeping)
  2. API Patterns — Endpoints for importing and exporting health records (see API Endpoints)
  3. Data Model — Mapping PHR-S Functional Model requirements to FHIR resources (see Data Model)

The only portion of this guide required for conformance testing is the ability to import and export .sphr files. All other sections are informational and assist implementers in modeling patient health histories using FHIR.

Use Cases

This guide is particularly interested in the problem of collecting and aggregating medical records from multiple healthcare systems and devices into a coherent whole. In the healthcare industry, these types of compiled records are known as longitudinal records. These needs arise in many situations: longitudinal health records and studies, snowbirds, symptom tracking, Long COVID, multiple chronic conditions, lifelogs, healthy living, differential diagnoses, alternative care, bring-your-own-device, the foster care system, migrants/immigrants, and climate refugees.

See the Use Cases page for detailed scenarios describing how a Personal Health Record supports each of these situations.

Acknowledgements

  • Jan Oldenburg, Patient Empowerment Workgroup
  • Dr. Neelima Karipineni, MITRE
  • Salim K Semy, MITRE
  • Dave Carlson, Clinical Cloud Solutions
  • Savannah Mueller, EMI Advisors

References

License

Copyright (c) 2021+ Health Level Seven International and MITRE.org.
Published under the Creative Commons "Attribution 4.0 International" (CC BY 4.0) License

Dependencies

Package hl7.fhir.uv.extensions.r4#5.3.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, May 16, 2026 18:32+1000+10:00)

Package hl7.fhir.uv.ips#1.1.0

International Patient Summary (IPS) FHIR Implementation Guide (built Tue, Nov 22, 2022 03:24+0000+00:00)

Package hl7.fhir.uv.tools.r4#1.1.2

This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00)

Globals

There are no Global profiles defined

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.uv.phr.r4) and R4B (hl7.fhir.uv.phr.r4b) are available.

IP Statements

This publication includes IP covered under the following statements.