Who is accountable when patient access is shared across third-party apps?

The health system remains accountable for the identity assurance it accepts, even when access is delivered through partner applications or CMS-aligned networks. Shared workflows do not remove the need for clear ownership of proofing, policy enforcement, and revocation.

Why This Matters for Security Teams

When patient access is shared across third-party apps, accountability does not disappear into the integration layer. The health system still owns the identity assurance it accepts, the policies it authorises, and the revocation path when access must end. That matters because third-party workflows often obscure where proofing occurred, which app asserted the user, and who can actually revoke credentials when risk changes. The security problem is not just trust in a partner. It is trust in the full chain of identity, consent, and access decisions. The Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a useful reminder that external access paths are now normal, not exceptional. For identity-led healthcare ecosystems, the same governance discipline applies to app-mediated patient access and delegated tokens. OWASP also frames this risk in the OWASP Non-Human Identity Top 10, where token lifecycle, overprivilege, and weak ownership remain recurring failure points. In practice, many security teams encounter ambiguous accountability only after a third-party app continues to operate with valid access long after the intended trust relationship has changed.

How It Works in Practice

The practical answer is to separate three responsibilities: identity assurance, authorisation, and operational custody. The health system typically remains accountable for the assurance level attached to the patient or delegated user identity. The third-party app may carry the transaction, but it does not inherit ownership of the trust decision unless that responsibility is explicitly contractually and technically transferred.

In mature models, the health system should require:

• Clear proofing standards for any identity it accepts from a partner or intermediary.
• Policy decisions evaluated at request time, not just at onboarding.
• Short-lived tokens with scope-limited access and traceable subject claims.
• Revocation that works across all connected apps, not just the originating portal.
• Audit logs that identify who asserted the identity, who approved access, and who can terminate it.

This is where NHI governance and healthcare access governance overlap. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently. That operational gap matters because delegated access in healthcare behaves like a credential lifecycle problem as much as an interoperability problem. The 52 NHI Breaches Analysis illustrates how weak ownership and stale credentials create long-lived exposure after an initial trust decision. Current guidance suggests treating every third-party access path as a separately governable trust edge, with documented control owners and explicit revocation responsibilities. NIST’s AI Risk Management Framework is not healthcare-specific, but its govern and map functions reinforce the need for named accountability, traceability, and ongoing monitoring. These controls tend to break down when patient access is federated across multiple intermediaries because no single party can see or enforce the full token lifecycle.

Common Variations and Edge Cases

Tighter control often increases integration and governance overhead, requiring organisations to balance patient convenience against revocation certainty and auditability. That tradeoff becomes sharper when portals, payer networks, and app marketplaces all participate in the same access flow.

There is no universal standard for this yet, especially when a third-party app acts as both data recipient and user experience layer. Some ecosystems rely on contractual accountability, while others demand technical enforcement such as token introspection, app attestation, or scoped delegation. Best practice is evolving, but the direction is consistent: the system that accepts the identity claim should be able to prove why it trusted it, and the system that issues access should be able to remove it.

Edge cases include caregiver access, patient-directed sharing, and delegated access through consumer health apps. Those cases often create ambiguity over whether the user, the app vendor, or the health system is the operational owner. The safest posture is to define ownership by control plane, not by user interface. If a partner app can initiate access, the health system still needs a way to enforce policy changes centrally. For a broader view of how external exposure complicates identity boundaries, the Ultimate Guide to NHIs is useful background. In healthcare ecosystems, accountability usually breaks down when partners assume the originating platform will revoke access, while the originating platform assumes the partner already did.

Related resources from NHI Mgmt Group

• What do security teams get wrong about third-party access in CJIS environments?
• Who is accountable when third-party remote access is overused in public safety environments?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a user grants a risky third-party app access?