Tenant resolution at the edge
The tenant is resolved once per request from a verified token, the database connection is switched, and every later query runs inside that boundary. There is no helper that accepts a raw tenant ID from the client.
Security Rule, translated to code
HIPAA compliant software development, explained for the people who have to ship it
The Security Rule is short on specifics and long on judgment. This page shows how we translate it into concrete engineering decisions, what we document along the way, and where compliance stops being a software problem and becomes a policy one.
Compliance is shared. We build software that supports the safeguards. You still need policies, workforce training, a risk analysis and a compliance officer. We help with the technical parts of that work and we say clearly when something is outside the code.
Safeguard map
What the rule asks, what we build, what we hand you as evidence
Technical safeguards (45 CFR 164.312)
| Requirement | How we build it | Evidence you can keep |
|---|---|---|
| Access control | Unique user IDs, role based permissions, least privilege by default, automatic logoff, and an emergency access procedure that is logged and reviewed. | Role matrix, permission tests, session timeout configuration |
| Audit controls | Application level logging of every read, create, update, export and delete of PHI, with user, tenant, record, source address and time. Append only storage kept apart from the app. | Log schema, retention setting, sample audit report |
| Integrity | Database constraints, versioned records for clinical notes, checksums on stored files and medical images, and tamper evident logs. | Migration history, file hash verification job |
| Person or entity authentication | Multi-factor sign-in, short lived access tokens, refresh token rotation, lockout and rate limiting, and signed device sessions for mobile apps. | Auth flow diagram, lockout test results |
| Transmission security | TLS 1.2 or newer everywhere, HSTS, certificate pinning on mobile where it fits, signed webhooks, and encrypted messaging for clinician to clinician chat. | TLS scan report, webhook signature tests |
Administrative safeguards (45 CFR 164.308)
| Requirement | How we build it | Evidence you can keep |
|---|---|---|
| Risk analysis and management | We run a data flow and threat review with you at the start, record the risks we find, and track each to a fix. It feeds your own risk analysis. It does not replace it. | Data flow map, risk register |
| Workforce access | Named engineers only, onboarding and offboarding checklists, hardware and account controls, and confidentiality terms in every contract. | Access list, signed confidentiality terms |
| Contingency planning | Encrypted backups, per tenant restores that we actually test, and a written recovery plan with targets agreed with you. | Restore test record, recovery runbook |
| Security incident procedures | A written incident runbook, on call contacts, evidence preservation and a notification path that matches your BAA. | Incident runbook, tabletop drill notes |
Physical and infrastructure safeguards (45 CFR 164.310)
| Requirement | How we build it | Evidence you can keep |
|---|---|---|
| Hosting and facilities | HIPAA eligible cloud services under a signed cloud provider BAA, private networking, no public database endpoints, and infrastructure defined as code. | Cloud BAA, network diagram, infrastructure code |
| Workstation and device use | Encrypted laptops, no PHI on developer machines, locked down production access and short lived credentials. | Device policy, credential rotation log |
| Media disposal | Cryptographic erasure per tenant when a customer leaves, and certified deletion records you can show a regulator. | Deletion certificate template |
Reusable patterns
Engineering patterns we reuse on every healthcare build
PHI aware logging
Application logs and error reports are scrubbed so names, dates of birth, member IDs and notes never leave the system. We test this with seeded sample records and a failing request.
Field level encryption for the sensitive few
Notes, diagnoses, government IDs and psychotherapy content get an extra encryption layer with tenant specific keys, so a database dump alone is not enough to read them.
Queue first for anything slow
Claims, report generation, image processing and outbound messages run on workers with retries and dead letter handling, so a clinician never waits on a third party.
Consent and purpose tracking
Patient consent, parental consent for minors, and the purpose behind each disclosure are stored as data, so access rules follow them.
Separate analytics from PHI
Product analytics use de-identified events. Mobile SDKs that would send identifiers to a third party are reviewed and, where needed, removed.
Honest limits
What software cannot do for you
- Replace your risk analysis, policies, training and sanction procedures.
- Make a vendor "HIPAA certified". No such certification exists.
- Decide whether your product is a regulated medical device. If software diagnoses or treats, talk to regulatory counsel early.
- Fix human behavior. Phishing and shared passwords still cause most real incidents.
Our BAA offer
We sign a Business Associate Agreement before we see PHI
Ask for it on the first call. We can sign yours or send ours, name the engineers who will have access, and keep real patient data out of development entirely. Your counsel has the last word on every clause.
- Signed before access. No engineer on our side opens a production system, a data export or a real record until the BAA is in place.
- Yours or ours. Send your standard BAA and we will review it, or ask for ours as a starting point. Either way your counsel has the final word.
- Named people only. Access is limited to the named engineers on your project, under written confidentiality terms, and removed the day they leave the work.
- Synthetic data by default. Development and staging use synthetic data. Real PHI is kept in production and only touched through approved, logged access.
Questions we hear
HIPAA software development questions
What does HIPAA compliant software development involve?
It means designing the application so the technical safeguards of the Security Rule are met by default: access control, audit logging, integrity, authentication and transmission security. Around that sit administrative work such as a risk analysis and workforce training, and a signed Business Associate Agreement with every vendor that handles PHI.
Is encryption required by HIPAA?
The Security Rule lists encryption as an addressable specification, which means you must implement it or document an equivalent measure. In practice it is expected. HHS guidance also treats properly encrypted PHI as unusable to an attacker, which can remove the breach notification duty if the data is lost.
How long should audit logs be kept?
HIPAA requires you to keep required documentation for six years. Many organizations apply the same period to audit logs. Medical record retention is set by state law and differs by state and by patient age, so confirm with counsel.
Can we use a no-code tool or a general chat tool with PHI?
Only if the vendor signs a BAA and the configuration is covered by it. Many popular tools do not, or only on specific paid plans. We check this before a tool goes anywhere near a workflow.
Do you help with SOC 2 or HITRUST?
We align our controls to the same families those frameworks use, and we produce the technical evidence your assessor asks for. We are not an audit firm, so the audit itself comes from an accredited assessor.
Planning a healthcare platform? Start with a conversation, not a quote.
A senior engineer will review what you have, ask about your data flows and tell you honestly whether we are the right team. We sign an NDA and a BAA before you share anything sensitive.