Patient-directed AI: where HIPAA ends, a provider’s duties change shape
In January 2026, two major AI companies invited patients to connect their medical records. Nothing in the law changed, but providers’ duties changed shape: what they cannot block, what they still control, and what they owe patients who arrive with an AI’s answer.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
Two-minute summaryThe dek and the first sentence of each section, quoted from the article
In January 2026, two major AI companies invited patients to connect their medical records. Nothing in the law changed, but providers’ duties changed shape: what they cannot block, what they still control, and what they owe patients who arrive with an AI’s answer.
- The week Two launches in early January 2026 brought consumer AI to the medical record.
- From portal to app in five steps Most hospitals and physician practices keep their records in an electronic health record system, the digital chart.
- What providers could not do A provider cannot refuse or slow a patient’s request to send records to a consumer app because it doubts the app’s privacy practices or dislikes its business model.
- What providers still controlled Providers controlled the pathway.
- What providers owed patients The third part is explanation.
- Two kinds of AI, one patient The boundary between a provider’s AI and a patient’s AI is easiest to see in a single story.
- The cost of getting the balance wrong The issue reaches beyond IT and the patient portal team, and its consequences go further still.
- Three parts, three owners These three parts need separate owners.
- Where the provider’s exposure sits Each answer needs a named owner, and the privacy notice behind them should be factual and identical for every app.
- With hindsight The January launches accelerated a trend rather than starting one.
The week
Two launches in early January 2026 brought consumer AI to the medical record. On January 7, OpenAI introduced ChatGPT Health, a separate space where U.S. users could connect medical records, through the health data company b.well, and wellness apps. OpenAI said health conversations would not be used to train its foundation models, the large underlying AI systems on which its products are built, and that the product was meant to support, not replace, medical care. Access began with a waitlist.
On January 11, at the start of the J.P. Morgan Healthcare Conference, one of the industry’s biggest annual gatherings of health executives and investors, Anthropic announced Claude for Healthcare. It combined tools for providers and payers, meaning hospitals, physician groups and health insurers, with an option for some U.S. subscribers to connect their own health records.
Consider a patient on a Sunday evening, looking at a new lab result in her hospital’s patient portal. One value is flagged in red, and the clinic is closed. A few months earlier she might have searched the internet and worried. Now she could ask an AI assistant that could read her actual medical record.
Neither launch created a new legal pathway. Patients already had a right to their records under federal law. And federal rules already required providers to make records available to the apps patients choose, generally through standardized technical connections designed for exactly that purpose.
What was new was who was asking. Large consumer brands were now inviting patients to plug in their medical histories. For hospitals and physician practices, a long-standing legal arrangement suddenly had a very large and very visible audience, and the questions from patients, staff and boards were about to follow: could the hospital stop a connection it did not trust, who protected the data once it left, and what should a nurse say when a patient called with an AI’s answer?
Coverage focused on the AI. For health systems, the more important facts were older. Under HIPAA, patients have a right of access to their health information. Under the 21st Century Cures Act, providers and their health IT developers generally may not interfere with that access, including through standardized APIs to third-party apps. Once a patient sends records to an app that is neither a covered entity nor a business associate, HIPAA stops applying to that copy.
All of that predated January. What changed was scale and salience. Large consumer brands were now asking patients to connect records, and patients were bringing the answers back to their clinicians. The provider’s position splits into three parts: what it could not do, what it still controlled, and what it owed patients. The plumbing and the law come first.
From portal to app in five steps
Most hospitals and physician practices keep their records in an electronic health record system, the digital chart. Patients typically see a slice of it through a patient portal, the website or app where they read results, message their doctor and book appointments.
For years, federal policy has pushed providers to let patients take that information elsewhere. The mechanism is an API, an application programming interface. An API is a standardized doorway that lets one piece of software ask another for information in an agreed format. It works much like a bank’s connection to a budgeting app: the patient logs in, approves the connection, and the app can then fetch the data it was given permission to see, without anyone emailing files back and forth.
In health care, the standard format is called FHIR (pronounced “fire”), a common language for describing things like medications, diagnoses and lab results so that different systems can understand each other. When a patient connects an app, the usual sequence is:
- The patient chooses to connect, inside the app.
- The app sends the patient to the provider’s login page, where the patient proves who they are.
- The provider shows an authorization screen describing what the app will receive.
- The patient approves, and the provider’s system issues an access token, a digital pass that lets the app fetch data for a set period.
- The app retrieves the data and keeps its own copy.
Companies like b.well sit in the middle of this chain for many consumer products, handling the connections to many different providers so that each app does not have to.
Now the legal terms. A covered entity under HIPAA is a health care provider, health plan or clearinghouse. A business associate is a company that handles health information on a covered entity’s behalf, under a contract called a business associate agreement. HIPAA binds both. A consumer app that a patient chooses for themselves is usually neither, which is why HIPAA stops at the point the patient sends a copy to it.
Information blocking is the term in the 21st Century Cures Act for practices that interfere with access to, exchange of, or use of electronic health information. Regulators can act against providers and health IT developers who engage in it, subject to defined exceptions. The rules are administered with the help of ONC, the federal office that oversees health information technology policy.
What providers could not do
A provider cannot refuse or slow a patient’s request to send records to a consumer app because it doubts the app’s privacy practices or dislikes its business model. The information blocking rules contain exceptions, including for privacy and security, but they are narrow and conditional. A practice that adds friction outside those exceptions, such as extra verification steps only for certain apps or a warning screen designed to discourage, risks an information blocking complaint. Organizations should check with counsel before restricting any app.
This can feel counterintuitive to clinicians and compliance teams whose instinct is to protect patient data. But the law’s premise is that the record belongs, in an important sense, to the patient, and that the patient, not the provider, decides where it goes.
Providers also cannot govern what the app does next. Retention, secondary use, sharing and security of the copy are governed by the company’s own terms, by state consumer health and privacy laws, and by the Federal Trade Commission. The FTC polices unfair or deceptive practices and enforces its Health Breach Notification Rule, which it updated in 2024 to make clear it reaches health apps. Those protections differ from HIPAA.
Patients rarely know the difference, and many assume the hospital’s protections travel with the data. Once the copy leaves, it lives under a different set of rules, and the hospital has no contract with the app that would let it enforce anything.
What providers still controlled
Providers controlled the pathway. They decide how identity is proofed at the portal, meaning how the patient proves who they are, how app authorization screens look, how long access tokens last, and how patients see and revoke connected apps. A screen that names the app, lists the data categories it will receive and shows how to disconnect is permitted. It is also the strongest protection the provider can offer.
Security teams should treat third-party app connections as an access channel, in the same category as staff logins or partner connections. That means logging which apps hold active authorizations, watching for unusual volumes, and making revocation as easy as consent. If a patient can connect an app in three taps, she should be able to disconnect it in three taps too. A patient who changes her mind, or loses her phone, should not have to call the help desk to cut off an app’s access.
Providers also controlled what they sent. A consumer AI tool will summarize whatever is in the record. A problem list that was never reconciled, a medication list with drugs stopped years ago, or a note full of shorthand becomes, in a chatbot’s answer, a confident statement about the patient. Record hygiene was always a safety issue for clinicians reading the chart. It is now also a patient experience issue, because patients read summaries generated from the same data.
The blood thinner he no longer takes
Take a patient at a family practice whose medication list still shows a blood thinner he stopped taking years ago, because nobody removed it after a specialist changed his treatment. His problem list still shows an old diagnosis that was later ruled out. He connects his record to a consumer AI assistant and asks for a summary of his health. The assistant, reading the record faithfully, tells him he is on a blood thinner and has a condition he does not have. He calls the practice, alarmed and a little angry. The AI did nothing wrong in a technical sense; it repeated the record. The fix lies in the chart.
The practical response is to prioritize reconciliation of problem and medication lists for patients who use portals and APIs heavily, and to fix the templates that generate the most ambiguous text. Reconciliation simply means reviewing the lists with the patient and correcting them, something clinicians already aim to do but often cannot keep up with. Fixing the templates matters because a single confusing template can produce thousands of confusing notes.
Finally, providers controlled their own AI use. Several of the same vendors sell enterprise tools to health systems under business associate agreements, where HIPAA does apply. A patient may not easily tell a tool chosen by the care team from one they chose themselves. Health systems that use AI in messaging, documentation or triage should say where and how, so the boundary is visible.
That means a short public statement of which functions use AI, which vendors provide it under business associate agreements, and how a patient can reach a person instead. It also means making sure the patient-facing disclosure matches the contracts. If a vendor’s enterprise terms allow use of data for product improvement, the statement should not imply otherwise. Mismatches of that kind are what turn a patient question into a regulatory complaint.
What providers owed patients
The third part is explanation. Patients who ask a chatbot about a lab result and then call the clinic, worried, are now part of the workload. Front-desk staff, nurses and portal message teams need one consistent position:
- The provider supports the patient’s right to use these tools.
- The tool is not part of the care team, and its answers are not reviewed by the patient’s clinicians.
- Questions about results should come back to the care team, and here is how to ask them.
That position respects the patient’s choice, avoids endorsing the app, and steers clinical questions to the people responsible for care. Without a shared script, one nurse may dismiss the AI’s answer, another may engage with it at length, and a third may tell the patient not to use such tools at all, which could itself raise information blocking concerns.
Patients also deserve a plain account of the privacy difference. Data in the portal is protected under HIPAA. A copy sent to a consumer app is governed by that company’s terms and other laws. ONC has said that educating patients about the privacy and security risks of apps is not information blocking, provided the information is accurate, unbiased and applied consistently. That gives providers room to inform without discouraging. The test is tone: the same factual notice for every app, not a warning reserved for products the organization dislikes.
Two kinds of AI, one patient
The boundary between a provider’s AI and a patient’s AI is easiest to see in a single story.
Take a health system that uses an AI tool to draft replies to patient portal messages. The tool is provided by a vendor under a business associate agreement, so HIPAA applies to it, and a nurse reviews every draft before it is sent. The same system also has patients who, on their own initiative, have connected their records to a consumer AI assistant.
One of those patients asks her consumer assistant what a result means, gets an answer, and then sends the health system a portal message asking whether the assistant was right. The system’s drafting tool produces a suggested reply, which a nurse edits and sends. In the space of an hour, the patient has dealt with two AI systems, operating under two different legal regimes, with two different relationships to her care team. From where she sits, both are simply “the AI.”
The public statement earns its keep here. If the health system has explained, in everyday language, that it uses AI to help draft messages, that clinicians review those drafts, which vendor provides the tool and under what protections, the patient can make sense of what happened. If it has said nothing, she may reasonably assume the consumer assistant was part of her care, or that the hospital’s reply was written entirely by a machine. Either misunderstanding can turn into a complaint.
The story also shows why the staff script matters. The nurse answering the message should neither ridicule the consumer assistant’s answer nor adopt it. She should answer the clinical question on its merits, from the record, and gently note that the assistant is not part of the care team. That is easy to do when it is the agreed position, and hard to do consistently when every nurse is improvising.
The cost of getting the balance wrong
The issue reaches beyond IT and the patient portal team, and its consequences go further still.
Regulatory risk runs in two directions. Intervene too much, and the organization risks information blocking complaints. Say too little, and patients may assume the provider endorses or protects what the app does with their data. The safe ground is narrow, and it is defined by consistency and accuracy.
Workload is real. Every confused patient who calls about an AI summary takes staff time. A consistent script and cleaner records reduce both the number of calls and the time each one takes.
Safety and reputation are linked to record quality. An inaccurate chart was always a clinical risk. Now it is also a visible one, because patients are reading machine-generated summaries of it. A patient told by an AI that he is on a drug he stopped years ago is unlikely to blame the AI.
Trust in the provider’s own AI depends on transparency. As health systems adopt AI for messaging, documentation and triage, patients will ask how it is used. A clear, accurate statement now is far better than an awkward explanation after a news story.
Three parts, three owners
These three parts need separate owners. Legal and compliance should own the limits on intervention. Portal, identity and security teams should own the pathway and record quality programs. Patient experience and nursing leaders should own the scripts. Left unassigned, each tends to fall between groups, and the first sign of the gap is a complaint.
The well-prepared organization has a clear authorization screen and an easy revocation path; a log of active app connections monitored like any other access channel; a reconciliation push aimed at heavy portal users; one factual, app-neutral privacy notice; one staff script; and a public statement of the organization’s own AI use that matches its contracts.
The usual failures are adding informal friction for apps the organization distrusts; writing warnings that read as discouragement; letting each department improvise its own answer to patients; assuming HIPAA protects copies held by consumer apps; and describing the organization’s own AI use in reassuring language its vendor contracts do not support.
Where the provider’s exposure sits
- If a patient asked to connect her record to a consumer AI app today, is there anything in our process that would slow her down, and has counsel confirmed it fits an exception?
- What does our app authorization screen show, and could a patient find and revoke a connection easily?
- How current are problem and medication lists for our heaviest portal users?
- What do our front-desk staff, nurses and portal teams say when a patient brings an AI interpretation of a result?
- Where do we use AI ourselves, under which agreements, and does our public description match the contract terms?
Each answer needs a named owner, and the privacy notice behind them should be factual and identical for every app.
With hindsight
The January launches accelerated a trend rather than starting one. Through 2026, patients arriving with an AI interpretation of their results became an ordinary enough experience that a standard staff response was worth having. We have no reliable figures on how many patients connected records, and we would be cautious about any claim of precision.
The legal picture did not change in substance. HIPAA still stopped at the point of patient-directed disclosure. The information blocking rules still limited how far providers could intervene. The FTC and state laws remained the main protections for the copy an app held. For patients, that meant the protections around their data depended on where the copy sat, a distinction patients rarely see.
What health systems controlled was the preparation around that pathway: clear authorization and revocation screens, clean problem and medication lists, consistent staff scripts and a factual privacy notice. These required no new law or new technology. They required ownership and attention, and the organizations that assigned clear owners early tended to find the work manageable rather than overwhelming.
Organizations that discouraged connections informally took on information blocking risk. Those that said nothing left patients to assume the provider stood behind whatever the app said. Both are uncomfortable places to be, and both are avoidable with modest, deliberate effort.
Consumer technology can change the experience of care without changing a single rule. When it does, the organization’s duties stay legally the same but practically shift: less about guarding the door, which the law has largely opened, and more about the quality of what passes through it and the clarity of what patients are told. The hospitals and practices that adapted best treated the record itself as something patients now read through new eyes, and kept it accurate accordingly.
Spotted an error? Tell us and we will check it and correct the article where needed.