HIPAA API Safeguards Guide

What does HIPAA require of an API that handles ePHI?

HIPAA requires an API that handles ePHI to meet the technical safeguards in 45 CFR 164.312: access control, audit controls, integrity, person or entity authentication and transmission security. The rule is technology-neutral, so it names outcomes, not protocols, and the API owner documents in a risk analysis how each outcome is met.

The API owner is usually a covered entity or a business associate. A wearable company that receives device readings for a provider's remote monitoring program, for example, handles that data as the provider's business associate and needs a business associate agreement before the first reading arrives.

No federal body certifies an API as HIPAA compliant. What exists is evidence: the risk analysis, the configuration, the test results and the audit records that show the safeguards work.

Which 164.312 safeguards are required and which are addressable?

Unique user identification, emergency access, audit controls and person or entity authentication are required. Automatic logoff, encryption at rest, integrity mechanisms and encryption in transmission are addressable, which means implement them or document why an equivalent measure is reasonable.

• Unique user identification, required: Every caller, human or system, has its own identifier. Shared API keys across clients fail this.
• Emergency access procedure, required: A documented way to reach ePHI during an emergency, such as a break-glass role with extra logging and an after-the-fact review.
• Automatic logoff, addressable: For an API, this becomes session and token lifetimes that end inactive access.
• Encryption and decryption, addressable: Encryption of ePHI at rest in the API's databases, caches, queues and files.
• Audit controls, required: Mechanisms that record and examine activity in systems holding ePHI.
• Integrity mechanism, addressable: A way to confirm ePHI has not been altered or destroyed improperly, such as checksums or signed payloads from devices.
• Person or entity authentication, required: Proof that the caller is who it claims to be.
• Transmission security, addressable: Integrity controls and encryption for ePHI in transit.

Addressable does not mean optional. An API that sends ePHI over the internet without encryption would need a strong documented reason, and it would lose the breach notification safe harbor that HHS gives to properly encrypted data.

In what order should an ePHI API apply its safeguards?

Design and test the safeguards in six steps: authentication, authorization, transport security, audit controls, rate limiting, then logging without PHI. Each step depends on the one before it. The audit record needs the identity from step 1 and the decision from step 2, and the logs in step 6 must not undo what step 4 protects.

• 1. Authentication: Identify every caller. Patient and clinician apps use OAuth flows such as SMART App Launch; server-to-server clients use SMART Backend Services with a signed JWT, or mutual TLS.
• 2. Authorization: Check, on every request, that this caller may perform this action on this patient's record. Scopes say what kind of data; object-level checks say which records.
• 3. Transport security: Encrypt every hop that carries ePHI, including traffic between internal services, not only the public edge. HHS breach guidance points to NIST SP 800-52 for TLS, and ePHI encrypted to that guidance is not unsecured PHI for breach notification.
• 4. Audit controls: Write an access record for each request: caller, client, patient, resource, action, outcome and time, in a store the application cannot rewrite.
• 5. Rate limiting: Cap requests and page sizes per client, so one runaway integration cannot exhaust the API for everyone. Availability of ePHI is part of the Security Rule's purpose, not only an operations goal.
• 6. Logging without PHI: Keep names, dates of birth, identifiers and resource bodies out of application logs, traces, metrics and error reports. Logs are copied to more tools and people than the database.

At runtime the TLS handshake happens before any token is read. The order above is the order of dependency for design and review: a team that starts with transport and logging, and leaves identity for later, ends up rewriting the audit trail.

How should the API prove who is calling?

The API should verify a short-lived credential on every request, issued to one named client or user. The Security Rule asks for proof of identity, and the API owner chooses the method.

For patient and clinician apps, SMART App Launch builds on OAuth 2.0 and OpenID Connect, and gives the API a token that carries the user, the scopes and the patient context. The API checks the signature, issuer, audience and expiry before it reads the body.

For device clouds and partner systems, SMART Backend Services has the client sign a JWT with its private key and exchange it for an access token. Each partner gets its own client registration, so access can be revoked for one partner alone.

