HIPAA compliance is an architecture decision, not a checkbox
Most healthcare automation vendors treat compliance as a procurement obstacle: a questionnaire to survive on the way to a signature. That approach produces systems that pass the review and fail the audit, because the controls were added around a design that never anticipated them.
We work the other way. PHI flow is mapped before architecture is chosen, the minimum necessary data set is defined before the schema exists, and audit logging is specified against the questions an investigator asks.
Controls on every engagement
Not aspirations. These are the conditions under which we agree to work.
Business associate agreement first
A BAA is executed before discovery begins, including for the assessment. If a vendor is willing to start looking at your workflows without one, that is information about the vendor.
PHI stays in your environment
In the large majority of engagements we build inside your own cloud tenant or data center. PHI never leaves infrastructure you control, which is simpler to defend and cheaper to audit.
Encryption in transit and at rest
TLS 1.2 or higher in transit, AES-256 at rest, with key management under your control. No PHI in logs, error traces, or analytics payloads.
Least-privilege access
Every account and service principal receives the narrowest permission set that lets it do its job. Access is reviewed quarterly and every grant is logged.
Audit logging built for review
Logging designed around what an OCR investigator asks: who accessed which record, when, from where, and under what authorization. Retention set to your policy.
Documented subprocessor chain
Every vendor that touches PHI in a system we build is inventoried with its BAA status. Any gap is flagged before that vendor is used, not after.
Minimum necessary by design
Systems are scoped to the smallest data set that supports the workflow. A surprising amount of healthcare reporting works fine on a limited or de-identified set.
NIST Cybersecurity Framework alignment
Architecture and controls mapped to the NIST CSF, which is the framework OCR references and the one your security team most likely already uses.
The documentation an auditor asks for, produced as a deliverable
We write these artifacts during the engagement, so they exist before an auditor asks.
- Data flow diagrams showing every point PHI enters, moves, rests, and leaves
- A PHI inventory naming each element, its source, and its retention
- Access control model with role definitions and review cadence
- Encryption posture documented in transit and at rest
- Subprocessor register with BAA status for each entry
- Incident response runbook with named owners and escalation path
- Technical runbooks written for your operations team, not for us
What we will not build
Being specific about the boundary is more useful to you than a capabilities list.
- Systems that make or replace clinical decisions, including triage judgment and diagnostic support
- Documentation that enters the chart without explicit clinician attestation
- Patient communication containing clinical detail without human review
- Automation that proceeds on a guess when a system it depends on has changed
- Any workflow where PHI would move through a vendor with no BAA in place
These constraints are enforced in the architecture. Read how they shape our AI agent work and our documentation automation.
Compliance Questions
Do you sign a BAA before the assessment?
Yes. The BAA is executed before any discovery work begins, including observation and system access. This is not negotiable on our side and we would treat a vendor who skipped it as a risk.
Where does PHI live in the systems you build?
In the large majority of engagements, inside your own cloud tenant or data center. We prefer architectures where PHI never leaves infrastructure you control. Where a workflow requires an external service, it is named, covered by a BAA, and approved by you before it is used.
How do you handle 42 CFR Part 2 records?
As a separate constraint on top of HIPAA. Part 2 limits when substance use disorder records can be shared. Since the 2024 final rule (compliance required from February 16, 2026), one patient consent can cover treatment, payment, and health care operations, and other disclosures still need written consent or a court order. We store each consent with its scope and keep Part 2 records tagged as they move between systems.
What happens if there is a breach?
Every engagement includes an incident response runbook with named owners, notification timelines, and escalation paths agreed in advance. Our BAA sets out our obligations for discovery, notification, and cooperation, and we will not sign one that leaves those vague.
Can you help us prepare for an OCR audit?
For the systems we build or manage, yes. The architecture documentation, PHI inventory, access model, and audit logs are produced as deliverables because auditors request them. We are engineers, not legal counsel, and we work alongside your privacy officer.
Do you use AI models with PHI?
Only under an executed BAA with the model provider, with the data flow documented and approved by you first, or with models deployed inside your own tenant so nothing leaves. We do not send PHI to a general-purpose endpoint on the strength of a terms-of-service page.
Send us your security questionnaire.
We would rather answer it before the call than after. Request our BAA and standard compliance package and we will return it the same week.