Patient-mediated data exchange in 2026: what works, what doesn't, and who is actually using it

Patient-mediated data exchange is the pattern where the patient, not a vendor, holds and releases their own clinical record to clinicians, apps, or another payer on demand. 2026 is the inflection point because CMS-0057-F took effect on January 1, 2026 with the Patient Access API now expanded to prior-authorization status, the ONC US Core Data for Interoperability (USCDI) version 4 became the floor for certified EHRs, and the Trusted Exchange Framework and Common Agreement (TEFCA) crossed ten designated Qualified Health Information Networks (QHINs). The architectural question for product teams is no longer whether to support patient-mediated exchange, but which pattern to build against.

The patient-mediated pattern, in one paragraph

The pattern is simple. The patient is the authorization layer. Clinical data sits in an EHR, a payer claims system, a lab, or a wearable. When the patient wants that data somewhere else, they release it directly using a token issued under their own credentials, without a central PHR vendor sitting in the middle as a data broker. The legal floor for this in the United States is the 21st Century Cures Act information-blocking rule (45 CFR Part 171), which since April 2021 has prohibited actors from interfering with the access, exchange, or use of electronic health information. The technical floor is FHIR R4 (HL7 FHIR 4.0.1, released October 2019) plus the SMART App Launch Framework 2.0.0. The data floor is USCDI v4, finalized by ONC in July 2023 and required in certified EHRs from January 1, 2026 under the HTI-1 final rule.

The PHR-tarpit critique

Brendan Keeler, writing on healthapiguy.substack.com, has made the sharpest version of the patient-mediated argument. His framing, the PHR tarpit, says vendor-locked patient portals absorbed two decades of healthcare engineering attention and capital without producing interoperability. Patients ended up with one portal per provider, no consolidated record, and no portability. Keeler's argument is that patient-mediated exchange is the architecturally honest alternative because it places the authorization layer where it belongs, with the patient. The patient holds the credentials. The patient releases the data. The vendor does not own the relationship.

This is not a moral argument, it is an architectural one. A portal that requires a separate login per institution is by definition not interoperable. A patient-held record with SMART on FHIR token exchange against any compliant endpoint is interoperable by construction. The Health Tech Nerds (HTN) community has carried this framing since 2022 and it now shows up in how regulators write rules. CMS-0057-F is written assuming the patient is the integration point, not the payer.

What is actually working in 2026: the comparison table

ApproachMaintainerScopeAdoption signalBest-fit use caseApple Health (FHIR Bundle export)AppleiOS 16.4+ exports a FHIR R4 Bundle from connected providersOver 800 US health systems connected to Apple Health Records as of Q4 2025 per Apple's developer documentationConsumer-side handoff of records from a provider visit to a third-party appGoogle Health Connect (Android FHIR)GoogleAndroid 14+ Health Connect with FHIR R4 read APIs in betaPre-installed on Android 14+, FHIR support announced at Google I/O 2024Wearable plus clinical data merge on Android devicesTEFCA (QHIN network)The Sequoia Project as Recognized Coordinating Entity under ONCNetwork-to-network exchange across designated QHINs including FastenHealth, Epic Nexus, eHealth Exchange, CommonWell, Health Gorilla, MedAllies, Konza, Kno210 designated QHINs as of January 2026 per Sequoia Project's QHIN directoryTreatment, payment, operations, public health, individual access, government benefitsHealthWallet.meLife Value (open source)Patient-held EHR on iOS and Android, FHIR-native, encrypted on device, biometric unlock, IPS export via the fhir_ips_export Flutter packageOpen-source release with the fhir_ips_export package on pub.dev, TEFCA participation via the FastenHealth on-prem partnershipIndividual patient ownership of a longitudinal record, cross-border handoff using HL7 International Patient SummaryMyHealth@EUEuropean Commission DG SANTE under the European Health Data Space (EHDS) RegulationCross-border ePrescription and Patient Summary exchange across EU member statesEHDS Regulation entered into force March 26, 2025, MyHealth@EU services live in 14 member states as of Q1 2026 per the European Commission's eHealth NetworkEU cross-border care, EHR primary-use under EHDS

Where each one breaks in 2026

Apple Health Records is the easiest consumer onboarding path but it does not export every USCDI v4 clinical category. Encounters, conditions, medications, immunizations, lab results, procedures, and vitals are reliable. Clinical notes, care plans, goals, and assessments are inconsistent. The export is provider-dependent, so a patient with five providers can get five different shapes.

Google Health Connect on Android has good wearable coverage but FHIR R4 read coverage is uneven by OEM and country. The Health Connect FHIR APIs were announced at Google I/O 2024 and remain in staged rollout. Treat it as production for fitness and sleep, beta for clinical.

TEFCA QHIN onboarding is slow by design. Becoming a QHIN takes 12 to 18 months and costs over one million USD in legal, technical, and audit work according to the Sequoia Project's onboarding documentation. The individual access use case (an individual requesting their own data through a QHIN) only went live in late 2024. Most provider organizations are still wiring up treatment exchange.

