SMART on FHIR interoperability depends on stronger IAM controls

At a glance

What this is: This is an analysis of how SMART on FHIR interoperability depends on IAM to control access to healthcare data across apps, vendors, and organizations.

Why it matters: It matters because healthcare interoperability increases the number of identities, permissions, and trust relationships that IAM teams must govern without weakening privacy or service availability.

👉 Read the source analysis on SMART on FHIR and healthcare IAM

Context

Interoperability in healthcare only works when identity and access management can decide who or what is allowed to see patient data, call APIs, and move information between systems. Without that control layer, connected systems increase exposure instead of improving care, because every new app, integration, or vendor relationship expands the trust surface.

SMART on FHIR combines the SMART standard and HL7 FHIR into a common approach for app access and data exchange, but the governance problem remains the same: access must be authorized, auditable, and limited to the minimum necessary scope. For IAM leaders, this is a healthcare identity problem as much as an interoperability problem, because the policy model must keep pace with the data-sharing model.

Key questions

Q: How should healthcare organisations govern SMART on FHIR access?

A: They should govern SMART on FHIR access by treating each app, token, and service account as a controlled identity with an owner, a purpose, a minimum scope, and a revocation path. Interoperability should never bypass least privilege. The operating goal is to make every API call traceable to a justified business need.

Q: Why does interoperability increase IAM risk in healthcare?

A: Interoperability increases IAM risk because it multiplies the number of trust relationships and non-human identities that can reach sensitive data. Each new app integration can widen the blast radius if scope, monitoring, and offboarding are weak. The problem is not sharing data itself, but losing control over who can keep using it.

Q: What is the difference between authentication and authorization in SMART on FHIR?

A: Authentication confirms who or what is calling the system. Authorization decides what that caller can do with healthcare data once access has been established. In SMART on FHIR environments, authorization is the more critical control for limiting patient data exposure because interoperable apps often authenticate successfully even when their requested scope is too broad.

Q: When should teams review third-party healthcare app access?

A: Teams should review third-party healthcare app access whenever the business purpose changes, the vendor relationship ends, the app scope expands, or audit logs show unusual usage. Regular review is also necessary because healthcare integrations often outlive the original approval. If access is still valid but no longer needed, it should be removed immediately.

Technical breakdown

How SMART on FHIR uses identity to mediate access

SMART on FHIR is an application authorization pattern built on FHIR APIs and OAuth-based access flows, so the identity layer is not separate from interoperability. In practice, a user or app authenticates, receives scoped access, and then interacts with healthcare data through policy checks that define which resources are available. That makes IAM the control point for consent, app trust, and data minimization. If scope design is too broad, interoperability becomes a route to excessive access rather than secure data sharing.

Practical implication: teams should treat SMART on FHIR scopes as security controls, not just integration settings.

Why healthcare interoperability creates NHI governance risk

Healthcare interoperability creates many non-human identities because apps, APIs, service accounts, and integration tokens often act on behalf of people and systems. These identities can persist longer than user sessions, move across organizational boundaries, and be reused in ways that are hard to observe. The technical risk is not only authentication failure. It is also over-privilege, weak offboarding, and unclear ownership when a third-party app continues to hold valid access after business need changes.

Practical implication: inventory every app-facing identity and tie it to an owner, purpose, and expiration rule.

What secure authorization should look like in digital health ecosystems

A secure healthcare identity architecture should combine least privilege, short-lived access, strong auditing, and explicit trust boundaries between providers, payers, and app developers. FHIR makes data exchange easier, but it does not by itself decide whether a caller should see a given record, claim, or clinical resource. That decision belongs to IAM policy, consent handling, and continuous monitoring. When those controls are weak, interoperability can amplify lateral access across connected systems.

Practical implication: enforce access by app purpose and resource type, then review those rules continuously.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SMART on FHIR is not an interoperability problem first. It is an identity governance problem first. The source article correctly centers IAM because healthcare connectivity only becomes useful when access remains controlled across multiple systems and organizations. Once apps, APIs, and service accounts can move patient data, the real question is whether identity policy is precise enough to preserve privacy and availability. Practitioners should design SMART on FHIR programs as governance programs, not just integration programs.

