The PHR tarpit, revisited: what a patient-held EHR looks like in 2026

Brendan Keeler wrote on Health API Guy (healthapiguy.substack.com) that personal health records severely fail to solve problems. He was right about every PHR that had shipped through the 2010s, and his framing of the PHR as a tarpit idea is one of the cleanest pieces of analysis in the interoperability canon. This piece is not a takedown of that argument. It is a response from 2026, after the regulatory ground underneath the question has been rewritten by CMS-0057-F, mature Cures Act information-blocking enforcement, the live TEFCA Qualified Health Information Network, and the European Health Data Space.

The short version: Brendan's critique was correct for the era it described. The architectural defaults for a patient-held EHR in 2026 are different. Below is what changed, why HealthWallet.me sits in a different category from the products in the PHR graveyard, and where Life Value fits in the wider picture.

What Brendan Keeler got right

Brendan's Health API Guy post 'Indiana Jones and the Personal Health Record' (June 2023) walked through the graveyard carefully. Google Health, Microsoft HealthVault, Dossia, Revolution Health. Each one was well funded, well staffed, and shipped by people who knew what they were doing. Each one shut down within a few years of launch. His core point was structural, not cultural: the vendor-locked patient portal was a tarpit because the data plumbing was not there, the consumer would not pay, the hosting layer was both a security target and a business-model trap, and the distribution path through the app stores ran into the same friction every generic consumer health app hits.

That argument was correct. It is still correct about the products it was written about. Lisa Bari of Innovaccer made the same point in the Health Tech Nerds archive in June 2023: 'Multiple concepts have been proposed or built over the years around a physical PHR and it has never caught on / been picked up.' Dave Boerner, writing in the same channel and from inside a prior-generation PHR effort, put the business-model problem more directly: 'Consumers won't pay for health. It needs to be sponsored by providers / payers / etc.' Jan-Felix Schneider at healthtechstack catalogued the PHR on his tarpit-ideas list. None of that consensus was wrong.

The generic PHR products that came out of the 2010s failed for the reasons Brendan named. Anyone shipping a fresh consumer-pay PHR in 2026 will fail for the same reasons. The HTN PHR-tarpit framing should be required reading for anyone considering one.

What changed in 2024 to 2026

Five regulatory and infrastructure pieces moved between the publication of Brendan's post and today.

CMS-0057-F is in effect. The Centers for Medicare and Medicaid Services Interoperability and Prior Authorization Final Rule (CMS-0057-F, published 17 January 2024) reached its operative compliance dates on 1 January 2026 for the Patient Access API and Provider Access API extensions, with the Payer-to-Payer API and Prior Authorization API compliance date set for 1 January 2027. Impacted payers, including Medicare Advantage organizations, state Medicaid and CHIP Fee-for-Service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on Federally Facilitated Exchanges, are now in production with FHIR R4 Patient Access endpoints carrying claims, encounter, clinical, and prior-authorization data. The plumbing is no longer aspirational.

21st Century Cures Act information-blocking enforcement is mature. The Office of the National Coordinator and HHS Office of Inspector General disincentives framework for information blocking (45 CFR Part 171) is past its early-implementation phase. Civil monetary penalties for healthcare providers and disincentives applied through CMS programs are no longer theoretical. The patient-access FHIR R4 endpoints required by ONC's Health IT Certification Program are live across the certified EHR base, with the (g)(10) Standardized API criterion covering SMART on FHIR launches.

TEFCA QHIN network is operational. The Trusted Exchange Framework and Common Agreement designated its first set of Qualified Health Information Networks in 2023 to 2024. As of 2026, the QHIN network is in production exchange with multiple designated QHINs handling patient-access, individual-access-services, treatment, and payment use cases. FastenHealth is a designated QHIN handling individual access services, which is the use case a patient-held EHR rides on.

Apple Health and Google Health Connect ship FHIR R4 export. Apple Health has supported FHIR R4 export of clinical records on iOS since 2018 and reached broad institutional coverage through the patient-access API era. Google Health Connect added FHIR R4 export pathways for clinical records in 2024 to 2025 alongside its broader Android health-data API. Both platforms route to the patient's device by default. There is no aggregator in the middle.

