Why the CMS patient app pledge depends on the registration desk

The week

On July 30, 2025, the federal government said that patients should be able to pull their medical records into one place through the apps they choose. Take a woman in her seventies who sees a cardiologist at one hospital, a primary care doctor at a clinic across town and a specialist in another state. Her records live in three separate computer systems. If she wants them in one place today, she usually logs into three different patient portals, each with its own password, or asks her daughter to request paper copies.

At a White House event that day, the Centers for Medicare & Medicaid Services, the federal agency that runs Medicare and oversees Medicaid, announced what it called a health technology ecosystem initiative. More than 60 organizations pledged to take part: technology companies, makers of electronic health records (EHRs, the software hospitals and clinics use to keep patient charts), health systems, payers such as insurers, and app developers.

CMS published an interoperability framework. Interoperability means different computer systems being able to exchange information and make sense of it. The agency invited health data networks, the organizations that route records between hospitals, clinics and insurers, to become “CMS Aligned Networks.” Joining meant committing to let patients retrieve their records through apps of their own choice, using modern data standards and digital identity credentials. A digital identity credential is a verified online proof of who you are, something like a passport that works on the internet, which a person sets up once and can then present to many organizations. CMS said 21 networks had pledged to meet the framework.

The initiative reached beyond records. It promoted conversational AI tools for patients, meaning chat-style assistants that can answer questions in everyday language, and digital check-in to replace the paper intake forms most of us fill out in waiting rooms. The slogan was blunt: kill the clipboard.

Participants were asked to show results in the first quarter of 2026. Two details mattered as much as the headline. Participation was voluntary, and the announcement created no new regulatory requirements. The pledge was a public promise backed by reputation and attention rather than penalties, which meant the real test would come in the ordinary daily work of hospitals and clinics.

Patient access rules are not new. The 21st Century Cures Act, a federal law, includes “information blocking” provisions that bar health organizations from unreasonably standing in the way of patients getting their own electronic health information. Separately, CMS’s patient access API requirements already obliged many payers to make data available through an API.

An API, short for application programming interface, is a standard, published doorway that lets one piece of software ask another for information automatically. Any program that asks in the agreed format gets a predictable answer, without needing access to the system’s internals. In health care, the widely used format is a standard called FHIR (Fast Healthcare Interoperability Resources), which defines how things like a medication list, a lab result or an allergy should be described so that any app can read them.

So the July 2025 initiative did not try to change the law. It tried to change the experience. The promise: 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 they land on a health system’s front office, the registration desk, the medical records department and the patient support phone line. There are three: proving identity, matching records, and handling consent and proxies. They occur in that order for every request, a failure at any one of them stops the patient, and an API alone solves none of them.

What actually happens when a patient taps “get my records”

A single request shows how much human judgment the technology hides. Suppose a patient downloads a health app on her phone and taps a button to connect to the regional health system where she had knee surgery two years ago. Behind the scenes, three questions have to be answered in sequence.

1. Is this really the patient? The health system must be confident the person holding the phone is the patient, or someone entitled to act for her.
2. Which records are hers? The health system must find her chart among millions, and only hers.
3. What is she allowed to receive, and what happens once it leaves? Some parts of a record carry extra legal protection, and some requests come from a parent or caregiver rather than the patient.

The data standard handles the last step of the journey: packaging the records and sending them. Everything before that is a decision, and decisions involve policy, staff and judgment. So an executive who hears “we are connected to the network” should ask a follow-up question: connected for whom, and how many of them get through?

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.

A short explanation of how that verification works. “Identity proofing” is the process of confirming that a person is who they claim to be, usually by checking a government ID, sometimes with a selfie compared against the ID photo, and checking details against records such as credit files or phone accounts. Federal guidance describes “assurance levels,” which are roughly how hard the checks are. A low level might accept an email address; a high level might require a document check and a live photo match. Higher levels stop more impostors and also turn away more legitimate people.

The reusable-credential 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, where someone uses another person’s identity to obtain care, prescriptions or information, 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 woman who registered at the hospital under her married name but whose driver’s license still shows her maiden name may simply be told “we could not verify you.” A health system that offers only remote proofing pushes those patients back to the phone line or the clipboard, the very thing the initiative set out to remove.

The practical answer is an in-person proofing path at registration, with staff trained to issue or verify the credential during a visit. The decision concerns staffing and workflow; there is nothing to buy. It means a registrar who has time, training and a script, and a manager who counts how often it is used.

Matching records

Once identity is established, the system must find the right records. The United States has no national patient identifier, no equivalent of a single health ID number that follows a person everywhere; Congress has long barred HHS from spending funds to adopt one. Matching therefore 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. There are many people who share a common name and a birthday.

Software that does this job is often called a matching algorithm: a set of rules that scores how likely two records are to belong to the same person, and then accepts or rejects the match based on a threshold. Every matching algorithm trades two errors against each other. A strict threshold misses records, which the patient experiences as gaps: the knee surgery is simply not there. 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. A doctor who sees an implausible diagnosis in an incoming record will pause and question it. Patient-facing retrieval cannot, because there is no reviewer. The app displays whatever arrives.

Health systems should know their own numbers before scaling app access. Three are worth asking for by name:

• Duplicate record rate: how often one person has two or more charts, usually because a registrar did not find the first one.
• Overlays: how often two different people have been merged into one record, which is the more dangerous error.
• Correction time: how long it takes, once an error is found, to fix it.

Health information management teams, the staff who maintain the official medical record, 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, the federal health privacy law, 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. Seen positively, this turns patients into a quality-control force; seen poorly, it turns them into a stream of complaints.

Handling consent and proxies

