HIPAA and compliance
In healthcare the hard part is not the model, it is touching a system that already passed review. We add AI as a layer beside the validated path, with PHI handling designed so the parts your compliance team signed off on stay exactly where they are.
Is this the right tool
Treating a feature as a HIPAA feature has a real cost: BAAs, data-flow reviews, and audit-friendly logging. That cost is worth it when PHI is genuinely in the path, and wasteful when it is not.
The honest move is to shrink the compliance surface, not grow it. The best design is often the one where PHI never reaches the model at all, because it was de-identified first, or the feature was built to sit outside the regulated path. We push for the smallest possible set of parties that ever touch PHI, because every party that does is another BAA and another thing to audit.
How we build it
Compliance in an AI feature is mostly about where data goes and who can see it. We design that path first, and we are precise about what we have done versus what we can attest to.
The AI feature sits as a separate layer, not inside the workflow a regulator already approved, with a human-review checkpoint before anything writes back to a record. The validated parts do not change, so you are adding a feature rather than re-opening an audit.
Two safe patterns: de-identify data before the call so no PHI leaves your boundary, or send it only to a provider under a BAA running a HIPAA-eligible, no-training endpoint. We default to a BAA-covered endpoint with training disabled, and we log every field that leaves the app so the data path is auditable.
Our founder built exactly this in VocalMD: patients log in with hospital credentials and the app pulls medications, conditions, and lab reports through EPIC FHIR. We read the slice we need, scoped to the encounter, rather than pulling more than the feature requires.
Sensitive data is encrypted end to end where the design calls for it. VocalMD kept all sensitive data encrypted with the Virgil SDK. Access is gated by role, the way we built RBAC across five clinical roles on Nightingale Labs.
What we will and will not attest to
What it costs to run
The model bill in a compliant app is usually not the expensive part. The cost that surprises teams is the process: getting a BAA in place with a model provider, keeping data flows documented and auditable, and building the logging that proves what left the app and when. That is engineering time and legal time, and it is real.
The design lever that lowers it is de-identification. If PHI can be stripped before a model call, you avoid needing a BAA-covered endpoint for that path entirely, which removes both a cost line and an audit surface. Where PHI must reach the model, a BAA-covered, no-training endpoint costs the same per token as a standard one; the added cost is process, not compute.
We sketch both the token cost and the compliance-work cost before building, so the number you approve includes the parts that are easy to underestimate. The token side uses the same cost-model formula we apply to every AI feature.
Proof
We name only work we can stand behind, and we are precise about who delivered it and what it does and does not prove.
Built by our founder
A HIPAA-compliant telehealth app connecting US doctors and patients, shipped to both stores and live in production for over two years. Our founder built the entire mobile app, integrating EPIC FHIR to pull patient medications, conditions, and lab reports from hospital systems, and keeping all sensitive data end-to-end encrypted with the Virgil SDK.
Delivered by our team via Toptal
A remote-monitoring platform around an under-mattress bed sensor reporting heart rate and ballistocardiography to clinical dashboards. Our founder and team built the cross-platform frontend: RBAC across five clinical roles, QR-based device onboarding, and a hand-built charting engine, on a platform that pushes risk scores to an EPIC EHR.
Delivered by our team via Andela
Frontend engineering across a US school-based telehealth platform serving students. Work our team delivered spanned the OpenTok and Vonage video-visit stack, EHR charting with ICD-10, and the referral, scheduling, and insurance-capture intake flow, across a multi-portal RBAC app.
Straight answer on the gap: we have not yet shipped a production LLM feature inside a HIPAA-regulated app, and we are not SOC 2 or HITRUST certified. What we have shipped is both halves separately, production healthcare apps that handle PHI, FHIR, and end-to-end encryption, and AI features in other live mobile products. The audit is where we prove the combination on your app, in a throwaway prototype, before you commit to a build.
FAQ
Yes. As your development partner we will sign a Business Associate Agreement, and we design the data flow so the list of parties that ever touch PHI stays as short as possible. Where PHI reaches a model provider, that provider needs to be under a BAA too, which is why we default to a BAA-covered, no-training endpoint and log every field that leaves the app.
Not as Inseed, and we will not claim otherwise. The honest version: our founder built VocalMD, a HIPAA telehealth app that has run in production across 200+ hospitals for over two years with EPIC FHIR and end-to-end encryption, so we have shipped into environments that carry that bar. We have not completed a payer's formal SOC 2 or HITRUST questionnaire as a vendor. If your review requires one, we will tell you plainly what we can and cannot attest to before you sign anything.
Two safe patterns: de-identify the data before the call so no PHI leaves your boundary, or send it only to a provider that signs a BAA and runs a HIPAA-eligible, no-training endpoint. Azure OpenAI, AWS Bedrock, and Google Vertex AI all offer BAAs and HIPAA-eligible configurations, and OpenAI signs BAAs under specific terms. We default to a BAA-covered endpoint with training disabled and keep the field-level data path auditable.
Epic via FHIR, yes: our founder built exactly that in VocalMD, where patients log in with hospital credentials and the app pulls their medications, conditions, and lab reports. We have not integrated Cerner directly, but both speak FHIR, so the integration pattern carries over. If your EHR exposes FHIR, we can read from it.
Where this goes next
These are the verticals where PHI and compliance shape every decision, plus our pricing so you can size the work.
30 minutes, free. We will look at your data flows, tell you honestly where PHI can and cannot go, what we can attest to, and what we would prototype first. Shuhel will be on the call.
Book a 30-minute call