HIPAA Vendor Risk Management for Health Data Interoperability APIs

Health data interoperability APIs connect covered entities, vendors, health plans, providers, and patient-selected apps. Managing the risks requires more than checking whether an API uses a familiar standard: you need to understand who handles protected health information (PHI), what each connection is authorized to do, and how security risks are assessed and addressed.

When does an interoperability API vendor qualify as a business associate?

An API vendor generally qualifies as a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate to perform a service or function. The role depends on what the vendor does and whose purposes it serves—not simply on whether it describes itself as an API provider or says it cannot read encrypted data.

For example, a vendor that hosts an API, processes PHI, stores it, or provides support that involves access to it may be a business associate. HHS explains that a cloud service provider can qualify even when it maintains only encrypted ePHI and does not have the decryption key. The narrow conduit exception is for transmission-only services with only temporary storage incidental to transmission. See HHS guidance on HIPAA and cloud computing.

When the vendor is a business associate, the covered entity generally needs a written business associate agreement (BAA) that addresses permitted uses and disclosures, safeguards, incident reporting, subcontractors, and other required terms. A vendor that is itself a business associate must also arrange appropriate written assurances with relevant subcontractors. See HHS business associate guidance and 45 C.F.R. § 164.504(e).

By contrast, an app that a patient independently selects to receive the patient’s information does not become a business associate solely by facilitating that patient-directed access. The relationship can differ if the app is provided by or on behalf of the covered entity, or handles PHI on the entity’s behalf. See HHS guidance on apps and business associate agreements.

What should a health data API vendor security assessment cover?

Start with the required HIPAA Security Rule risk analysis: identify the ePHI the organization creates, receives, maintains, or transmits; where it flows; and the reasonably anticipated risks and vulnerabilities to its confidentiality, integrity, and availability. The Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment and implement measures to reduce identified risks to a reasonable and appropriate level. See 45 C.F.R. § 164.308(a)(1)(ii)(A)–(B) and HHS guidance on risk analysis.

For an API vendor, assess the service in its actual operating environment, not just its written policies. A practical review can cover:

• Data and architecture: PHI types, data flows, API endpoints, storage and retention, environments, encryption, and connections to other systems.
• Identity and access: requester authentication, authorization scopes, privileged access, service accounts, credential handling, and access review.
• API defenses: validation of requests, rate limiting, abuse detection, secure configuration, vulnerability management, and testing for common API weaknesses.
• Operations and response: logging, monitoring, incident escalation, recovery, backup, and support procedures.
• Third parties: subcontractors, cloud providers, their roles in handling ePHI, and the agreements and safeguards that apply to them.
• Evidence and remediation: relevant test results, policies, control evidence, identified gaps, accountable owners, and remediation dates.

Document the reasoning, evidence, and follow-up actions so the assessment is an objective and verifiable security analysis, rather than a vendor questionnaire alone. The HIPAA Security Rule does not prescribe a single assessment template; the organization should use its documented risk analysis and risk-management process to determine what is appropriate for its systems and circumstances.

How do OAuth 2.0 safeguards limit API access risks?

OAuth 2.0 authorization code flow can let an individual authenticate with the health plan or provider’s authorization service rather than sharing account credentials with an app. The authorization service issues tokens that let the app access only the data and actions permitted by the granted authorization.

HHS recommends using the OAuth 2.0 framework specified by the SMART App Authorization Guide and implementing the authorization-code workflow. Its API guidance explains that this approach supports direct authentication with the authorization server and can reduce exposure of credentials and tokens to intermediaries. See HHS privacy and security considerations for healthcare APIs.

Configure authorization scopes to match the approved access, protect tokens in storage and transit, and avoid giving an app broader access than it needs. Set an appropriate access token expiration as part of the security design, and consider how token revocation and refresh-token controls work. HIPAA does not set one universal access-token lifetime; the organization should make and document choices based on its risk analysis and applicable API requirements.

OAuth helps establish delegated access, but it does not by itself prove that a requester is entitled to the PHI, secure the API implementation, or satisfy all HIPAA obligations. Pair it with requester and application authentication, appropriate authorization, monitoring, and documented security procedures.

How should organizations assess risks from third-party API connections?

Map the full connection chain: the covered entity, API platform, app or provider organization, hosting provider, and any other subcontractors that create, receive, maintain, or transmit ePHI. Record what information each party handles, why it handles it, and what systems or services could affect the connection’s security.

For each connection, review the authorization model, identity checks, data scope, encryption, token handling, logging, incident coordination, and termination or revocation process. Confirm that applicable BAA and subcontractor terms match the real data flows and service responsibilities. A contract is important, but it does not replace the covered entity’s own risk analysis or the business associate’s applicable Security Rule duties.

Use a repeatable, risk-based process to approve connections and revisit them when the app, vendor, API, data use, or threat environment changes. If an organization identifies a risk, document its decision, mitigation, responsible owner, and follow-up. For patient-selected apps, distinguish the security of the API connection from concerns about how the app may use information after receiving it; those concerns do not automatically permit denial of a patient’s access request.

