Every healthcare product is mostly APIs. The mobile app talks to the backend, the backend talks to the EHR, the EHR talks to the lab. HIPAA does not certify an API and does not name one. What it does is set Security Rule safeguards for every system that touches protected health information (PHI), and an API is where those safeguards are easiest to get wrong, because it is where data crosses a boundary.
This guide covers the eight controls we build into healthcare APIs from the first sprint, and the mistake we most often find behind each one. It is the API-level companion to our guide to HIPAA-compliant backend architecture.
1. Authenticate every caller, authorize every object
The Security Rule asks for access control (45 CFR 164.312(a)) and person or entity authentication (164.312(d)). For an API that means OAuth 2.0 with OpenID Connect for user-facing flows, short-lived access tokens measured in minutes, refresh token rotation, and client credentials with mutual TLS for service-to-service calls. For FHIR APIs, SMART on FHIR scopes such as patient/Observation.read express least privilege directly in the token.
The mistake we find most often: the API validates the token but never checks that this user may see this record. Change /patients/1042/records to /patients/1043/records and you are reading someone else's chart. OWASP ranks broken object-level authorization first in its API Security Top 10 for this reason. Check the relationship between caller and record on every request, on the server, every time.
2. Encrypt everything in transit
Transmission security (164.312(e)) means TLS on every hop that carries PHI. Use TLS 1.2 as the floor and TLS 1.3 where you can, in line with NIST SP 800-52 Rev. 2. Add HSTS on public endpoints, and use mutual TLS between internal services rather than trusting the network behind the load balancer.
Encryption is an addressable specification in the current text of the Security Rule, which means you implement it or document an equivalent measure. In practice no hospital security review accepts an API that skips it, so treat it as required.
3. Keep PHI out of URLs and logs
Paths and query strings end up in access logs, CDN logs, browser history, referrer headers and APM traces. Use opaque identifiers in paths (random UUIDs, never an MRN or an SSN), send searches that include a name or date of birth in a POST body, and strip request and response bodies from application logs by default.
The mistake: debug logging left on in production, quietly recording full payloads into a log store that nobody classified as PHI.
4. Log access, not content
Audit controls (164.312(b)) are about being able to answer who did what to which record, and when. For every call, record the user and client, the resource type and ID, the action, the time, the source IP and the outcome. Ship the log to write-once storage separate from the application database, and alert on patterns such as one account reading hundreds of records in an hour.
Note the difference from control 3: the audit log records that a record was read, never the record itself. Retention is set by your policy and your state's rules.
5. Return the minimum necessary
The minimum necessary standard (164.502(b)) shapes API design more than most teams expect. Filter fields by role and token scope, avoid endpoints that return the whole patient object, cap page sizes, and keep clinical and billing data behind separate scopes. Make error messages generic and free of PHI, and return the same response for "not found" and "not yours" so nobody can enumerate records by watching which errors they get.
6. Sign webhooks and keep them thin
Webhooks are the API teams forget. Sign every payload (HMAC with a timestamp), reject replays, and put only an event type and an ID in the body. The receiver then fetches the record through the authenticated API. A webhook that posts a lab result to a customer's endpoint is a PHI transmission to whatever happens to sit behind that URL.
7. Put every vendor in the path under a BAA
API gateways, web application firewalls, logging and monitoring tools, and error trackers all see traffic. If a vendor can see PHI, it is a business associate and needs a signed BAA. If you cannot get one, configure the tool so it never sees PHI. The most common gap we find is an error tracker or APM tool capturing request bodies with no BAA in place. Our guide to what a BAA for app developers must cover walks through the clauses.
8. Rate limit, validate and test
Rate limit per client and per user. Validate every input against a schema and reject unknown fields. Protect integrity (164.312(c)) with idempotency keys on writes and versioning or ETags so two clients cannot silently overwrite each other's edits to a clinical record. Then test the API itself: automated authorization tests in CI (user A cannot read user B), and penetration testing aimed at the API, not just the web front end.
If your API connects to an EHR or exposes FHIR
The same eight controls apply. EHR vendors review third-party apps before they allow a connection, and that review tests exactly these areas: scopes, token lifetimes, audit trail and what leaves in webhooks and logs. Building them in early is faster than retrofitting them to pass the review.
Where Bitsol fits
We build healthcare backends and integrations with these controls designed in from the first sprint, as part of the 8-Week HIPAA-Compliant MVP Launch, and we have delivered 50+ projects for HealthTech teams. If you are choosing a partner for the build, start with our guide to how to choose a HIPAA-compliant software development company, or see our HIPAA compliant software development page.
Sources
HHS: HIPAA Security Rule, 45 CFR 164.312 technical safeguards (eCFR)
HHS: Minimum Necessary Requirement, 45 CFR 164.502(b)
NIST SP 800-52 Rev. 2: Guidelines for TLS Implementations
OWASP API Security Top 10 (2023)
HL7: SMART App Launch Framework
