Apache APISIX for healthcare

The default access log fields are where most exposure starts, because the request path and query string are logged by default. A FHIR path such as /Patient/{id} can contain a patient identifier, and so can a search like /Patient?identifier= or a family and birthdate pair. Client IP, user agent and the upstream URI are usually not PHI on their own, but they can become identifying when combined with timestamps and account data. Review the log_format in your configuration and remove or mask any variable that carries request-specific data you do not need. Ask your team to list every field that reaches the log and to justify each one against a clear operational purpose.

For clinical APIs, the default answer should be no. Request and response bodies in FHIR calls contain ePHI, including names, diagnoses, medications and notes, so logging them moves PHI into a store with different access controls and retention. Body logging plugins exist in APISIX, but they should stay disabled on routes that carry patient data. If a troubleshooting need arises, enable capture only on a non-production route with synthetic data, or on a short, approved window with a named owner and a removal date. Document the decision in your risk file, since the HIPAA Security Rule expects you to assess addressable safeguards and record the reasoning.

Query strings are the most common leak path in FHIR APIs, because search parameters often hold identifiers such as medical record numbers or dates of birth. The practical controls are to keep these values out of the logged URI and to avoid placing them in query strings where possible. In APISIX, review the $request_uri and $args variables in your access log format and replace them with a masked form or a route-level identifier. Where a client must send identifiers in the query, coordinate with the application team so they move to request headers or the request body, which you can then exclude from logging. Test each change with sample traffic before it reaches production.

Bearer tokens and identity claims should never appear in gateway logs in full. When you use the openid-connect plugin, the gateway validates tokens and can pass user claims upstream as headers, and those headers can end up in logs if the format includes them. Remove Authorization and any token or session cookie from the log format, and avoid logging the claims headers that carry subject identifiers or names. If you need a user reference for investigations, log a stable pseudonymous subject identifier that your identity provider issues, and keep the mapping under restricted access. Confirm the exact header names your configuration emits by checking the plugin documentation for your APISIX version.

Log shipping should carry only the fields your security and operations teams need, after masking has run. Apply redaction in APISIX before the record leaves the gateway, not later in the SIEM, because copies made earlier in the pipeline are hard to recall. The shipped set typically includes timestamp, route name, status code, latency, consumer or client identifier and a pseudonymous subject reference. Confirm that the receiving system, whether a SIEM or a Graylog-style store, uses encryption in transit, role-based access and retention limits that match your policy. Your business associate contract should also cover any hosted log service that receives this data, since the Security Rule flows terms down to subcontractors that handle ePHI.

Test with synthetic patient data, not production records, and check the logs at every layer the record passes through. Build a test set that includes a FHIR read by identifier, a search with several parameters, a POST with a clinical body, a request with a bearer token and an error response. Send the traffic through the gateway, then search the access logs, error logs and any shipped copies for the synthetic identifiers and token strings. Repeat the test after every change to the log format, plugin list or route configuration. Keep the test scripts and results as evidence. Auditors and your own compliance team will ask how you verified the control, and a documented, repeatable test answers that question.

No. HAPI FHIR BALP audit logging records who accessed which FHIR resources inside the FHIR server, and it is a separate control from the gateway's access logs. The gateway sees the request before it reaches the server and cannot tell which resources were actually returned, so it cannot produce that record. Treat the two as complementary: APISIX logs network-level and authentication events with masked fields, while the FHIR server's audit trail covers resource-level access. Confirm the BALP configuration, its retention and who can read it, because that trail may itself contain ePHI. The HAPI FHIR security documentation describes these building blocks as parts of a layered design rather than a single security layer.

Ownership works best when the privacy or compliance lead signs off on the data elements, and the platform team implements and tests them. The compliance lead decides which fields are permitted in logs, how long they are kept and who may read them. The platform engineers write the log format, plugin configuration and shipping pipeline, then produce the test evidence. The application team confirms which identifiers their clients send and where. A partner can plan, implement and document this design in infrastructure you control, but the decisions about PHI handling remain with your organization and your legal counsel. Agree the responsibility split in the written scope before work starts.

