Guide

The app request: patient-directed APIs and your obligations

Summary

Yes, presumptively. A patient directing your EHR to send their electronic health information to an app of their choosing is exercising the same right of access that lets them request a paper copy — the information-blocking rule treats refusing or obstructing that request the same as blocking a portal login. You can decline only under one of eight narrow exceptions, documented case by case, never as a standing policy against apps generally.

By Gale Editorial · Updated 2026-07-27. Every figure cited to a dated source. How we write.

Why the default answer is yes

A patient asking your EHR to push their records to an app they've chosen is making a patient-directed API request, and the information-blocking rule treats interfering with it the same way it treats interfering with portal access or a records request — as blocking, unless one of eight narrow exceptions applies 1. The request doesn't have to come through a special form or a lawyer's letter; a patient authorizing an app through your patient portal's standard connection flow is enough.

This is the same access right that lets a patient get a paper copy of their chart, routed through a technical channel instead of a mailed envelope. Treating an app request as inherently more suspicious than a paper request, without a specific reason tied to that patient or that app, is the posture the rule exists to prevent.

What "patient-directed" actually means technically

The mechanism is a standardized API — most EHRs now expose a FHIR-based endpoint the patient's chosen app connects to after the patient logs in and authorizes it, pulling data the certified EHR is required to expose under the U.S. Core Data for Interoperability set 1. You aren't emailing a file or manually exporting anything; the app authenticates directly against your EHR's API using credentials the patient controls.

Your role in a typical request is limited to not obstructing the connection — disabling the API, requiring an extra manual approval step for every app, or telling patients a specific app "isn't supported" without a documented technical reason are the patterns that draw information-blocking scrutiny.

The HIPAA right sitting underneath the API rule

Separately from information blocking, HIPAA's right of access lets a patient direct a copy of their designated record set to a third party in writing, and an app the patient has authorized functions as that third party 2. The two rules point the same direction and reinforce each other: refusing under one is very likely to also fail the other.

The access right's one clean carve-out still applies here — true psychotherapy process notes kept separately from the rest of the record aren't part of what a patient can direct anywhere, app included. Everything else in the designated record set is in scope for both rules.

Where your obligation actually ends

Once data leaves your EHR into an app the patient chose, HIPAA generally stops following it — the app is typically not your business associate and isn't bound by the Privacy Rule unless it's acting on your behalf under a contract, which a patient's personal health app usually isn't. That surprises clinicians who assume they remain responsible for how the app subsequently handles the data; ordinarily they don't.

What does stay your responsibility is the security of your own system up to the point of transfer — proper authentication, a current risk analysis, and safeguards scaled to a solo practice, not the app's downstream privacy practices 3. A patient asking pointed questions about an app's own privacy policy is a fair conversation to have, but it isn't a HIPAA compliance question you're required to gatekeep.

Vetting what your EHR actually supports

Whether patient-directed API access works smoothly in practice depends heavily on what your EHR vendor actually built and what the contract lets you configure — some systems expose a full patient-facing API with minimal friction, others require workarounds that functionally slow the request down. This is squarely an EHR-selection and contract question, not just a policy one 4.

Before or when renewing an EHR contract, confirm the API meets current certification requirements, ask what happens when a new app type connects for the first time, and get in writing that the vendor won't charge the patient or you a special fee for a standard API connection — some historical vendor fee practices are exactly what drew information-blocking scrutiny industry-wide.

When you can actually say no

The eight exceptions to information blocking are your only legitimate ground for declining a specific app request, and the one most likely to be real in a solo practice is a documented security concern about a specific app — not apps as a category, and not a general discomfort with data leaving your system. The judgment has to be made and written down for that patient, that request, at that time.

A blanket rule of "we don't connect to apps we haven't heard of" doesn't survive scrutiny on its own; a specific, documented technical or security basis for a specific app might. If you're unsure which side of that line a given refusal falls on, treat it as connect-unless-you-can-document-why-not, the same posture that governs the immediate release of results and notes generally.

If a patient escalates a refused request

A patient whose app request you declined without a documented basis can file a complaint, and information-blocking complaints route through ONC's process while HIPAA-flavored access complaints go to OCR — either way, the record you kept of your reasoning at the time is what determines how the conversation goes from there. Responding to the ocr letter well starts with having made and saved that judgment in the first place, not reconstructing it after the fact.

A clean paper trail — what the patient asked for, what you checked about the app, why you connected or declined — takes minutes to keep and is the entire difference between a defensible decision and an information-blocking finding.

Common questions

No — requiring pre-approval of every app before connecting it functions as an access barrier and is the kind of blanket practice the information-blocking rule targets. You can flag a specific app for a specific, documented security reason, but a general pre-approval gate for all apps isn't a defensible policy on its own.

Generally no — a BAA is required when a vendor acts on your behalf, and a personal health app the patient independently authorized to pull their own data isn't functioning as your business associate. If your EHR vendor's API infrastructure itself handles the connection, that vendor's existing BAA with you already covers its own role.

You're only obligated to expose electronic health information through the certified API your EHR is required to support; a request genuinely outside that scope isn't an information-blocking issue in the same way. Document specifically what was requested and why it fell outside the API's scope rather than treating the whole request as declined.

The same API mechanics apply, but who is authorized to make the request differs — a minor's own authorization versus a parent's proxy access depends on your state's minor-consent rules and how your portal is configured for that patient, which is a separate question from the information-blocking obligation itself.

Run your practice on Gale

The software is free. Gale earns one flat 3.5% all-in per paid transaction — only on transactions that actually pay. No subscription, no setup fee, no network cut.

Start or manage a practice →

References

  1. 1.Office of the National Coordinator / ASTP (2026). Information Blocking. HealthIT.gov. link ✓That the information-blocking rule requires honoring patient-directed API requests to send USCDI data to an app absent a documented exception, and treats obstruction of that request the same as blocking portal or records access.
  2. 2.HHS Office for Civil Rights (2026). Individuals' Right under HIPAA to Access their Health Information. U.S. Department of Health and Human Services. linkThat HIPAA's right of access lets a patient direct their designated record set to a third party such as an authorized app, with psychotherapy notes excluded from that right.
  3. 3.HHS Office for Civil Rights (2026). Summary of the HIPAA Security Rule. U.S. Department of Health and Human Services. linkThat the Security Rule requires safeguards scaled to practice size anchored in a risk analysis, used here to define where a solo practice's own security duty ends at the point data transfers to a patient-authorized app.
  4. 4.Office of the National Coordinator (2016). EHR Contracts Untangled: Selecting Wisely, Negotiating Terms, and Understanding the Fine Print. HealthIT.gov (ONC). link ✓ONC's guidance on negotiating EHR contract terms, used here for confirming certified API access and fee terms before signing or renewing.

https://www.gale.care/for-providers/cde-patient-api-requests · 4 sources. Competitor details are cited to dated public sources and maintained as they change; figures are estimates, not commitments. Synthetic demonstration.

← Back to for providers

Findability, by specialty

How practices like yours get found in local search and AI answers — the honest playbook, per specialty.

SEO for private practices · SEO for AI search / answer engines (all verticals)