Why API management for healthcare starts with patient-level access
A self-hosted gateway such as Apache APISIX or Kong can enforce authentication, routing and access logging in your own infrastructure, but patient-level authorization stays in the FHIR server or the application behind it. A health IT leader usually faces the same mix of requests: patients reading their own records through a portal, clinicians querying a care team's panel, and third-party apps calling FHIR endpoints under scopes that were granted for a specific purpose. The gateway can check that a token is valid, that the client holds the scope it asked for and that the request reached the right backend. It cannot decide whether a given patient ID belongs to the caller. Plan that decision as an application and FHIR server concern from the start, including how the FHIR server's authorization and consent building blocks are configured, and treat the gateway as one control among several.
The HIPAA Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. If your API vendor or hosting partner handles ePHI on your behalf, confirm that a business associate contract is in place under 45 CFR 164.314, including flow-down to subcontractors and incident reporting terms. There is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, so any assessor's report or badge is evidence for your own program, not a legal status. Ask your team to confirm the current state of the proposed Security Rule revision before you scope the program, because the rule text you design against may change.
For EU operators the context is tighter. NIS2 Annex I lists health as a sector of high criticality, including healthcare providers and medical device manufacturers, and France's CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34. The CNIL found external access to the patient record system lacked VPN and multi-factor authentication, and that access control ignored the care team's need to know. Those are the two questions to answer first: how external callers authenticate, and whether each scope limits access to what that role needs. Confirm with counsel which national rules and the European Health Data Space framework apply to your data flows before you finalize the design.
Which HIPAA and health requirements shape the API build
This table maps the HIPAA technical safeguards, business associate terms and two forward-looking or adjacent obligations to the gateway and FHIR server settings they affect. Read each row as a design input: the requirement on the left, the configuration it implies in the middle, and what an assessor or auditor will ask to see on the right. The main takeaway is that the gateway handles transport, identity checks and logs, while object-level access to patient records must be enforced in the FHIR server or the application.
| Requirement | Build implication | Evidence to prepare |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i), required) | Require OIDC tokens tied to individual users and clinicians, not shared API keys, at the gateway; pass the verified subject to the FHIR server for access decisions. | Identity provider configuration, token claim mapping, and a sample of logs showing a named user per request. |
| Emergency access procedure (45 CFR 164.312(a)(2)(ii), required) | Define a break-glass route or role with its own approval, logging and expiry; confirm the gateway and FHIR server can honor it without disabling authentication. | Written emergency access procedure, test records of break-glass use, and review of who can invoke it. |
| Automatic logoff (45 CFR 164.312(a)(2)(iii), addressable) | Set token lifetimes and idle session limits at the identity provider and in any client-facing session; document the chosen values and why they fit the clinical workflow. | Documented decision on addressable status, token policy settings, and the reason an alternative was chosen if not implemented as stated. |
| Audit controls (45 CFR 164.312(b)) | Log every FHIR request with user, patient context, resource type, action and outcome; forward gateway and FHIR access logs to central storage that the organization controls. HAPI FHIR offers BALP audit logging as a building block. | Log schema, retention settings, sample access records for PHI reads, and confirmation that logs cannot be altered by application users. |
| Integrity and transmission security (45 CFR 164.312(c) and (e)) | Enforce TLS on every external and internal hop, with mutual TLS for system-to-system partner calls where agreed; reject plaintext routes in gateway configuration kept in Git. | TLS configuration exports, certificate inventory, route definitions under version control, and scan results for weak protocol settings. |
| Business associate terms (45 CFR 164.314(a)(2)(i)) | Vendors and subcontractors that handle ePHI in the API path must accept Security Rule compliance, flow terms to their subcontractors and report security incidents. Confirm the contract covers the gateway, FHIR server and any hosting provider. | Executed business associate agreements, subcontractor list, and incident reporting procedure tied to gateway and FHIR logs. |
| External access controls (CNIL finding, GDPR Articles 32 and 34, 3 September 2026) | The CNIL fined Hopital Prive de la Loire EUR 500,000 for external access to a patient record system without VPN or multi-factor authentication and for access control that ignored need to know. Treat remote and partner access as requiring MFA, a private path or VPN, and role checks scoped to the care team for each patient. | Access architecture diagram, MFA enforcement evidence, and access review records showing role-based and care-relationship checks. |
| European Health Data Space (Regulation (EU) 2025/327) | Forward-looking constraint for organizations operating in the EU: data exchange and access rules may shape how patient data is exposed through APIs. Confirm applicability and timing with counsel before fixing data-sharing interfaces. | Counsel's written applicability assessment and a list of APIs whose data-sharing obligations are under review. |
Which gateway and FHIR platforms fit a health API estate
Apache APISIX is an Apache-2.0 licensed API gateway, a top-level Apache Software Foundation project, and the release listed for this page is 3.19.0, published on September 28, 2026. Its openid-connect plugin works with identity providers such as Keycloak, Microsoft Entra ID and Okta and supports authorization code, client credentials, token introspection and PKCE flows, which covers the patient and application access patterns in most FHIR deployments. APISIX offers three deployment modes: traditional, decoupled (separate data and control planes sharing one etcd cluster) and standalone, where configuration lives in a file such as conf/apisix.yaml that is reloaded when it changes. Standalone mode lets teams keep routes and plugin settings in Git and review them like code.
- Plugin coverage: The documentation describes more than 100 built-in plugins, but scope-to-route mapping and claim checks often need custom logic.
- Standalone configuration: File-driven configuration suits change control, though it removes the Admin API as a runtime management path.
- Custom plugins: Plugins can be written in Lua, or through plugin runners in Java, Go and Python, which helps where clinical teams already maintain code.
- Protocol support: HTTP, HTTPS, HTTP/3, gRPC and WebSocket are listed in the repository, which matters for streaming or bulk FHIR interfaces.
- Port exposure: In traditional mode the Admin API listens on port 9180, so restrict it to management networks.
Before committing, confirm with your team which openid-connect flows, scope checks and audit fields your identity provider and FHIR endpoints require, and test them against your own environment.
Kong Gateway is an Apache-2.0 licensed API gateway, and the release listed for this page is 3.9.4, published on October 12, 2026. It is a common choice for organizations that already run Kong for other APIs and want one gateway standard across estates. Its plugin model covers authentication, rate limiting and logging, and its declarative configuration can be kept in version control. Health teams should verify the exact plugins, licensing for enterprise features and support terms against the version they plan to run, because capability differs between the open-source distribution and commercial offerings.
- Shared standard: Teams with existing Kong operations can extend current runbooks rather than introduce a second gateway platform.
- Declarative configuration: Routes and plugins can be expressed in files for review and promotion between environments.
- Authentication plugins: Confirm which OIDC and token validation capabilities the open-source edition provides for your identity provider.
- Scope enforcement: Verify how OAuth scopes map to specific FHIR resource paths without custom code.
- Feature boundaries: Check whether logging for PHI-related fields and enterprise support features are included in the edition you select.
Ask for a written list of the plugins used in the proposed design, the version each one requires, and the features that depend on a commercial license.
HAPI FHIR is a Java API for HL7 FHIR clients and servers, licensed under Apache 2.0. Version 8.8.2 was released on September 25, 2026, and the JPA server provides a RESTful FHIR server backed by a database, covering DSTU2, DSTU3, R4, R4B and R5. The JPA server starter can be deployed with Docker, Docker Compose, Spring Boot, a WAR on Tomcat, Jetty or Wildfly, or on Kubernetes with a Helm chart. For production, the starter supports PostgreSQL and Microsoft SQL Server, and it does not support MySQL, so MySQL should not be selected for this component. HAPI does not provide one complete security layer. Instead, it supplies building blocks: authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging.
- Database choice: Use PostgreSQL or Microsoft SQL Server in production; the embedded H2 default is not a production choice.
- Java runtime: HAPI FHIR 8.2.0 requires JDK 17, so confirm the runtime your platform team supports for the version you select.
- Authorization: The AuthorizationInterceptor and search narrowing must be configured to enforce patient and app scopes per resource.
- Audit logging: BALP audit logging supports access records for PHI, but retention and review are your responsibility.
- Partitioning: JPA partitioning can separate data by region or tenant, which may help with data residency.
Confirm with your application and security teams which authorization rules must live in the FHIR server versus the gateway, and test object-level access for each resource type.
How a FHIR request travels through the gateway
A single FHIR call passes through several checks before any patient record is read, and each check leaves evidence that an auditor or security team can trace. The sequence below is illustrative of a self-hosted gateway in front of a HAPI FHIR server, and the exact configuration should be confirmed in your own environment.
Client obtains a token from the identity provider
The patient portal or clinical app authenticates the user against the organization's OpenID Connect provider and receives an access token whose scopes reflect what the user and app are allowed to do. The gateway never sees the user's password. The step is done when the token carries the expected issuer, audience and scope claims, which the team should confirm against its own identity provider configuration.
Gateway validates the token at the edge
The gateway receives the request over TLS and validates the bearer token before forwarding anything. In APISIX this is typically handled by the openid-connect plugin, which supports token introspection and works with identity providers such as Keycloak, Microsoft Entra ID and Okta. Requests with missing, expired or unverifiable tokens are rejected at this point and never reach the FHIR server. Confirm the validation method and key rotation process with your identity team.
Gateway checks scopes against the requested resource
The gateway compares the token's scopes with the HTTP method and FHIR resource type in the request, for example read access to Patient versus write access to Observation. Requests outside the granted scopes receive an authorization error at the edge. This check controls coarse access only. It does not decide whether a specific patient record belongs to the caller, which the FHIR server or a dedicated authorization layer must enforce.
Gateway routes the request to the FHIR server
After validation, the gateway forwards the request to the HAPI FHIR JPA server over an internal, encrypted connection. Routing rules map paths such as /fhir/ to the correct backend, and the gateway can carry identity claims to the server in headers. In an illustrative traditional APISIX deployment, client traffic arrives on port 9080 and the Admin API listens on port 9180, and those values should be confirmed for your topology and locked down to administrators only.
FHIR server applies resource-level authorization
The HAPI FHIR server applies its own authorization and narrowing logic, using building blocks such as its AuthorizationInterceptor and search narrowing interceptors, because HAPI states it does not provide a single security layer. This is where object-level decisions, such as whether the caller may see a particular Patient, are made. The step is complete when tests show that a valid token for one patient cannot retrieve another patient's resources through search or direct reference.
Gateway and server write access logs
The gateway records each request with the caller identity, route, timestamp, response status and correlation identifier, and the FHIR server can write audit events through its BALP audit logging support. Logs should be shipped to storage the security team controls and checked for PHI minimization, so that query strings and payloads are not copied unnecessarily. The step is done when a test read produces matching entries in both logs, linked by the same correlation identifier.
Response returns across the trust boundary
The FHIR server returns the response to the gateway, which may apply response headers, TLS settings and size limits before sending it to the client. The gateway and FHIR server form the boundary where untrusted client input stops and trusted clinical data begins, so the team should document which controls sit on each side. The sequence is verified when a penetration test or review confirms that the boundary is enforced in both directions and that no path bypasses the gateway.
Deployment patterns for FHIR behind a self-hosted gateway
Where the gateway sits, how many gateways you run, where the control plane lives and how FHIR data is partitioned all shape the PHI exposure of a health API estate. The cards below cover the deployment decisions that have to be settled before any route or OAuth scope is written, and the checks that confirm they hold in your own environment.
Gateway in the DMZ, FHIR in a private segment
Place the APISIX data plane in a demilitarized zone that accepts external and partner traffic, and keep the HAPI FHIR server in a private network segment reachable only from the gateway. The gateway terminates TLS, validates tokens and forwards requests, so the FHIR server never accepts connections from the internet. Check that firewall rules allow only the gateway-to-FHIR path, and that no direct route to the database bypasses the gateway.
Separate gateways for patient and clinician APIs
Patient-facing apps and clinician-internal applications have different identities, network origins and risk profiles, so give each its own gateway instance and route set. A patient app authenticates through a consumer identity flow with narrow patient-level scopes, while clinician tools run on the hospital network with workforce identity. Confirm that a compromise or misconfiguration in one gateway cannot widen access in the other.
Decoupled control plane in an admin network
Run APISIX in decoupled mode so the data plane handles traffic while the control plane, the Admin API and the etcd cluster stay in a secured administrative network. The Admin API on port 9180 should never be reachable from the DMZ or from application networks. Ask who holds administrative access, how it is logged, and how configuration changes are reviewed before they reach production traffic.
Kubernetes deployment with Helm for HAPI
HAPI FHIR JPA server ships with a Helm chart for Kubernetes, which suits repeatable deployment across development, test and production. Pin the chart and image versions, store the values files in version control, and keep secrets in a managed secret store rather than in chart values. Confirm that pods run with restricted privileges, that the database connection uses encrypted transport, and that the cluster network policy matches the DMZ and private segment design.
Partitioning for regional or tenant separation
HAPI FHIR JPA partitioning assigns each resource to a partition, which can separate tenants, data sources or regions within one server. This is a data isolation tool, not a substitute for authorization: the gateway and the AuthorizationInterceptor must still check that a caller's token maps to the partition it requests. Decide early whether a regional separation rule requires physically separate databases, and confirm that partition boundaries align with your data residency obligations.
Shipping PHI access events to a separate store
Gateway access logs and FHIR audit events record who read which patient record, so they are PHI-adjacent and need their own protection. Ship them to a log store that the API team and application administrators cannot edit or delete, with restricted read access and retention set by your compliance owner. Confirm that the BALP audit logging on the FHIR server and the gateway logs carry matching identifiers, so an investigation can follow one request across both systems.
What auditors and regulators will ask to see
What access logs will an auditor ask for from a FHIR API gateway?
Auditors will ask for records showing who accessed which patient resource, under which token and scope, and when. The gateway produces the request-level part: client identifier, subject claim from the validated token, scope, route, method, response status and timestamp, which APISIX can emit through its logging plugins to a store you control. The FHIR server produces the resource-level part, such as the resource type and identifier. Confirm that both logs share a correlation ID, that they are retained under your policy, and that PHI in log bodies is masked or excluded. The HIPAA Security Rule requires audit controls for ePHI systems, but it does not prescribe a log format, so agree the schema with your compliance lead before implementation.
Why does an auditor want the gateway configuration exported from Git?
An auditor wants proof that the access rules in production match the rules someone approved, and that changes were reviewed. Keep APISIX routes, plugin settings, consumers and the scope mappings as declarative files in Git, with reviewed merge requests and deployment records tied to each commit. In standalone mode, APISIX reads conf/apisix.yaml or conf/apisix.json and reloads when the file changes, so the file in Git can be the source of truth. Ask your team to show how a rollback is recorded and whether any manual Admin API changes are blocked or logged. Secrets should be referenced, not committed.
What authentication policy will reviewers expect for external app access to patient data?
Reviewers will expect a written policy that states which clients may call which FHIR resources, how users and apps authenticate, how tokens are scoped and how long they live. In practice this means OpenID Connect with an identity provider you control, authorization code with PKCE for user-facing apps, client credentials for system-to-system access, and scopes that map to FHIR resource types and patient context. The APISIX openid-connect plugin supports these flows with providers such as Keycloak, Microsoft Entra ID and Okta. Confirm the token lifetimes, the MFA requirements for external users, and how revoked clients are removed. The CNIL's 2026 fine against a French hospital for external access without VPN or multi-factor authentication shows why regulators look at this closely.
Which business associate agreements and subcontractor terms should exist before a vendor touches ePHI?
Any vendor that creates, receives, maintains or transmits ePHI on your behalf needs a business associate contract that meets 45 CFR 164.314(a)(2)(i). It must require compliance with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and require reporting of security incidents, including breaches of unsecured PHI. For an implementation partner, this covers the engagement itself. Hosting, backup and support providers that can reach ePHI are also in scope. Ask your legal team to list every party with potential access, confirm the subcontractor chain, and check the reporting timelines in the signed agreement. DeployOpen's role is to document the systems and access paths so that your agreements can be checked against them.
What does a HIPAA risk analysis look like for a self-hosted API layer?
A risk analysis identifies where ePHI flows through the API layer, what threats apply, what controls exist and how residual risk is accepted. NIST SP 800-66 Rev. 2, published in February 2024, gives a practical method for implementing the HIPAA Security Rule and is the reference most teams use. For this layer, the analysis covers the gateway, the identity provider, the FHIR server, its database, logs, backups and admin access. It should record object-level authorization risks that stay in the FHIR server or application, not the gateway. Confirm who owns the analysis, how often it is reviewed, and how findings feed a remediation plan. HHS proposed a major Security Rule revision on 6 January 2025, and no final rule had been published as of October 2026, so track that revision in your plan.
Is HITRUST required for HIPAA, and what would a HITRUST assessment scope include?
HITRUST is not required by HIPAA, and no HIPAA certificate exists. HHS states that no Security Rule standard requires certification and that private certifications do not prevent HHS from later finding a violation. HITRUST is a voluntary assessment pathway that some customers and partners request. If you pursue it, the scope must name the systems in the assessed environment: gateway, identity provider, FHIR server, database, logging and backup systems, and the hosting boundary. Your assessor, not DeployOpen, decides the outcome. DeployOpen prepares systems, controls and evidence for assessment. Confirm which CSF version and assessment type your assessor uses, and the validity period of the resulting report.
Who produces each evidence artifact, and what should we confirm before an audit?
Evidence comes from different components, so assign an owner to each before an audit. The gateway produces request logs and enforcement records. The identity provider produces authentication, MFA and token issuance records. The FHIR server produces resource-level audit data, such as HAPI FHIR's BALP audit logging, when enabled. Git and the CI pipeline produce change history for configuration. Legal holds the business associate agreements, and the risk owner holds the analysis. Confirm that each source is retained for your required period, that logs are tamper-resistant and access-controlled, and that you can produce a single patient-access timeline from them. Gaps between these sources are the most common findings in reviews.
How a healthcare API gateway rollout runs in phases
The sequence moves from knowing which FHIR and clinical APIs exist and what data they carry, to a gateway that enforces identity, logging and authorization checks before any patient-facing traffic reaches it. Each phase closes with a written output that the next phase depends on.
Inventory APIs and classify the data they expose
The team lists every FHIR endpoint, clinical interface and internal API that could be reached through the gateway, including undocumented routes found in logs and existing integration engines. Each API is tagged by the kind of electronic protected health information it returns or accepts, and by the systems and external parties that call it. The output is an API inventory with a data classification column, reviewed by the privacy officer and the security lead. The phase is done when every route in scope has an owner and a classification.
Design identity and the scope model
The team maps the existing identity provider to the gateway, deciding how patient, practitioner and application access is represented in OAuth tokens and which scopes map to which FHIR resource types and operations. The apisix openid-connect plugin supports common flows such as authorization code with PKCE and client credentials, so the design records which flow each client type uses and how token introspection is handled. The output is a signed-off identity design document and a scope catalog. Confirm with your identity team that the provider supports the flows you intend to use.
Build the gateway in a non-production environment
The build runs in a non-production environment that contains FHIR test data only, never copies of live patient records. Routes, plugins and the chosen deployment mode are defined as configuration files kept in version control, and the FHIR server, such as HAPI FHIR with a database backend, is deployed alongside them. Engineers verify that requests reach the correct FHIR server, that unauthenticated calls are rejected and that the scope catalog behaves as designed. The output is a versioned configuration set and a test report that a second engineer has reviewed.
Test object-level authorization and OWASP API risks
An independent tester, typically the security testing team, attacks the non-production build with object-level authorization tests, such as requesting another patient's resource identifiers with a valid token, along with tests for the other risks in the OWASP API Security Top 10 2023. Gateway controls like authentication and rate limits are checked separately from authorization logic that lives in the FHIR server or a consent interceptor, because the gateway cannot decide whether a given clinician may see a given patient. Findings are logged, fixed and retested. The output is a test report with each finding closed or formally accepted by the data owner.
Validate logging and retention
The team confirms that access to electronic protected health information is recorded with the caller identity, the resource, the time and the outcome, and that these records flow to storage that the organization controls. Log content is checked to ensure tokens and patient identifiers are masked where the policy requires it, and retention periods are set with legal and compliance input. Engineers also test that logs remain available during a simulated failure of the logging pipeline. The output is a logging specification and a signed record of validation results that the compliance lead can present during an assessment.
Cut over to production with a rollback plan
Production traffic moves in a controlled cutover, starting with a limited set of routes and clients chosen by the product owner and the clinical systems team. Each route change is applied from the reviewed configuration in version control, and the team watches error rates, authentication failures and log completeness during the change window. A rollback procedure is written and rehearsed beforehand so that routes can return to the previous path without manual edits. The output is a cutover record with timestamps, approvals and the rollback steps that were tested, plus a handover to operations.
Questions to ask an implementation partner before signing
Start with the questions that decide whether PHI leaks outside production. Ask how the partner keeps PHI out of non-production environments: whether test FHIR servers are loaded with synthetic data, how any copy of production data is de-identified or masked before it leaves the production boundary, and who approves that copy. Ask how a gateway configuration and HAPI FHIR JPA server are promoted between environments, and whether access logs from staging are treated as PHI. A partner that answers with a general statement about encryption has not answered the question.
Next, press on object-level authorization, because a gateway cannot enforce it. Ask how the partner tests whether one patient's app token can read another patient's Patient or Observation resources by changing an ID, and whether that test runs against the actual AuthorizationInterceptor rules and search narrowing configuration. Ask how they test scope enforcement at the APISIX openid-connect layer, including token introspection and PKCE flows, and who signs off that the clinical access model matches the care team's need to know. Request the test cases and results in writing before signing.
Then ask about evidence and operations. Ask how gateway configuration is versioned, where it is stored, who reviews changes, and whether a change requires a second approver before reaching production. For access logs, ask where they are written, who can read or alter them, how they are shipped off the gateway host, how long they are retained, and how the retention period is set against your legal and contractual obligations. Ask how the partner handles business associate terms with its own subcontractors: whether it will sign agreements that flow the Security Rule obligations and incident reporting down to any subcontractor that handles ePHI, and what the incident notification path to you looks like. Confirm the exact terms with counsel rather than assuming them. Finally, ask how upgrades happen without breaking clinical clients. Ask for their procedure for moving APISIX or Kong to a new release, including how they check the release status on the Apache APISIX downloads page and which release they select, and how they run HAPI FHIR upgrades against the JDK version the chosen release requires. Ask how they keep a rollback path, how they verify that existing SMART-style app registrations and FHIR resource responses still behave the same, and which clinical clients they test against before a change reaches production. Ask for a written upgrade runbook and a named owner for each step.
How much work does a healthcare API gateway take?
What drives the cost of a healthcare API gateway project?
The biggest drivers are the number of APIs and routes, how many identity integrations are needed, which FHIR versions and resource types are exposed, how much access logging you must retain, and how deeply the APIs are tested. Each one adds design, configuration, testing and documentation work. Infrastructure is usually a smaller line than people expect, because APISIX and Kong Gateway are open source and run in your own cloud account, data center or air-gapped network. The cost is mostly labor: architecture, plugin configuration, identity mapping, clinical scope design, testing and handover. Ask any partner to price these components separately so you can see which ones move if scope changes.
Which costs are one-time and which recur after go-live?
One-time costs usually include discovery, architecture, initial routing to the FHIR servers, identity integration, scope design, logging setup and acceptance testing. Recurring costs include security patching, gateway and plugin upgrades, certificate and key rotation, monitoring, access-log review support and changes as new clinical apps or partners are onboarded. Gateway upgrades are a recurring event in their own right: APISIX 3.19.0 was released on September 28, 2026, and Kong Gateway 3.9.4 on October 12, 2026, so a plan should assume regular version reviews. Ask whether a support retainer covers upgrades, emergency patching and on-call response, and what is excluded.
Can our internal team run a healthcare API gateway without a partner?
Often yes, if you already operate Kubernetes or VM infrastructure, have engineers comfortable with NGINX-based gateways, and can staff an identity and security function. The hard parts are rarely the gateway itself. They are keeping scopes aligned with clinical roles, testing object-level authorization in the FHIR server or application, and producing evidence that your HIPAA Security Rule controls operate. A useful test is whether two or three named engineers can own upgrades, incident response and documentation without the project lead. If not, a partner can handle the build and a retainer can cover the run phase.
How long does a healthcare API gateway implementation take?
Duration depends on scope rather than on the gateway product. A single FHIR endpoint behind an existing identity provider is a much smaller project than a multi-tenant estate with several clinical apps, external partners and a centralized audit trail. Plan for discovery of existing APIs, a decision on deployment mode (traditional, decoupled or standalone), an identity integration, a staged rollout and a clinical sign-off on scopes. No fixed timeline should be accepted until the written scope lists the APIs, identity systems, environments and acceptance criteria. Ask the partner to show which phases depend on your staff, such as access to the identity provider or clinical owners.
What must our organization supply before implementation starts?
Expect to supply access to your identity provider and its configuration, a list of APIs and the FHIR server versions in use, a data classification for each resource type, and named clinical owners who approve each OAuth scope and patient or app access rule. You will also need cloud or data center access, network and DNS approvals, a logging destination that meets your retention policy, and a business associate agreement with any partner that will handle ePHI. Under 45 CFR 164.314, that agreement must require Security Rule compliance and incident reporting. Missing inputs are the most common reason fixed-scope work slips, so ask for the dependency list in the quote.
Does the gateway fix object-level authorization problems in our FHIR API?
No. A gateway can validate tokens, enforce scopes, limit rates and log requests, but it does not know whether a clinician should see a particular patient record. That decision belongs in the FHIR server or application, using HAPI FHIR's AuthorizationInterceptor or equivalent controls, consent and search narrowing, and tested patient-level rules. Budget for test cases that try to read another patient's resources by changing identifiers, and for a review of compartment and partition design. Partitioning in the HAPI FHIR JPA server can help separate data, but it must be configured and tested deliberately.
What does a HIPAA-aligned engagement produce as evidence?
A well-run engagement produces configuration in version control, a documented architecture, a mapping of gateway and application controls to the Security Rule standards for transmission security, integrity and audit controls, access-log samples, test results and a runbook for upgrades and incidents. It does not produce a HIPAA certificate, because HHS states that no Security Rule standard requires certification. Ask the partner which artifacts are delivered, who keeps them current after go-live, and how they will be shared with your compliance team and any independent assessor you engage.
How DeployOpen scopes and supports this work
DeployOpen plans, builds and hardens the gateway and FHIR layer inside your own infrastructure, then tests and documents it. Each card below marks a part of that work, from the written scope to the evidence your compliance team receives. Every engagement starts with a written, fixed scope so that security, clinical and compliance owners agree on the boundaries before any configuration changes.
Planning and written scope
DeployOpen starts with an inventory of the FHIR endpoints, clinical APIs, consuming applications and identity providers that the gateway will front. The scope document records which APIs move, which stay on their current path, and who signs off on OAuth scopes and PHI access rules. Ask for the scope in writing, with deliverables and a timeline agreed before work starts, and confirm which environments (test, staging, production) are included.
Gateway and FHIR server build
DeployOpen implements self-hosted Apache APISIX or Kong in your infrastructure, with routing to HAPI FHIR JPA servers on the database platform your team already runs. Confirm the deployment mode with your operations team, because APISIX offers traditional, decoupled and standalone modes that change where the control plane and configuration live. The build covers TLS termination, upstream health checks and separate routes per FHIR version.
Authentication and scope hardening
DeployOpen configures token validation through your identity provider, with scopes mapped to patient, practitioner and application access. The gateway checks tokens, but the FHIR server and the application still decide which record a caller may read, so the configuration includes matching checks on both layers. Test each flow your clinical apps use, including client credentials for backend services, before go-live.
Security testing of APIs
DeployOpen tests the gateway and the exposed FHIR and clinical APIs for authorization flaws, including object-level checks where a caller changes a patient identifier to reach another record. Testing also covers injection, excessive data exposure in responses and misconfigured CORS or TLS. Agree the test scope, the rules of engagement and the handling of any test data containing synthetic or de-identified records in advance.
Audit logging and compliance evidence
DeployOpen configures access logs that record who requested which resource, from which application, and when, then routes them to a store your organization controls. The deliverable includes the control mapping, configuration records and test results that your compliance team can use in an assessment. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications; independent assessors and certification bodies make those determinations.
Retainers for ongoing support
After go-live, gateway upgrades, plugin changes, certificate rotation and periodic API testing need a named owner and a schedule. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, separate from the fixed-scope build. Ask any partner to define in writing who patches the gateway, who responds to incidents, and how changes to scopes or routes are reviewed and recorded.