The main drivers are the number of APIs and routes, how many identity integrations are needed, how far PHI logging and audit controls must reach, and the high availability design. Each API needs its own route, authentication and access rules, so a catalog of 10 APIs and a catalog of 80 differ mainly in testing and cutover effort. Identity work grows with each identity provider, client type and flow (for example, authorization code for patient apps and client credentials for backend services). Logging scope matters because every log sink, retention rule and redaction rule must be designed and tested. Ask any partner to price these four items separately in a written quote, and ask which costs are one-time and which recur, such as upgrades, support and testing retainers.

Duration depends on the same drivers as cost: the number of APIs, the identity integrations, the environments and the change approval steps your organization requires. No duration is set here because the research supplied for this page does not give a project timeline. A useful first step is an inventory that lets a partner estimate effort. Plan extra time for clinical and compliance review of logging and access rules, since those sign-offs often gate production cutover more than the gateway configuration itself. Ask for the timeline as milestones tied to written deliverables, with dependencies on your identity provider and network changes called out.

A fixed-scope quote needs a defined starting point. Provide an API inventory listing each endpoint, its consumers, whether it carries ePHI, and its current gateway or direct exposure. Provide identity provider access or a test tenant, the client types that must sign in, and the claims your applications expect in tokens. Name data flow owners for each clinical or patient-facing API so that logging and access decisions have an accountable person. Also confirm the hosting target (cloud account, data center or restricted network), the TLS certificate process, and your change window rules. Missing items are the most common reason a quote changes after kickoff, so ask the partner to list every assumption in writing.

Yes, an experienced platform team can build it, provided it has skills in Kubernetes or Linux operations, TLS, OpenID Connect and HIPAA technical safeguards. The gateway itself is open source under the Apache License 2.0, so licensing does not require a purchase. The harder work is usually the healthcare-specific parts: redacting PHI from access and error logs, designing consumer and role models that match care team access, and producing evidence that the controls work. HIPAA has no certification, and the HHS Office for Civil Rights reviews compliance through complaints, compliance reviews and audits, so your own documentation must show how each safeguard is implemented. Weigh your staff's capacity against that workload and against ongoing upgrades.

No. HIPAA has no certification, and HHS states that no Security Rule standard requires an entity to certify compliance. A gateway supports specific technical safeguards in 45 CFR 164.312, such as access control, audit controls and transmission security, but compliance covers the whole organization, including administrative and physical safeguards and business associate contracts under 45 CFR 164.314. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Ask your compliance lead to map each gateway control to the relevant standard and to decide which implementation specifications are required and which are addressable.

Clinical and patient-facing APIs often sit on the path to care, so an outage can delay work for many users. High availability means running more than one data plane node behind a load balancer, and deciding how configuration is stored. APISIX supports traditional, decoupled and standalone deployment modes, and each has different failure domains. Traditional and decoupled modes depend on an etcd cluster, which needs its own quorum and backup plan. Standalone mode reads a file or API configuration and removes etcd, but then configuration change control moves into your deployment pipeline. Confirm recovery targets with clinical operations before choosing a mode, because those targets set the cost of redundancy.

Start with the identity provider that already governs staff and patient accounts, then list each client type. The APISIX openid-connect plugin works with providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. Patient-facing mobile and web apps typically need authorization code with PKCE, while backend services usually need client credentials. Clinician access to FHIR servers needs claims that map to roles or care relationships, which is a design decision your identity team should own. Each provider and flow adds testing effort, so confirm the list before the quote is written.

Log the metadata that auditors and incident responders need, such as who called which route, when, from where and with what result, and exclude request and response bodies and sensitive headers. Define a field allow list rather than a block list, then test log output with synthetic PHI before production. Keep logs for a period set by your retention policy and restrict who can read them. Confirm with your privacy office whether identifiers in URLs, such as patient IDs in paths, count as PHI in your logs, since many access logs record full paths. A partner can design and test these rules as part of the scope, but your privacy and security owners must approve the final field list.