Category: Individual Rights

Patient Access API

Also known as: CMS Patient Access API, Patient Access API Mandate

Simply put

The Patient Access API is a secure online connection that certain federally regulated health insurers (payers) must operate so that their members can access their own health data through third-party apps of their choosing. It generally makes available information such as claims, encounter, and cost data, along with a defined set of clinical data. It is intended to help patients more easily retrieve and use their health information.

Formal definition

The Patient Access API is a FHIR-based application programming interface that certain CMS-regulated payers are required to implement to make specified data available to enrollees. Per the evidence, the data set generally includes claims and encounter information (including cost), clinical data such as laboratory results, and, in some payer implementations, membership, coverage, and prescription (RX) formulary information. This requirement arises from CMS interoperability rules and is distinct from HIPAA's Privacy Rule right of access; readers should verify the specific applicable payers, data elements, and compliance dates against current CMS regulatory text, as scope and effective dates are subject to change. Note that CMS interoperability requirements and HIPAA are separate authorities, and this definition addresses only the CMS Patient Access API mandate as described in the evidence.

Why it matters

The Patient Access API represents a significant shift in how patients interact with their own health information. Historically, enrollees seeking their claims, encounter, and clinical data often faced fragmented processes and manual requests. By requiring certain CMS-regulated payers to operate a standardized, FHIR-based interface, the mandate is intended to let members retrieve their data through third-party applications of their choosing, generally including claims and encounter information (with cost), clinical data such as laboratory results, and, in some implementations, membership, coverage, and prescription formulary information.

For compliance professionals, it is important to recognize that the Patient Access API arises from CMS interoperability rules and is a distinct authority from HIPAA. The HIPAA Privacy Rule's individual right of access is a separate requirement enforced by HHS OCR, whereas the Patient Access API mandate is a CMS requirement applicable to specified payers. Conflating the two can lead to gaps in compliance planning, because each imposes its own scope, obligations, and timelines. Organizations subject to both should map their responsibilities under each authority separately rather than assuming one satisfies the other.

Because the applicable payers, data elements, and compliance dates for the CMS interoperability rules are subject to change, organizations should verify current requirements against the applicable CMS regulatory text rather than relying on general summaries. Enabling patient access through third-party apps also raises downstream privacy and security considerations, since data flowing to consumer-facing applications may move outside the direct control of the payer; readers should evaluate these considerations in light of current CMS guidance and any applicable state law.

Who it's relevant to

CMS-Regulated Payers

Certain federally regulated health insurers subject to CMS interoperability rules must implement and maintain the Patient Access API. Compliance and IT teams at these organizations should confirm which of their lines of business are in scope, which data elements they are required to expose, and the applicable compliance dates against current CMS regulatory text, as these are subject to change.

Privacy and Compliance Officers

Because the Patient Access API arises from CMS interoperability rules and is distinct from HIPAA's Privacy Rule right of access, compliance professionals should map obligations under each authority separately. Meeting the CMS mandate does not by itself satisfy HIPAA obligations, and vice versa; each should be evaluated on its own terms and against current guidance.

Security and IT Architecture Teams

Teams responsible for implementing the FHIR-based interface should address the security of member authentication, authorization, and data exchange with third-party applications. Because data may flow to consumer-facing apps that fall outside the payer's direct control, teams should evaluate the associated privacy and security considerations in light of current CMS guidance and any applicable additional requirements.

Enrollees and Member Support Functions

The API is intended to help members more easily retrieve and use their own health information through apps they choose. Member-facing support functions may need to provide guidance on connecting applications and on the types of data made available, which can vary by payer implementation.

Inside Patient Access API

Standardized API Requirement

The Patient Access API generally refers to an application programming interface that certain payers are required to make available so that individuals can access their own health information (such as claims, encounter, and certain clinical data) through third-party applications of their choice. This requirement stems primarily from CMS interoperability rules rather than from the HIPAA rules themselves; readers should verify the specific scope and applicability against the current CMS regulatory text.

FHIR-Based Technical Standard

These APIs are typically built on the HL7 FHIR standard to enable consistent, machine-readable exchange of health data between the payer's systems and consumer-facing applications. The exact FHIR version and implementation guides applicable should be confirmed against current CMS and ONC guidance.

Relationship to HIPAA Right of Access

The Patient Access API supports, but is distinct from, the HIPAA Privacy Rule's individual right of access to PHI. The Privacy Rule establishes an individual's right to access their PHI held by covered entities; the API is a technical mechanism that can facilitate such access for covered payers, but the two arise from different regulatory sources and have different scopes.

Third-Party Application Access

Individuals generally direct their data to an app they select. Once data is transmitted to a consumer-chosen third-party app at the individual's request, that app is often not a business associate of the payer and may fall outside HIPAA's direct coverage, potentially subject instead to other consumer protection authorities. The specific coverage of any given app should be evaluated case by case.

Applicability by Entity Type

The Patient Access API requirement applies to specific categories of payers identified in the CMS rules (for example, certain Medicare Advantage, Medicaid, CHIP, and qualified health plan issuers). It does not apply universally to all covered entities or business associates under HIPAA. Readers should confirm which entity types are in scope under current regulation.

Common questions