EHDS is rolling out. Regulation (EU) 2025/327 of the European Parliament and of the Council on the European Health Data Space entered into force on 26 March 2025. The Regulation establishes MyHealth@EU as the primary infrastructure for cross-border electronic health record exchange and mandates patient access to electronic health records in priority categories (patient summary, electronic prescription, electronic dispensation, medical imaging, laboratory results, hospital discharge reports) on phased compliance dates through 2027 and 2029. EU public-health programs procuring patient-held EHR software now operate under a statutory requirement to provide patient-mediated access, not under a wish list.

The five conditions, restated for 2026

The PHR tarpit condition (as Brendan Keeler framed it)The 2026 architectural defaultConsumers will not pay for health software.The patient-held EHR is sponsored by payers, hospitals, employer benefits programs, and EU public-health programs. The patient pays nothing. The MIT license on HealthWallet.me makes this commitment durable: any future pivot to a consumer-pay model is structurally blocked by the open-source fork option.A hosted PHR is a centralized security target and a data-mining business model waiting to happen.The patient-held EHR has no back end. Records live encrypted on the device behind biometric authentication. The breach surface is per-device. The data-mining business is structurally impossible because the data is not in the operator's reach.The data is too distributed across walled gardens to actually populate a PHR.CMS-0057-F Patient Access API, Cures Act (g)(10) patient-access FHIR R4 endpoints, the TEFCA QHIN network via FastenHealth, Apple Health FHIR R4 export, and Google Health Connect FHIR R4 export collectively deliver patient-mediated access at scale. EHDS Regulation 2025/327 extends the same default to the EU.Generic consumer health apps cannot win the app-store distribution game.The patient-held EHR is open-source infrastructure that a payer or hospital ships through its own member app, branded as the sponsor's product. The distribution path is sponsor-led, not consumer-acquisition-led.The PHR has a 20-year graveyard.The PHR graveyard is a graveyard of products in a specific category: hosted consumer-pay PHRs running against pre-Cures-Act data plumbing. A patient-held EHR riding on FHIR R4 patient-access endpoints with an open-source codebase and sponsor distribution sits in a different category by construction.

Why HealthWallet.me is not a tarpit

HealthWallet.me is the open-source patient-held EHR Life Value builds and maintains. The architecture, licence, and distribution model address each row of the table above by design rather than by hope.

• Open source under MIT. The repository is public on GitHub. The Android and iOS binaries on the app stores compile from the same source. Any sponsor (payer, hospital, EU public-health program, employer) can fork, brand, and ship the app without licensing it from Life Value. The MIT license makes that path permanent.
• FHIR R4 native. The data model inside the app is FHIR R4 resources (Patient, Observation, Condition, MedicationStatement, AllergyIntolerance, Immunization, DocumentReference, Encounter, Procedure, DiagnosticReport, and the rest of the US Core and International Patient Summary set). No proprietary intermediate format. The export path is an International Patient Summary IPS bundle, which is the same artefact MyHealth@EU exchanges under EHDS.
• On-device encryption. Records live in an encrypted store on the patient's device, behind a biometric unlock (Face ID, Touch ID, Android BiometricPrompt). There is no HealthWallet cloud. There is no central database. There is no aggregation target.
• TEFCA participation through FastenHealth. FastenHealth is a designated QHIN handling individual access services on the TEFCA network. HealthWallet.me retrieves records through the FastenHealth connection, which gives the patient access to the US health system network covered by TEFCA. There is no Life Value-side store.
• Patient as the authorization layer. The patient holds the credentials, authorizes the SMART on FHIR launch, and controls what data leaves the device. The architectural decision to put the patient in the authorization position is the same decision the Cures Act, EHDS, and CMS-0057-F Patient Access API are encoding into regulation.

The architectural decision tree

