Open source API management for HIPAA

Keep the exported TLS settings for every listener that carries ePHI, including protocol versions, cipher suites, certificate chain and the HSTS or redirect policy in force on each route. The gateway, typically Apache APISIX or Kong Gateway, produces these from its configuration files and admin API, so the export should be taken from the running system, dated and stored under change control. Pair it with scan output from your own testing tools to show the settings were checked, not only written. This evidence supports 45 CFR 164.312(e)(1) and the encryption decision under 164.312(e)(2)(ii). Confirm with your assessor which format they want, since the Security Rule does not prescribe one, and check the cryptographic guidance in NIST SP 800-52 against your chosen settings.

Maintain a certificate inventory listing each hostname, issuer, expiry date, key length, the gateway or service that terminates the certificate, and the owner responsible for renewal. The inventory is produced from the gateway's certificate objects and your internal certificate authority or secrets store, and it should be reconciled against a periodic scan of the public and internal endpoints. Reviewers use it to confirm that no ePHI route runs on an unmanaged certificate and that renewal is handled before expiry. Record the process for revoking and replacing a compromised certificate alongside the inventory. The inventory is your own operational record; it is prepared for independent assessment and does not itself establish compliance.

Export the realm configuration, client definitions, role and scope mappings, authentication flows, password and MFA policies, and session and token lifetime settings. Keycloak produces these through its admin console or the export tooling in its server administration documentation, and the Keycloak Operator's custom resources such as KeycloakRealmImport and KeycloakOIDCClient can keep client definitions in version control. Reviewers look for evidence that each FHIR-facing client has a defined scope set and that human and service accounts are governed by documented policies. Exports should exclude client secrets, which belong in a secrets manager. Store each export with its date and the change ticket that produced it, so the configuration at any point in time can be reconstructed.

Yes, and this is the most direct way to show what the gateway enforces. Keep route definitions, upstream FHIR server mappings, the openid-connect plugin settings and rate limits as declarative files in a Git repository, with pull requests and approvals required before merge. In Apache APISIX, standalone mode reads conf/apisix.yaml, which suits file-driven review, while decoupled or traditional deployments can be synchronized from the same source with your deployment tooling. The commit history then shows who changed which route, when, and under which approval. Confirm with your gateway partner how secrets are referenced rather than committed, because plaintext credentials in a repository will undermine the evidence.

Access logs should record who made each request, what resource was requested, when it happened, the outcome, and the source address, with the subject identifier taken from the validated token rather than from client input. The standard at 45 CFR 164.312(b) asks for mechanisms that record and examine activity in systems that use ePHI, so the gateway access log and the Keycloak event log should be forwarded to central storage that the application team cannot silently edit. Avoid logging full request bodies or raw tokens, since that creates a second copy of ePHI. Confirm with your team how patient identifiers in URL paths are masked or hashed before they reach the log store.

Document how long each log category is kept, where it is stored, who can read it, and how reviews are performed and recorded. The retention period is set by your own policy and any other law that applies to you; HIPAA does not fix a number in the Security Rule text, so confirm the period with your privacy and legal teams. The gateway and Keycloak produce the logs, while your security operations process produces the review records, such as a dated list of alerts examined and the disposition of each. Reviewers commonly ask for a sample of these review records, so keep them as searchable entries rather than informal notes. Test that logs can be retrieved within the timeframe your procedure states.

The risk analysis itself is your organization's document, and it should record the decision on whether and how to use encryption for each API path that carries ePHI. HHS OCR's risk analysis guidance names this decision as one the analysis should inform. The gateway and Keycloak supply the technical facts the analysis relies on, such as supported protocol versions, the mutual TLS option for internal hops, and where traffic is decrypted. Tie each entry to the specific route or network segment and to the TLS records described above, so a reviewer can trace a decision to its configuration. DeployOpen can help prepare the technical inputs for this analysis, but the risk decisions remain with your organization.

For each addressable specification that applies to the API layer, record whether you implemented it, and if not, why it is not reasonable and appropriate and which equivalent alternative you chose. Under 45 CFR 164.306(d), this documentation is required for the decision itself, not just the outcome. The integrity and encryption specifications under the transmission security standard are the ones most often recorded here. Keep the decision memo, the date, the approver and a review date, and link it to the risk analysis entry. The gateway configuration can then be cited as the evidence of the chosen measure, which keeps the written reasoning and the running system consistent.

Keep a change record for each upgrade that names the component, the source version and target version, the test evidence, the approver, and the rollback plan. For Keycloak, the Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades, and schema migrations run automatically at startup by default, so record which mode you use and the pre-upgrade database backup. For APISIX, record the release used, such as the 3.19.0 release published on September 28, 2026, and note any plugin changes. These records show that security-relevant configuration was controlled over time. Confirm the upgrade cadence and support terms with your implementation partner in the written scope.

The cost is driven by scope: how many APIs and FHIR servers sit behind the gateway, how many identity integrations Keycloak must support, how long logs must be retained, and whether the design needs high availability. Each added FHIR server adds routing, authorization mapping and access logging work. Documentation effort grows with every control you must evidence. Ask any partner to price these components separately so you can see which ones move the total.

One-time costs usually include the risk analysis support, architecture and configuration of the gateway and Keycloak, integration with FHIR servers, testing, and the initial control documentation. Recurring costs include Keycloak and APISIX patching, version upgrades, log storage and retention, monitoring, backup testing, and any ongoing support or testing retainer. Keycloak releases four minor versions a year according to the project's release plan, so budget for recurring upgrade work rather than treating the platform as finished at launch.

HIPAA transmission security is addressable, so your organization must decide what is reasonable and appropriate, and that decision belongs to you. You will need a named risk analysis owner, clinical reviewers who understand which FHIR resources and patient data flows are in scope, security reviewers who approve encryption and audit decisions, and network staff who can grant the gateway, Keycloak and FHIR server connectivity. Confirm these people and their time before a quote is finalized, because missing reviewers are a common cause of delay.

A capable platform team can deploy APISIX, Keycloak and the logging stack alone, provided it has experience with TLS configuration, OpenID Connect, database operations and Kubernetes or equivalent hosting. The harder parts are usually the HIPAA-specific decisions: documenting why an addressable specification was or was not implemented, proving audit logging is reviewed, and testing object-level authorization in the FHIR layer. Decide which of these your team can evidence internally, and consider a fixed-scope partner for the rest.

Duration depends on the number of APIs, FHIR servers, identity flows, the chosen high availability design and how quickly reviewers return decisions. No fixed duration applies across these variables, so ask any partner to tie its timeline to a written scope with named deliverables and dependencies. Expect the schedule to slip if the risk analysis or identity design is still open when build work starts.

No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that a certification does not prevent HHS from later finding a violation (HHS FAQ 2003). Budget for evidence instead: a documented risk analysis, configuration records, access and audit logs, and test results. Any vendor offering a HIPAA certificate should be asked to explain exactly what it certifies and who issued it.

A fixed-scope quote should list the APIs and FHIR servers covered, the identity integrations, the deployment mode and high availability design, the logging and retention approach, and the documentation deliverables. It should name client responsibilities such as reviewer availability and network access, state what is excluded, and define acceptance tests. Ask for one-time and recurring costs listed separately, including upgrade and patching support. DeployOpen does not publish a price list, and quotes follow from the written scope.

Under 45 CFR 102.3, the inflation-adjusted civil money penalty for violations on or after February 18, 2009 ranges from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294, for penalties assessed on or after January 28, 2026. These figures apply to the whole Security Rule, not only transmission controls, so use them to frame the business case for a documented, funded control program rather than as a precise estimate of your exposure.