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 actually asks rather than the ones a developer finds convenient to answer.
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
These artifacts are written during the engagement rather than reconstructed afterwards, which is the difference between an audit response measured in hours and one measured in weeks.
- 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 architecturally rather than by policy. 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 genuinely 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 and stricter constraint on top of HIPAA. Part 2 requires consent specific to the recipient and purpose of each disclosure, which a single consent flag cannot represent. Any build touching substance use disorder records is designed against Part 2 first and HIPAA second.
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 specifically because that is what gets requested. We are engineers, not legal counsel, and we work alongside your privacy officer rather than replacing them.
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.