The right to data portability: FHIR APIs and what patients can actually access
FHIR APIs promise patients the right to access and move their health data. The reality is that most patients can only retrieve a narrow slice of their record, and what they get lacks the provenance and trust scoring needed for meaningful use. The gap between legal right and practical access defines the next frontier of health data governance.
Patients in the United States have a legal right to access their medical records. They have had this right since 1996. Yet in 2024, fewer than 10% of patients who downloaded their records through a FHIR-based Patient Access API could identify all the data sources that contributed to that record. The right to data portability exists on paper. What patients actually receive through FHIR APIs is a different story.
What is the right to portability in HIPAA?
HIPAA's Privacy Rule grants individuals the right to access and obtain a copy of their protected health information (PHI) held by covered entities. This includes medical records, billing records, and other data used to make decisions about care. Covered entities must respond to access requests within 30 days and can charge only a reasonable, cost-based fee.
But HIPAA portability is narrower than most patients assume. It covers data held by a specific covered entity. It does not create a unified view across providers, payers, and labs. A patient who sees three specialists, uses a pharmacy benefit manager, and has lab work at two facilities must file separate requests to each organization. HIPAA gives you the right to your data. It does not give you your data in one place.
What does data subject right to data portability mean?
Under GDPR, the right to data portability means a data subject can receive their personal data in a structured, commonly used, machine-readable format and transmit it to another controller without hindrance. The U.S. does not have a direct equivalent, but the CMS Interoperability and Patient Access Final Rule moves in that direction. It requires CMS-regulated payers to implement Patient Access APIs using HL7 FHIR R4 standards, enabling patients to access claims, encounter data, and clinical information through third-party apps.
The CMS rule went into effect January 1, 2021 for most impacted payers. By July 2021, Medicare Advantage, Medicaid, and CHIP plans were required to have operational Patient Access APIs. The 21st Century Cures Act reinforces this by prohibiting information blocking among healthcare providers, health IT developers, and health information exchanges.
How do FHIR APIs work?
FHIR (Fast Healthcare Interoperability Resources) defines a set of standardized resources, such as Patient, Condition, Observation, and MedicationRequest, that can be exchanged between systems via RESTful APIs. A FHIR API exposes these resources as endpoints. A patient-authorized third-party app sends an authenticated request, receives a JSON or XML response, and displays the data.
The HL7 FHIR Patient Access API uses SMART on FHIR for authorization. The patient authenticates through their payer or provider portal, grants scoped permissions to the app, and the app retrieves the permitted resources. In practice, this means a patient can pull claims data, lab results, medication lists, and some clinical notes into a mobile app.
The problem is scope. FHIR US Core profiles define a minimum set of data elements. Most implementations expose only what US Core requires. Radiology images, pathology reports with full narrative, behavioral health notes, and social determinants of health data are frequently absent. The API works. What it returns is incomplete.
Do patients have a right to access their medical record?
Yes. Under HIPAA, patients have the right to inspect and obtain a copy of their PHI in a designated record set. The 21st Century Cures Act strengthened this by defining electronic health information (EHI) broadly and prohibiting information blocking. As of October 6, 2022, the information blocking provisions apply to all EHI, not just the US Core Data for Interoperability (USCDI) subset.
But access does not equal understanding. A patient who downloads a C-CDA document or a FHIR Bundle receives coded data. ICD-10 codes, LOINC identifiers, and RxNorm concepts are machine-readable. They are not patient-readable without interpretation layers. And critically, the data arrives without any indicator of its trustworthiness. Was the diagnosis code assigned by a clinician or auto-populated by a billing system? Is the lab result from a CLIA-certified facility? When was the record last validated?
Key statistics
FHIR adoption and patient access numbers tell a clear story about the gap between policy and practice.
The trust gap in portable data
Moving data is not the same as trusting data. A FHIR API delivers structured health records from point A to point B. It says nothing about whether the data at point A was accurate, current, or properly consented.
Consider a patient who uses a FHIR-enabled app to aggregate records from three health systems. The app receives three medication lists with overlapping entries, two conflicting allergy records, and a diagnosis code that was entered during a billing audit rather than a clinical encounter. The patient now has portable data. They do not have trustworthy data.
This is where FHIR patient data portability meets its practical limit. The standard solves transport. It does not solve trust. Health data access rights give patients a legal mechanism. They do not give patients a quality mechanism.
The DTI framework addresses exactly this gap. Every record that passes through the DTI Engine receives a score from 0 to 100 across Provenance, Consent, Recency, Quality, Concordance, Validation, Breadth, and Stability. A patient using MyBio.Health can see not just their data, but how trustworthy each element is. A researcher querying that data through SuperTruth's Data Reservoir knows the DTI floor before building a cohort. A payer deploying AI against claims data knows which records meet the threshold for clinical decision support.
What the CMS interoperability rules actually require
The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) requires four categories of action. First, payers must implement a Patient Access API using FHIR R4. Second, they must implement a Provider Directory API. Third, they must send admission, discharge, and transfer (ADT) event notifications. Fourth, under the subsequent CMS-0057-F rule, payers must implement a Prior Authorization API and a Payer-to-Payer API by January 2027.
These rules create the pipes. They standardize the format. They do not score the data flowing through those pipes. A Patient Access API can return a FHIR Bundle with a Provenance resource attached, but most implementations leave the Provenance resource empty or omit it entirely. The FHIR standard includes a Provenance resource type. Adoption of that resource in production APIs remains below 15% according to industry implementation surveys.
FHIR API patient trust requires more than transport standards. It requires a trust layer that scores data before it moves, while it moves, and after it arrives.
The DTI Engine scores every health data record 0 to 100 across 8 trust dimensions before your AI model sees it. If your team is building on FHIR APIs, evaluating data for training, or trying to make patient-facing data meaningful, contact Louis Simeonidis at louis@supertruth.ai or (215) 918-4140.
Further reading:
Jason Alan Snyder
Co-founder of SuperTruth and Artists & Robots, and an inventor on the Data Trust Index patents. Twenty-plus years building technology inside Interpublic Group. He writes here nearly every day on data trust, provenance, and what AI should be allowed to act on, and publishes essays on his Substack.
About SuperTruth · LinkedIn · Substack · jasonalansnyder.com
See it in practice
DTI scores the record, not the patient.
8 dimensions. 0–100. Travels with every record permanently.