Healthcare interoperability expands non-human identity sprawl faster than most teams expect. Every API integration, delegated app, and vendor connection creates another non-human identity that needs ownership, rotation, auditability, and offboarding. The field still tends to understate how quickly these identities accumulate when digital care becomes the default. That is why lifecycle control, not just authentication, is the real differentiator in healthcare IAM maturity.

Least privilege is the only durable control model for digital health ecosystems. Shared data platforms invite broad access patterns, but broad access creates avoidable exposure when a single application reaches more records than it needs. IAM policies must reflect patient data sensitivity, application purpose, and business context instead of relying on static trust in a healthcare vendor relationship. Practitioners should expect interoperability to fail safely only when privilege is intentionally constrained.

Identity blast radius is the right concept for healthcare interoperability programs. The more systems that can authenticate into the same clinical data environment, the more damage one credential, token, or app compromise can create. This is especially true when access spans providers, payers, and external developers, because revocation and monitoring become more complex. Teams should measure how far a single app identity can reach before they call the architecture secure.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• For the lifecycle angle, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that apply to healthcare integrations.

What this signals

Identity visibility, not just integration architecture, will determine whether healthcare interoperability scales safely. When teams cannot see every app, token, and service account in play, they cannot prove that access remains appropriate over time. The governance burden grows quickly in connected care environments, so the next step is to make non-human identity inventory a standing operational control, not a periodic project.

With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, healthcare interoperability programs should assume that overreach is the default unless scopes are tightly constrained. That means tighter approval gates, shorter-lived access, and stronger offboarding discipline for every external app path.

The forward-looking shift is toward identity-centric interoperability, where data exchange is allowed only when the calling app, the resource, and the context all satisfy policy. Teams that adopt that model now will be better positioned to handle digital health ecosystems that include providers, payers, consumers, and AI-driven applications.

For practitioners

• Map every SMART on FHIR app to an accountable identity owner Create an inventory of each app, service account, token, and integration path, then assign a business and technical owner for approval, review, and offboarding.
• Reduce access scope to the minimum FHIR resources required Define scopes by use case and resource type, then test whether any app can read or write data beyond its stated clinical or operational purpose.
• Build offboarding into third-party healthcare integrations Require a formal revocation process for every external app so access is removed when a contract ends, a use case changes, or a vendor relationship is retired.
• Add continuous audit logging for API-driven health data access Log who accessed which resource, through which app, and under what scope so security and compliance teams can detect anomalous access patterns quickly.

Key takeaways

• SMART on FHIR succeeds only when IAM can control access as tightly as it enables connectivity.
• Healthcare interoperability expands non-human identity sprawl, which raises the need for lifecycle control and visibility.
• The practical goal is not broader data sharing at any cost, but safer sharing with least privilege, logging, and offboarding.

Key terms

• SMART on FHIR: SMART on FHIR is a healthcare interoperability pattern that combines the SMART app framework with HL7 FHIR data exchange. It lets applications request scoped access to clinical data through standardized authorization flows, which makes identity controls central to both security and usability.
• Healthcare Identity And Access Management: Healthcare identity and access management is the discipline of controlling who or what can access patient data, clinical apps, and connected services. In interoperability programs, it must cover users, APIs, service accounts, vendors, and delegated apps so privacy and auditability remain intact.
• Non-human identity: A non-human identity is any machine-driven credential or account that acts in a system without a person directly logging in. In healthcare, this includes app tokens, API keys, service accounts, and integration identities that often persist across systems and require strict lifecycle control.
• Authorization scope: Authorization scope is the set of actions and data resources a caller is allowed to access after authentication succeeds. In SMART on FHIR environments, scope is a primary security boundary because it determines whether an app can see only the records it needs or far more.

Deepen your knowledge

SMART on FHIR authorization and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for healthcare interoperability, it is worth exploring.

This post draws on content published by Ping Identity: Beyond Compliance, using IAM to surpass the healthcare interoperability status quo. Read the original.