Patients generally have a right under HIPAA to direct their records to an app, with a subtlety that surprises many executives. HIPAA applies to “covered entities” (health care providers, health plans and clearinghouses) and their “business associates” (vendors handling data on their behalf). Most consumer apps are neither, 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. A record that was tightly protected inside the hospital may, once in an app, be governed by the app’s own privacy policy and a different federal rule.

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. A plain notice, “once you send these records to this app, HIPAA no longer applies, and this is what that means,” respects the patient’s choice and the patient’s right to understand it.

Sensitive categories need extra review. Substance use disorder records covered by 42 CFR Part 2, a federal regulation that gives addiction treatment records stronger confidentiality than ordinary medical records, raise their own questions. So do reproductive and behavioral health data, and adolescent records protected by state law. Each raises different questions. Counsel should review how they flow through app-based retrieval.

Proxies are the hardest case and the most common. A proxy is someone acting on another person’s behalf. 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.

Suppose a father requests his 16-year-old daughter’s records through an app. His own identity checks out perfectly. But in some states, certain care a teenager receives can be confidential even from parents. The credential proves who the father is; it cannot tell the hospital what the father is entitled to see. 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.

Killing the clipboard runs into the same three problems

The initiative’s slogan, kill the clipboard, sounds like a separate project from records access. In practice it runs into exactly the same three questions, which makes it a useful way to see the whole picture.

Take a community hospital that replaces its paper intake forms with digital check-in. Patients receive a link before their visit, confirm their details on their phone and arrive with the paperwork done. On the first morning, three things happen.

First, a patient whose phone number changed last year never receives the link, because the system sent it to the number on file. She fills in a paper form at the desk: the identity problem in miniature, because the digital path assumed the organization’s contact details were current.

Second, a patient completes check-in, but the system creates a new chart instead of finding his existing one, because he typed “Bob” where the registration record says “Robert.” Now he has two records, and his allergy list lives in only one of them. The matching problem has been created at the front door.

Third, a daughter tries to check in her mother, who has dementia. The system asks the mother to confirm her identity, which she cannot do on a phone. The daughter has power of attorney papers in her bag, but the app has no place to show them. Staff fall back to paper, and the proxy problem has arrived.

No software bug caused any of these. Each is a policy or staffing question that the software exposed. The hospital that sees these patterns early, counts them and fixes the processes behind them will end up with cleaner records, which in turn makes app-based records requests work better. The hospital that treats them as isolated annoyances will carry the same errors into every new digital service it launches.

Where the cost and risk land

The money, risk and reputation in patient access lie outside the IT department’s compliance checklist.

Cost. Every failed digital request becomes a phone call, a portal reset or a paper form. The work does not disappear; it moves to the most expensive channel. A health system that celebrates its number of connections while its call center absorbs the failures has not saved anything.

Risk. A loose matching threshold or a weak credential policy turns a convenience feature into a breach generator. A single misdirected record delivered to the wrong phone is a privacy incident with notification duties, regulator attention and possible litigation attached.

Patients and equity. The people most likely to fail remote proofing, older patients and people with less stable documentation, are often the people with the most complex care and the greatest need to move records between providers. A program that serves the easiest patients and drops the rest will show up in complaints and in community trust.

Regulators and reputation. The pledge itself was voluntary, but information blocking rules and HIPAA rights were not. Public commitments also create public expectations: once an organization’s name appears on a list of pledgers, journalists and patients will ask what changed.

A front-office service with technology underneath

The work here is mostly unglamorous. A well-run health system treats app-based access as a front-office service with the technology underneath it, rather than a technology project with a front office attached. It has an in-person identity path at every registration desk, with trained staff and a target time for completing it. It publishes and regularly reviews its numbers for duplicates, overlays and correction time, and a named leader owns them. It has a written proxy policy covering parents, adult children, guardians and teen confidentiality, reviewed by counsel against state law, and a clear notice to patients at the moment of release explaining where HIPAA protections end.

The weaker systems report “live connections” to the board as the measure of success. They assume the EHR vendor’s defaults reflect their own risk appetite on matching thresholds and credential acceptance. And they launch app access without adding capacity to health information management and patient support, then discover the backlog months later.

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.

Completion rates, identity checks and proxy rules the board should see

• Of the patients who start an app-based records request, what share finish it, and how does that differ for patients over 65?
• If a patient fails remote identity checks, what exactly happens next, and how long does it take?
• Which outside identity credentials do we accept, at what assurance level, and what would we do if one were stolen?
• What are our duplicate and overlay rates today, how long does a correction take, and has health information management staffing kept pace with record requests?
• How does a parent, adult child or guardian prove authority in the app, and what do we do with a confidential adolescent visit?

With hindsight

CMS kept the framework and its lists of participants on its health technology ecosystem pages, and reports of progress against the pledges 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.

That gap is itself instructive. When the evidence of success comes from the people who made the promise, leaders inside those organizations need their own, sharper measures. A press release can say a network is live; only internal numbers can say whether a seventy-year-old patient with a name mismatch actually got her records.

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. Those are departments that rarely appear in technology announcements, and they are often the first to feel budget pressure. Yet they determine whether the app on the patient’s phone shows a complete, correct record or an error message.

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. For organizations that hold substance use disorder records, that meant the question of what flows into a patient’s app, and under which rules, became more pressing at the very moment pledges were due to show results.

Health systems that staffed in-person identity proofing, measured matching errors and defined proxy authority are better placed to say whether access actually improved. A technology promise in health care is only as good as the human process wrapped around it. Ask for the completion rate, ask who is staffing the front desk, and ask how a caregiver proves they are allowed to help. Those three questions will tell you more than any count of connected networks.