Engineering HIPAA-ready telehealth platforms: the decisions we make first
How tenant isolation, access control, audit logging, identity and vendor agreements shape a HIPAA-ready telehealth system, with what each looked like on three clinical platforms we built.
Telehealth is where HIPAA stops being a checklist. Patient data crosses clinics, prescribers, pharmacies, payment providers and, more and more, AI tools. The costly mistakes are rarely in the code. They are decisions made before launch: how tenants are separated, who can see what, what gets logged, and which vendors touch patient data.
This post covers the decisions we make first, and what they looked like on three clinical platforms we have built. It is engineering practice, not legal advice.
Start by mapping where patient data goes
Protected health information (PHI) is any health data tied to a person. Before choosing a database or a vendor, draw every place it travels:
- 01Patiententers data
- 02Apptenant-scoped access
- 03Servicesprescribing, pharmacy, payments
- 04Storageencrypted and backed up
- 05Auditevery access recorded
Every box on that line needs an owner, an access rule, and, for any outside vendor, a business associate agreement. The five decisions below follow that line.
Decision 1: separate tenants in the data layer
A telehealth product usually serves many clinics from one platform. The question is how hard the wall between them is. Two common approaches are a separate schema per clinic, and shared tables with row-level rules.
| Approach | Strength | Cost |
|---|---|---|
| Schema or database per tenant | Strong, easy-to-explain isolation | More to migrate, back up and monitor as tenants grow |
| Shared tables with row-level rules | One schema to run and change | A single missing rule can expose another clinic's records |
On our US and UK telehealth platform we built a multi-tenant PostgreSQL schema with complete tenant data isolation and role-based access control. The platform now has 38 clinic tenants, with 10 operating at scale. Read the full case study.
Decision 2: role-based access and an audit trail from the first sprint
Not everyone who works in a clinic should see every chart. Role-based access control decides who can do what, and an audit trail records who actually did it. Adding either late is hard, because every screen and every API needs to be revisited.
The same platform includes an asynchronous provider review portal with digital signature and audit logging, so a physician's decision on a chart is both signed and recorded.
Decision 3: one identity layer
Each extra login is another place for credentials to leak and another system to deprovision when someone leaves. For a multi-vendor care ecosystem we built a central identity and orchestration layer supporting OIDC, SAML and JWT token exchange. It replaced five separate vendor logins with one. See the case study.
Decision 4: offline use and payments must not weaken the boundary
Clinics do not always have a perfect connection, and patients pay for care. Both create risk if they are bolted on.
For an executive-health clinic group we moved the whole workflow to an offline-first Next.js progressive web app, so nurses can chart without a continuous connection. It runs on a hardened Node.js service architecture with HIPAA and PCI-DSS requirements built in, including a PCI-DSS compliant split-payment gateway. Read the case study.
Decision 5: infrastructure and agreements
Compliance sits on top of infrastructure that supports it. The telehealth platform runs on HIPAA infrastructure on AWS, and we execute business associate agreements as part of the day-zero architecture. A BAA is needed with any vendor that creates, receives, maintains or transmits PHI on your behalf.
Encryption is listed as an "addressable" specification in the Security Rule. That does not make it optional: you either implement it or document why an equivalent measure is reasonable. In practice, encrypt everything.
Where AI features fit
AI tools, such as transcription or note drafting, are one more vendor in the data flow, and the same rules apply:
- A vendor whose service receives PHI needs a business associate agreement first.
- Send the minimum necessary, and strip identifiers where the feature does not need them.
- Keep a record of what was sent and what came back.
- Keep a clinician in the loop before anything AI-generated reaches a chart or a patient.
We have built AI-assisted clinical documentation and EMR tooling too. See the case study.
How this looks at Techdome
In the Blueprint, compliance is a Week 1 decision: we lock compliance requirements such as HIPAA in the same week the data model is designed, and Week 7 is reserved for security review, an accessibility audit and load testing. Our healthcare and HIPAA topic page links the rest of our clinical work.
Related reading
- Telehealth compliance checklist for the US and UK
- How to build a GLP-1 telehealth platform
- Asynchronous vs synchronous telehealth: which to build first
- Telehealth metrics and KPIs
- The Techdome Blueprint: the method these decisions sit inside.
Takeaways
- Map where patient data travels first. Every stop needs an owner, an access rule and, for vendors, a BAA.
- Decide tenant isolation, role-based access and audit logging in the first sprint, not later.
- Use one identity layer and treat offline devices as part of your security boundary.
- Treat AI tools as vendors: BAA first, minimum necessary, and a human in the loop.
- Compliance is the result of your whole programme, not a property of one framework or one cloud.
Have a project like this? Talk to our engineers.
