Why the CMS patient app pledge depends on the registration desk

The week

On July 30, 2025, at a White House event, the Centers for Medicare & Medicaid Services announced a health technology ecosystem initiative. More than 60 organizations, including technology companies, EHR vendors, health systems, payers and app developers, pledged to take part. CMS published an interoperability framework and invited networks to become CMS Aligned Networks, committing to let patients retrieve records through apps of their choice using modern standards and digital identity credentials. CMS said 21 networks had pledged to meet the framework. The initiative also promoted conversational AI tools for patients and digital check-in to replace paper intake forms, under the slogan kill the clipboard. Participants were asked to show results in the first quarter of 2026. Participation was voluntary, and the announcement created no new regulatory requirements.

Patient access rules are not new. The 21st Century Cures Act’s information blocking provisions and CMS’s patient access API requirements already obliged many providers and payers to make data available. The July 2025 initiative tried to change the experience rather than the law: a patient opens an app, proves who they are once, and pulls records from many organizations into one place.

The exchange standards behind that experience largely existed. The harder parts sit around the exchange and land on a health system’s front office. There are three: proving identity, matching records, and handling consent and proxies. They occur in that order for every request, and a failure at any one of them stops the patient. None is solved by an API alone.

Proving identity

Before releasing records, a health system must be confident that the requester is the patient or someone authorized to act for them. Today that usually means a portal account activated at a visit, or by a code sent to a phone or address on file. The initiative pointed to a different model: patients verify once with a credential meeting federal digital identity standards, then reuse it across organizations.

That model moves trust outside the health system’s walls. Someone has to decide which credential providers the organization will accept, at what assurance level, and what happens when a credential is compromised. A stolen credential that unlocks records from every connected organization is a larger prize than a single portal password. Medical identity theft becomes easier to scale.

Remote proofing also fails some patients predictably. Older patients, people without smartphones, recent immigrants and people whose documents do not match their registration details are all more likely to be rejected. A health system that offers only remote proofing pushes those patients back to the phone line or the clipboard. The practical answer is an in-person proofing path at registration, with staff trained to issue or verify the credential during a visit. That is a staffing and workflow decision, not a technology purchase.

Matching records

Once identity is established, the system must find the right records. The United States has no national patient identifier; Congress has long barred HHS from spending funds to adopt one. Matching relies on demographic data such as name, date of birth, address and phone number. Those fields change, contain typos and sometimes collide between different people.

Every matching algorithm trades two errors against each other. A strict threshold misses records, which the patient experiences as gaps. A loose threshold attaches someone else’s records, which is a privacy breach delivered straight to a stranger’s phone. Clinician-facing exchange can tolerate some of both, because a professional reviews the result. Patient-facing retrieval cannot, because there is no reviewer.

Health systems should know their own numbers before scaling app access: the duplicate record rate, the frequency of overlays where two people share one record, and how long corrections take. Health information management teams own those processes. If retrieval volume rises and those teams do not grow, correction queues lengthen and the errors persist in the apps patients use.

Visibility has a second-order effect. Patients who can read their records in an app find errors that used to go unnoticed, from wrong medications to someone else’s diagnosis. HIPAA gives them a right to request amendment, and each request needs a documented response. Organizations should expect that workload to grow with app adoption and route it to a team that can answer quickly.

Handling consent and proxies

Patients generally have a right under HIPAA to direct their records to an app. Most consumer apps are neither covered entities nor business associates, so HIPAA protections usually stop once the data leaves. The Federal Trade Commission’s Health Breach Notification Rule covers many such apps, but its protections differ from HIPAA’s, and patients rarely know which regime applies.

Information blocking rules limit a health system’s ability to refuse access because it dislikes an app’s privacy practices. It can still explain clearly, at the moment of release, where protections change. Sensitive categories need extra review. Substance use disorder records covered by 42 CFR Part 2, reproductive and behavioral health data, and adolescent records protected by state law each raise different questions. Counsel should review how they flow through app-based retrieval.

Proxies are the hardest case and the most common. Parents of minors, adult children managing an aging parent’s care, and legal guardians all request records for someone else. Digital identity frameworks are built around one adult proving who they are. They do not establish that a person holds authority over another person’s records, or that a teenager’s confidential visit should be hidden from a parent. Health systems need a defined way for proxies to prove authority in an app-based model, with staff who can resolve disputes. Without one, proxy requests fall back to fax and paper, and the experience the initiative promised reaches only the simplest cases.

Measured together, the three parts suggest a single test. Count how many patients who start an app-based request finish it, broken out by age group and by whether they needed help. That completion rate says more about patient access than the number of live connections.

With hindsight

Through 2026, CMS showcased demonstrations from participants, and several companies announced that they had reached production as CMS Aligned Networks or had launched digital check-in built on reusable identity credentials. Those announcements came mostly from the participants themselves. We have not found independent data on how many patients use the tools, or how completion rates vary across patient groups, and we would not claim more than the participants have reported.

The diagnosis holds. The voluntary framework moved the technical plumbing forward, while the work that decides whether a given patient succeeds stayed in registration, health information management and patient support. The 42 CFR Part 2 compliance date of February 2026 also arrived during the pledge period, adding a sensitive-data question to the consent work. Health systems that staffed in-person identity proofing, measured matching errors and defined proxy authority are better placed to say whether access actually improved.