Answers to the questions practitioners most commonly ask about Patient Access API.

Is the Patient Access API a HIPAA requirement?

Not exactly. The Patient Access API requirement generally stems from CMS interoperability rulemaking that applies to certain payers (such as Medicare Advantage organizations, Medicaid and CHIP programs, and qualified health plan issuers on federally facilitated exchanges), rather than from the HIPAA rules themselves. HIPAA's Privacy Rule separately grants individuals a right of access to their protected health information, but that right and the API mandate arise under different authorities. Because scope, applicability, and effective dates vary and are adjusted over time, readers should confirm the specific obligations against the current CMS regulation and applicable guidance.

Does implementing a Patient Access API mean an organization is HIPAA compliant?

No. Standing up a Patient Access API addresses a specific interoperability and access requirement but does not by itself establish HIPAA compliance. An organization subject to HIPAA must still meet the broader obligations of the Privacy Rule, the Security Rule, and the Breach Notification Rule as applicable, including safeguards over electronic protected health information exchanged through the API. Deploying the API is one component among many and should not be treated as a substitute for a complete compliance program.

What safeguards should apply to ePHI exchanged through a Patient Access API?

For entities subject to the HIPAA Security Rule, electronic protected health information moving through an API generally remains within the scope of the Security Rule's administrative, physical, and technical safeguards. Technical safeguards such as access controls and transmission security are commonly relevant, and each addressable implementation specification should be evaluated rather than assumed optional. Organizations should map API data flows to their risk analysis and confirm safeguard decisions against the current regulatory text.

How should organizations handle third-party applications that patients authorize to receive their data through the API?

When a patient directs their data to a third-party application of their choosing, that application is often not acting as a business associate of the disclosing entity and may fall outside the disclosing entity's direct HIPAA obligations. Because the relationship and resulting obligations depend on defined roles, organizations should carefully assess whether a business associate relationship exists and document authentication and authorization processes. Where no such relationship exists, the disclosing entity generally is not responsible for the downstream app's practices, though this should be verified against current guidance.

How does a Patient Access API relate to the HIPAA right of access?

The two are related but distinct. The HIPAA Privacy Rule's individual right of access covers protected health information in the entity's designated record set across forms, while a Patient Access API is a specific electronic mechanism, typically required of certain payers under CMS rules, for making designated data available in a standardized way. An organization may need to satisfy both the underlying access right and any applicable API mandate. Readers should confirm the precise data elements and timelines against the current regulation.

Should breach notification processes account for data disclosed through a Patient Access API?

For entities subject to HIPAA, disclosures of electronic protected health information through an API remain subject to the Breach Notification Rule where a breach of unsecured PHI occurs and the entity is the responsible party. Where a patient has directed data to a third-party app that is not a business associate, subsequent handling by that app may fall outside the disclosing entity's notification obligations. Because these determinations depend on the specific relationships and facts, organizations should incorporate API data flows into their breach assessment procedures and verify obligations against current HHS OCR guidance.

Common misconceptions

The Patient Access API is a HIPAA Security Rule or Privacy Rule requirement.

The API requirement generally originates from CMS interoperability regulations, not from the HIPAA rules. While it interacts with the HIPAA Privacy Rule's individual right of access and while HIPAA's Security Rule safeguards for ePHI remain relevant to a covered payer's systems, the API mandate itself is a separate CMS obligation. Applicability and details should be verified against current CMS guidance.

Once data flows through the API to a consumer app, HIPAA continues to govern that app.

When an individual directs their data to a third-party app of their own choosing, that app is frequently not a business associate of the payer and may not be directly regulated by HIPAA. Obligations under HIPAA attach through defined relationships such as business associate agreements; a consumer-selected app typically does not have such a relationship. Other consumer protection frameworks may apply instead, and each arrangement should be assessed individually.

Implementing a Patient Access API establishes HIPAA compliance.

Offering the API addresses a specific CMS interoperability obligation and can support the HIPAA right of access, but it does not by itself establish overall HIPAA compliance. A covered payer must still meet applicable Privacy Rule, Security Rule, and Breach Notification Rule obligations independently. Similarly, using a particular framework or certification does not, by itself, demonstrate HIPAA compliance.

Best practices

Confirm whether your organization falls within the specific payer categories subject to the CMS Patient Access API requirement, and verify the applicable scope, standards, and timelines against the current CMS regulatory text rather than relying on general summaries.

Maintain HIPAA Security Rule safeguards (administrative, physical, and technical) for the ePHI within the systems supporting the API, treating addressable implementation specifications as requiring evaluation and documentation rather than as optional.

Document the point at which an individual authorizes transmission to a third-party app, and assess on a case-by-case basis whether any given app is a business associate or falls outside HIPAA's direct coverage.

Provide clear, accessible information to individuals about how their data leaves the organization's HIPAA-covered environment when sent to a consumer-selected app, and note that other consumer protection authorities may apply to that app.

Coordinate the API's role with your HIPAA Privacy Rule right-of-access procedures so that the two mechanisms are consistent, without treating the API as a replacement for required access processes.

Verify FHIR versions, implementation guides, and any referenced figures or deadlines against current CMS and ONC guidance, and reassess as regulations and standards are updated over time.