They should treat each API integration as a named identity with a documented purpose, narrow scope, and explicit revocation path. Interoperability should not mean broad standing access. The safest model is policy-based access that ties the request, the identity, the data type, and the approved use case together before PHI can move.
Why This Matters for Security Teams
FHIR access looks simple on paper because healthcare interoperability depends on broad data exchange, but that same openness can become a privilege sprawl problem if every integration is treated like a trusted internal app. The safer model is to treat each connector, service account, or API client as a distinct Non-Human Identity with purpose, scope, and revocation. That aligns with the governance discipline described in the Ultimate Guide to NHIs and with the access-control emphasis in the NIST Cybersecurity Framework 2.0.
In practice, the issue is not whether a partner can reach the API, but whether the organisation can prove that the request is expected, the identity is known, the data set is appropriate, and the use case is approved before any PHI moves. Healthcare teams often inherit legacy interfaces, shared credentials, and broad integration exceptions that were created to keep systems working during go-live pressure. That creates hidden exposure when the business later adds new partners, new payer workflows, or new patient-app features. In practice, many security teams encounter FHIR overexposure only after a partner integration has already been copied, expanded, or reused beyond its original clinical purpose.
How It Works in Practice
Govern FHIR access by binding authorisation to the specific integration rather than to a generic network zone or shared user. The organisation should define a named workload identity for each API consumer, issue credentials only for the approved task, and revoke them when the integration is retired or the vendor relationship changes. This is consistent with the NHI lifecycle approach in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the OWASP focus in the OWASP Non-Human Identity Top 10.
- Register every integration with a documented purpose, owner, data classes, and expected FHIR resources.
- Use narrow scopes for patient, observation, claim, or scheduling endpoints rather than granting broad system-wide access.
- Prefer short-lived tokens, mTLS, or workload identity over static api key that persist across environments.
- Evaluate policy at request time, using context such as tenant, resource type, patient relationship, and transaction purpose.
- Require explicit offboarding so access is revoked when the integration is no longer needed.
Where possible, apply the same control logic across internal apps, partner apps, and patient-facing channels so interoperability does not become a special case that bypasses policy. The governance model should support exchange without creating standing trust, which is the core Zero Trust principle for API security. The NHI evidence base also matters here: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which is exactly the pattern that weakens FHIR boundaries when teams overgrant access for convenience. These controls tend to break down when multiple EHR interfaces share the same credential set because no one can reliably distinguish which system asked for which record.
Common Variations and Edge Cases
Tighter FHIR controls often increase onboarding effort, so organisations must balance interoperability speed against auditability and patient-data minimisation. That tradeoff is real, especially when national exchanges, emergency care pathways, or legacy laboratory connectors cannot immediately support modern token and policy patterns. Current guidance suggests making exceptions explicit and temporary, not permanent.
One common edge case is delegated access through a third-party app marketplace, where the app may be legitimate but its downstream data use is not fully visible. Another is break-glass access, which may be necessary for care delivery but should be isolated, monitored, and time-bounded. A third is cross-tenant or cross-organisation routing, where the identity of the caller alone is not enough and the policy must also check the patient, purpose, and endpoint. For governance maturity, teams should also track what happens after revocation, since stale credentials and cached access paths can outlive the original approval. The Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce that long-lived access and weak offboarding are common failure points, even in regulated environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | FHIR access often fails through overprivileged non-human credentials and weak rotation. |
| NIST CSF 2.0 | PR.AC-4 | FHIR governance depends on controlled access to systems and data by authorised identities. |
| NIST AI RMF | AI RMF governance principles support accountable, policy-driven access decisions for automated integrations. |
Assign each FHIR integration a unique identity, enforce least privilege, and rotate or revoke secrets on a schedule.
