Notifications
Clear all
Topic starter
24/06/2026 8:59 pm
TL;DR: SMART on FHIR creates a usable identity layer for healthcare apps, but Kong’s analysis shows the real control point is the API gateway, where token validation, policy enforcement, and compliant error handling determine whether FHIR access stays secure and observable. That makes edge enforcement a governance requirement, not an integration convenience.
NHIMG editorial — based on content published by Kong: Level Up Your Digital Health Platform with Kong, SMART on FHIR, Okta
Questions worth separating out
Q: How should healthcare teams secure SMART on FHIR access at the gateway?
A: Healthcare teams should validate every access token at the API gateway, enforce scopes before backend access, and log each decision centrally.
Q: When does gateway enforcement become necessary for FHIR APIs?
A: Gateway enforcement becomes necessary when multiple apps, users, and patient-context rules share the same FHIR backend.
Q: What do security teams get wrong about SMART on FHIR authorization?
A: They often assume successful login means the request is safe.
Practitioner guidance
- Enforce token validation at the edge Require every FHIR request to pass signature, issuer, expiry, and scope checks in the API gateway before it can reach backend services.
- Map FHIR scopes to explicit access policy Review the scopes your SMART on FHIR apps request and tie each one to a documented business purpose, data class, and patient-context rule.
- Transform gateway failures into OperationOutcome Configure the gateway to convert authentication failures, expired tokens, and rate-limit responses into FHIR-compliant OperationOutcome messages so client applications receive consistent, standards-based errors.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step SMART on FHIR launch sequence across Okta, Kong Gateway, and the backend FHIR server
- Example gateway configurations for OpenID Connect token validation and response transformation
- Plugin-level handling of rate limiting, caching, and audit logging for protected health information
- Concrete OperationOutcome payload examples for authentication and policy failures
👉 Read Kong's guide to SMART on FHIR security with Kong Gateway and Okta →
SMART on FHIR security: what IAM teams need at the edge?
Explore further
25/06/2026 5:56 am
FHIR security fails when teams confuse authentication with enforcement. SMART on FHIR gives applications a standard way to request scoped access, but that does not remove the need for a policy decision at the point of API execution. Kong’s framing is useful because it separates identity issuance from resource access and shows why the gateway, not the app, must become the control boundary. Practitioner implication: healthcare IAM teams should govern the full request path, not the login step alone.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do you keep FHIR error handling compliant when the gateway blocks traffic?
A: Use response transformation so blocked requests return OperationOutcome resources instead of generic API errors. That preserves the FHIR contract for application developers while still enforcing security at the edge. It also improves troubleshooting because clients receive structured diagnostics rather than an opaque denial.
👉 Read our full editorial: SMART on FHIR security needs edge enforcement, not just IAM