Multi-factor authentication for the people who administer the API is good practice. The HHS Security Rule proposed rule of January 2025 would make MFA and encryption required, but it is a proposal, not a final rule.

Token lifetime is where the addressable automatic logoff specification shows up in an API. Keep access tokens short, tie refresh tokens to a revocable grant, and end the grant when a patient disconnects a device or a partner contract ends.

Logging without PHI

Audit records and application logs are different things, and only the audit record should identify a patient. Mixing them turns the logging platform into a second copy of the patient database.

• Audit record: Holds the patient identifier, the caller and the action, in a restricted store with its own access controls and retention.
• Application log: Holds request IDs, error codes, timings and client IDs. It never holds names, dates of birth, member numbers or resource bodies.
• URLs: FHIR searches by name or birth date put PHI in query strings, which then land in proxy, CDN and load balancer logs. Send them as POST _search bodies.
• Errors: Exception handlers and validation messages often echo the request body. Scrub them before they reach an error tracking service.
• Review: Audit records need an owner and a review schedule, not only storage. Someone should look for unusual access patterns on a fixed cycle, not only after an incident.

Retention is a separate decision. HIPAA's documentation retention rule covers policies, procedures and required documentation, not audit logs. Set log retention through the risk analysis and customer contracts, and keep it long enough to investigate an incident found late.

Test the logging rule the same way as the other safeguards. Send synthetic patients with distinctive names through every endpoint, including failing calls, then search the log platform, traces and error tracker for those names. Any hit is a defect, and the search belongs in the release checklist.

How do you prove the safeguards work?

Prove them with tests that try to break each safeguard and must fail, run on every release. Tests that only send valid calls prove the API works, not that it is safe.

• Wrong caller: A request with no token, an expired token or a token issued for another audience is rejected before any data is read.
• Wrong patient: A token scoped to one patient asks for another patient's records by ID, through search, through included resources and through paging links, and gets nothing.
• Wrong action: A read-only client tries to create, update or delete a resource and is refused.
• Plain transport: A connection without TLS, or with an outdated protocol version, fails at internal hops as well as at the edge.
• Audit trail: Every test above leaves an access record with the caller, patient, action and denial, and the application's own account cannot delete it.
• Limits: A load test from one client is throttled while a second client's calls keep their normal response times.
• Error paths: A malformed request that causes a server error returns a generic message, and the error tracker holds no request body.

Put these tests in the release pipeline. A new endpoint that skips one of the checks then fails the build instead of reaching production, and the test results become the evidence a customer's security team asks for.

Keep a small set of synthetic patients and test clients for this purpose, each with a documented role. Reusing real accounts or copied production data in security tests creates the exposure the tests are meant to prevent.

Where ePHI APIs fail a security review

Each of these gaps is simple to find in a review, and cheaper to fix before partners connect. This failure-point list maps to the six steps above.

• Shared credentials: One API key used by several clients or several hospitals, so neither identification nor revocation works per caller.
• Scope without object checks: The token allows Observation reads, and the API returns any patient's observations when given an ID.
• TLS only at the edge: Traffic is encrypted to the load balancer and travels in plain text between internal services.
• Audit trail in the app database: The same service account that writes clinical data can edit or delete its own access records.
• No per-client limits: A device sync bug retries in a loop and slows the API for every other customer.
• PHI in logs: Request bodies are logged at debug level in production, and the logging vendor has no BAA.
• Untested deny paths: Tests cover valid calls only, so nobody has proved that an expired, wrong-audience or wrong-patient token is rejected.

How Agnotic can help

Device and wearable data is often the first ePHI a digital health product handles at volume, and its API sets the pattern for everything after. Agnotic Technologies builds those APIs for the client with the six safeguards in place: per-client credentials, object-level authorization, encryption on every hop, a separate audit store, per-client limits and PHI-free logs.

Agnotic also writes the evidence a customer's security team asks for, mapping each control to 164.312 and recording the deny-path tests that prove it works.

Sources

• 45 CFR 164.312: Technical safeguards
• HHS: Guidance to render unsecured PHI unusable, unreadable or indecipherable
• Federal Register: HIPAA Security Rule proposed rule, January 2025