Healthcare organizations evaluating patient-data architecture in 2026 face three live options. The decision tree below is the one we apply when we advise payers, hospitals, and ISVs on which path fits which problem.

PatternWhen to build itWhen to avoid itBuild a vendor-locked patient portalAlmost never in 2026. The use cases the patient portal historically owned (record review, secure messaging, appointment booking, bill pay) are better served by FHIR R4 endpoints feeding a sponsor-branded app that the patient already has installed.Almost always. The patient-portal tarpit Brendan Keeler described is still a tarpit. Vendor lock plus consumer-pay assumptions plus per-system fragmentation produce the same failure mode they produced in the 2010s.Build patient-mediated exchange (a patient-held EHR layer)Almost always when the goal is patient access to records across multiple providers, member-app utility for a payer, citizen access for an EU public-health program, or employer benefits utility.When the use case is provider-to-provider treatment exchange that does not need patient mediation. Use TEFCA treatment exchange or HIE infrastructure for that path.Participate in TEFCA as a QHIN or QHIN participantWhen the organization is a payer needing CMS-0057-F Payer-to-Payer exchange, a large health system needing nationwide treatment exchange, or an aggregation layer (like FastenHealth) providing individual access services to downstream apps.When the organization is a single-provider clinic, a smaller payer below the CMS-0057-F threshold, or a non-US entity. EHDS MyHealth@EU is the equivalent path in the EU.

Where Life Value sits in this

Life Value occupies the orchestration layer Jan-Felix Schneider has described in healthtechstack: healthcare organizations are not buyers of microservices, and they generally do not have an engineering team large enough to wire Redox, Particle Health, Health Gorilla, Candid, MedPlum, Aptible, Verifiable, Eligible, and Vanta together. Life Value sits in that wiring layer.

Concretely, this means three lines of work:

• HealthWallet.me. We build and maintain the open-source patient-held EHR. Public repository, MIT license, FHIR R4 native, on-device encryption, biometric unlock, FastenHealth TEFCA pipe for US records, EHDS IPS bundle for EU records. Sponsors (payers, hospitals, employers, public-health programs) ship branded instances to their members, patients, or citizens.
• fhir_ips_export Flutter package. We build and maintain the Flutter package that produces and consumes International Patient Summary FHIR bundles. This is the package HealthWallet.me uses internally and the package any Flutter health app can install to add IPS export.
• CMS-0057-F readiness and SMART on FHIR builds for healthcare ISVs and payer engineering teams. We partner on the implementation work behind Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API endpoints, on the SMART on FHIR app launches that ride on those endpoints, and on the HL7 FHIR R4 conformance work the CMS rule requires. ISO/IEC 27001:2022, HIPAA, and GDPR posture is built in from the start.

The bear case

Writing the bear case in our own words is the test of whether we understand our own position. The HealthWallet.me bear case has three live failure modes.

First, the Cures Act and CMS-0057-F FHIR endpoints underperform in practice. The endpoints exist, but vendor-level data quality (USCDI conformance, completeness, accuracy) is uneven. ONC's annual Standards Maturity scoring across 2024 to 2026 has documented variation between certified EHR products. If the data the patient retrieves is incomplete or inaccurate enough to break the use case, sponsor adoption stalls. This is a real risk and the one we monitor most closely.

Second, no sponsor steps forward at scale. A patient-held EHR with no payer, hospital, or public-health programme shipping a branded instance is an engineering artefact, not a product. We address this by partnering directly with sponsors on the readiness work for CMS-0057-F and EHDS, but the risk is not zero.

Third, a national-scale public-sector PHR equivalent (the German ePA pattern, scaled to additional member states) fills the slot with a state-mandated artefact rather than an open-source one. EHDS leaves room for both, but a member state choosing a single national app is an outcome we cannot rule out.

None of these failure modes is the original tarpit argument applied unchanged. They are failure modes specific to the 2026 environment. That is the test the original argument has to pass to remain load-bearing: does it survive the architectural changes that happened after it was written?

An open invitation