HealthWallet.me requires the patient to install an app and trust on-device encryption. The pattern is correct, the adoption barrier is real. Carriers and health systems that want patient-mediated exchange need to either fund a co-branded distribution or accept that a fraction of the patient population will participate.

MyHealth@EU rollout is uneven by member state. Estonia, Finland, Portugal, Croatia, and Czechia were early. Germany and France joined Patient Summary exchange in 2024 and 2025. Several southern and eastern member states are still in pilot. The EHDS secondary-use provisions ramp into 2029, so the cross-border story for 2026 is primary-use only.

The architectural choice for product teams

The decision framework is short. Build another vendor-locked portal and the product becomes a tarpit, by Keeler's definition. Build SMART on FHIR launch into the patient's existing app, whether that is Apple Health, Google Health Connect, or HealthWallet.me, and the product is patient-mediated. Build TEFCA QHIN participation, either directly or through a participant member, and the product is network-mediated. Most production architectures in 2026 ship two of the three: patient-mediated for the consumer surface, network-mediated for clinical exchange.

The choice depends on the buyer's regulatory exposure and the use case. A US carrier subject to CMS-0057-F has to ship Patient Access API and Provider Access API endpoints. A US health system has to ship the certified-EHR USCDI v4 floor under HTI-1. An EU public health authority has to ship MyHealth@EU connectivity under the EHDS Regulation. An ISV selling into any of the above has to support SMART on FHIR launch as the table stakes.

What this means for the 7 healthcare ICPs

Insurance carriers and payers. CMS-0057-F member access expanded the Patient Access API to prior-authorization status, decisions, and supporting documents. The compliance deadline was January 1, 2026 for non-grandfathered Medicare Advantage, Medicaid, CHIP managed care, and qualified health plans on the federally facilitated exchange. Patient-mediated exchange is now a regulated payer obligation, not an option. The prior-auth share-back is the highest-impact build.

Public health systems and ministries. The EHDS Regulation made the national patient-summary contribution to MyHealth@EU a member-state obligation. Ministries that have not stood up a National Contact Point for eHealth (NCPeH) are now late. Patient-mediated exchange at the EU level is built on the IHE Cross-Community Patient Discovery and Cross-Community Document Sharing profiles plus the HL7 International Patient Summary.

Private hospitals, clinics, integrated delivery networks. The high-value use case is discharge summary handoff. A discharged patient with a HealthWallet.me or Apple Health Record carrying the IPS bundle gives the receiving primary-care clinician a usable record without faxing. The hospital reduces 30-day readmission risk and the clinician saves intake time.

Established healthcare companies (medical-device, pharma, diagnostics, distributors, labs). A digital companion that respects patient consent and uses SMART on FHIR for the clinical context launch ships faster, audits cleaner, and ports across geographies. The alternative, a proprietary patient portal per product line, is the tarpit Keeler described.

Healthcare ISVs and digital-health platforms. FHIR R4 is the canonical interchange model. Build the data layer as FHIR resources, build the auth layer as SMART App Launch 2.0.0, and the product becomes a SMART-conformant app rather than an integration project. This shortens hospital procurement cycles measurably.

Healthtech founders pre-seed through Series B. The advice is direct. Do not build another vendor-locked portal. The category is saturated, the architecture is wrong, and the regulatory direction is against you. Build into the patient-mediated layer or into the network-mediated layer.

Individuals (via HealthWallet.me). The end-state for the individual is one record under their own control, portable across providers, payers, and geographies. HealthWallet.me is the open-source version of that record. Encrypted on device, biometric unlock, IPS export, no vendor account in the middle.

Where Life Value sits in this

Life Value builds HealthWallet.me and the fhir_ips_export Flutter package. HealthWallet.me is the patient-held EHR. fhir_ips_export takes a FHIR Bundle and produces a conformant HL7 International Patient Summary, which is the document the EU MyHealth@EU network and the TEFCA individual access use case both accept. We work with carriers on CMS-0057-F readiness, with health systems on SMART on FHIR launch into the patient's app, and with founders on shipping into the patient-mediated layer instead of building another portal.

The orchestration gap, in Jan-Felix Schneider's framing, is the reason this work is not commoditized. Healthcare organizations are not buyers of microservices. They need the FHIR layer, the SMART layer, the TEFCA participant relationship, the device-side encryption, and the IPS export to arrive as one working product. That is the orchestration we ship.

Further reading

• Brendan Keeler, the PHR tarpit and patient-mediated exchange essays at healthapiguy.substack.com
• HL7 FHIR R4 specification at hl7.org/fhir/R4
• ONC Cures Act Final Rule and information-blocking guidance at healthit.gov/topic/oncs-cures-act-final-rule
• CMS-0057-F, Advancing Interoperability and Improving Prior Authorization Processes, at cms.gov/priorities/key-initiatives/burden-reduction
• FastenHealth, designated QHIN, at fastenhealth.com
• The TEFCA Common Agreement at rce.sequoiaproject.org/tefca
• MyHealth@EU at the European Commission eHealth portal, health.ec.europa.eu/ehealth-digital-health-and-care
• HealthWallet.me, the open-source patient-held EHR by Life Value, at healthwallet.me