Which interoperability API requirements apply to health plans?

Requirements depend on the type of plan and the particular API. CMS’s rules apply to specified payers, including Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. The 2020 CMS rule established Patient Access API requirements; the 2024 CMS Interoperability and Prior Authorization final rule added requirements for certain APIs and expanded some existing ones. See CMS’s API standards and implementation-guides overview.

Depending on the payer and provision, the requirements cover a Patient Access API and additional Provider Access, Payer-to-Payer, and Prior Authorization APIs. They also specify applicable data, technical standards, and implementation timelines. For example, CMS states that the 2024 final rule’s API development and enhancement requirements generally have compliance dates beginning January 1, 2027, while certain operational provisions begin earlier. Check the applicable payer-specific regulation and compliance date rather than assuming every plan has identical duties. See CMS’s fact sheet for the 2024 final rule.

For the Patient Access API, CMS requires affected payers to make specified claims, encounter, and clinical information available through a FHIR-based API that conforms to applicable technical, content, and vocabulary standards. CMS also explains that the API must allow an enrollee’s chosen third-party app to access the required data. These are interoperability technical standards and API obligations in addition to, not a substitute for, applicable HIPAA privacy and security requirements. See CMS’s Patient Access API FAQs.

How can organizations verify requester identity and authority?

HIPAA’s Privacy Rule requires a covered entity to verify the identity and authority of a person requesting PHI if those facts are not already known, and to obtain documentation or representations when a disclosure provision requires them. HIPAA generally does not mandate a single technical verification method, so organizations should use reasonable procedures suited to the request and the information involved. See HHS guidance on electronic identity and authority verification and 45 C.F.R. § 164.514(h).

In API workflows, distinguish the person or organization requesting access from the software client making a technical request. Use API requester authentication to establish the claimed identity of the app, provider, plan, or other requester; then verify its authority and the purpose and scope of the request. For patient-directed access, the OAuth authorization flow can authenticate the individual and communicate the authorization granted to the app. For provider or organization-to-organization exchanges, use an appropriate method to authenticate the organization and validate the requester’s role or authority under the applicable workflow.

Keep records of relevant identity checks, authorization decisions, and access events. Authentication answers who is connecting; authorization and verification address whether that person or entity may receive the requested information.

When can an organization deny or discontinue API access?

For a patient’s preferred app connecting to a Patient Access API subject to the CMS rule, a payer may deny or discontinue the connection if it reasonably determines that the app presents an unacceptable risk to the security of PHI on the payer’s systems. The determination must be supported by an appropriate security analysis and objective and verifiable security analysis criteria applied fairly and consistently across apps and developers. Examples discussed in the final rule include inadequate authentication or authorization controls, poor encryption, or reverse engineering. See the CMS Interoperability and Patient Access final rule.

A payer should document the specific security concern, evidence, criteria applied, and decision. It should not treat disagreement with an app’s business model or general concern about how the app may use information after receiving it as a substitute for the required security determination. HHS also explains that a covered entity may not deny an individual’s right of access solely because the individual directs the information to an app with which the entity has privacy or security concerns. See HHS guidance on app-related concerns and access requests.

For other API connections, apply the rules and contracts governing that specific exchange, including HIPAA requirements to verify identity and authority and applicable security obligations. A security concern should prompt a documented, legally grounded decision—not an automatic assumption that all app access can be blocked.

FAQs

Does an API vendor need a business associate agreement to handle protected health information?

Generally, yes, when the vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity or business associate as part of its service. A vendor that merely provides a patient-selected app for the patient’s independent use does not necessarily have that relationship. Determine the parties’ actual roles and data flows, then document the relationship and required safeguards in the appropriate written agreement.

Does an app become a business associate when a patient authorizes access to their own data?

Not solely because the patient authorizes the app to receive the patient’s data. HHS explains that facilitating access at the individual’s request alone does not create a business associate relationship. The answer may differ if the app is provided by or on behalf of a covered entity or performs services involving PHI on that entity’s behalf.

Can a covered entity deny an app access to an interoperability API for security reasons?

For a patient-selected app under the CMS Patient Access API requirements, a payer may deny or discontinue access when it reasonably determines, using an appropriate security analysis and objective, verifiable criteria applied fairly and consistently, that the connection presents an unacceptable risk to PHI on the payer’s systems. General concern about the app’s data practices alone is not the required security basis for denying the patient’s access request.

Who is responsible for HIPAA compliance when a health plan implements an interoperability API?

The health plan remains responsible for meeting the obligations that apply to it as a covered entity, including applicable HIPAA requirements and its API obligations. A vendor that qualifies as a business associate also has its own applicable HIPAA responsibilities and must meet the terms of its BAA. The plan cannot transfer its own regulatory responsibilities simply by hiring a vendor.

Effective vendor risk management combines a documented Security Rule risk analysis, clear business associate arrangements where required, carefully scoped and authenticated API access, and consistent review of third-party connections. For health plans, those safeguards must be coordinated with the specific interoperability rules and standards that apply to each API.