If you read healthapiguy.substack.com and disagree with this take, push back. The PHR-tarpit framing has done more to clarify the patient-data conversation than any other piece in the interoperability canon, and any rebuttal of it should be taken apart in public. The conversation moves the field forward. We will publish the disagreement intact.

Frequently asked questions

Is HealthWallet.me a personal health record?

Yes by literal definition: the patient holds their own records on their device. No by the category Brendan Keeler analysed in the PHR-tarpit piece: HealthWallet.me is not a hosted consumer-pay PHR, has no central aggregation target, and is not distributed through consumer acquisition. It is open-source infrastructure that healthcare organizations distribute to their members, patients, or citizens.

How is this different from the PHRs Brendan Keeler described?

The four structural conditions that killed the prior PHRs (consumers will not pay, hosted PHRs create centralized targets, data was too distributed, generic consumer apps lose the distribution game) have been rewritten by CMS-0057-F, Cures Act enforcement, the TEFCA QHIN network, EHDS, Apple Health FHIR R4 export, and Google Health Connect FHIR R4 export. HealthWallet.me operates inside the new conditions and is open-source plus on-device by construction. It sits in a different architectural category.

Who pays for HealthWallet.me?

Sponsors. Payer member apps, hospital portals, employer benefits programs, EU public-health programs, and the FastenHealth TEFCA pipe. The patient pays nothing. The code is MIT-licensed, which makes the sponsor-pay model durable.

Where do the records live?

On the patient's device, encrypted at rest, behind biometric authentication. There is no HealthWallet cloud, no Life Value-side store, no central aggregation target.

How does HealthWallet.me retrieve data from EHRs?

Through FHIR R4 patient-access endpoints exposed under the 21st Century Cures Act (g)(10) certification criterion, through CMS-0057-F Patient Access API endpoints at impacted payers, through the FastenHealth TEFCA pipe for nationwide US individual access services, through Apple Health FHIR R4 export on iOS, through Google Health Connect FHIR R4 export on Android, and through MyHealth@EU under EHDS Regulation 2025/327 for EU citizens.

Is this a TEFCA-certified app?

The TEFCA designation is held at the QHIN layer, not the app layer. HealthWallet.me participates in TEFCA through FastenHealth, which is a designated QHIN handling individual access services. The patient retrieves records under TEFCA's individual access services use case via FastenHealth's QHIN designation.

Where can I read Brendan Keeler's original argument?

healthapiguy.substack.com. The PHR-tarpit framing comes from his 'Indiana Jones and the Personal Health Record' piece published in June 2023. Anyone evaluating patient-data architecture should read it carefully before building anything in this space.

Read this next

• Brendan Keeler, 'Indiana Jones and the Personal Health Record', Health API Guy, June 2023 (healthapiguy.substack.com)
• CMS, Interoperability and Prior Authorization Final Rule CMS-0057-F (published 17 January 2024, Patient Access and Provider Access API compliance 1 January 2026, Payer-to-Payer API and Prior Authorization API compliance 1 January 2027)
• ONC, 21st Century Cures Act Information Blocking final rule, 45 CFR Part 171, healthit.gov
• Regulation (EU) 2025/327 of the European Parliament and of the Council on the European Health Data Space (in force 26 March 2025)
• Office of the National Coordinator, Trusted Exchange Framework and Common Agreement, TEFCA QHIN designations
• HealthWallet.me, the open-source patient-held EHR Life Value maintains
• FastenHealth, designated QHIN for individual access services, the FHIR aggregation layer HealthWallet.me uses

Want to talk through the architecture?

If you are a payer innovation lead working on CMS-0057-F readiness, a hospital CIO weighing the patient portal versus patient-mediated exchange tradeoff, a public-health program manager scoping an EHDS deployment, an ISV building on FHIR R4 patient-access endpoints, or a healthtech founder figuring out where a patient-held EHR fits your architecture: we are happy to walk through HealthWallet.me, the FastenHealth TEFCA pipe, the on-device security model, and the sponsor distribution paths. Contact us at lifevalue.com/company/contact.

Last reviewed: 30 May 2026.