Telehealth compliance checklist for the US and UK
An engineering checklist for a telehealth platform serving US and UK patients: contracts, access and audit, clinic isolation, licensing by jurisdiction, prescribing, signatures, payments and incidents.
A telehealth platform that treats US and UK patients needs contracts (a BAA in the US, a data processing agreement in the UK), access control and an audit log, isolation between clinics, licensing checks by jurisdiction, standard messages for prescriptions, and a plan for breaches and patient requests. Build them into the architecture on day one. This is an engineering checklist, not legal advice: have counsel confirm what applies to you.
1. Contracts first
- BAA with every vendor that touches patient data. In the US, HIPAA requires a business associate agreement with each vendor that handles protected health information for you: hosting, email, messaging, payments, support tools.
- A data processing agreement for UK patients. UK GDPR requires a written contract with each processor. Sign it before data flows, not after.
- A list of subprocessors. You need to know every service that sees patient data, or you cannot sign the two items above honestly.
2. Access, encryption and the audit log
- Role-based access. A front-desk user, a nurse, a physician and a network administrator should each see only what their job needs.
- Encryption in transit and at rest. Treat it as a default, not a feature.
- An append-only audit log. Every read, edit and signature is recorded with who, what and when, and nobody can edit the log. If you cannot show who opened a record, you cannot answer an audit or a patient.
3. One clinic cannot see another
In a platform that serves many clinics, isolation is a compliance control, not a nicety. Isolate each clinic's data in the database, enforce it in code, and test it automatically: a user in one clinic must never be able to read another clinic's patients. Our own build uses a multi-tenant PostgreSQL schema with complete tenant data isolation and role-based access control.
4. Licensing by jurisdiction
- US: a prescriber must hold an active licence in the state where the patient is located. Telehealth rules vary by state, so the match belongs in code, against live registries, and not in a spreadsheet.
- UK: a prescriber must be registered with the GMC, and pharmacies with the GPhC. Providers in England are also regulated by the CQC.
- Local rules for asynchronous care differ. Check them for each jurisdiction you serve.
5. Prescriptions and pharmacies
- Use standard messages. In the US that means NCPDP SCRIPT for electronic prescriptions.
- Choose the pharmacy on inventory, licensing and proximity, and keep a record of which one received each order.
- For temperature-sensitive medicines, monitor the shipment through transit and alert before a limit is breached, not after.
6. Signatures and records
- Provider sign-off should be a real cryptographic signature with a timestamp. Our platform uses one that follows 21 CFR Part 11.
- Use a standard format for clinical data exchange. FHIR R4 is the usual choice.
7. Payments and accessibility
- If patients pay on your platform, use a payment provider that tokenises card data, and keep card numbers out of your own database (PCI-DSS).
- Patient-facing screens should meet WCAG 2.2 AA.
8. When something goes wrong
- Breaches. HIPAA requires notifying affected individuals without unreasonable delay and within 60 days. UK GDPR requires reporting a notifiable breach to the ICO within 72 hours. Write the runbook before you need it.
- Patient requests. UK patients can ask for access to their data and for it to be erased. Build the export and delete paths early.
- Outages at partners. Use queues and retries, so a slow pharmacy or payment provider delays work and does not lose it.
A one-page version
| Area | Done when |
|---|---|
| Contracts | BAA and DPA signed with every vendor and processor |
| Access | Roles defined, encryption on, audit log append-only |
| Isolation | Automated test proves clinic A cannot read clinic B |
| Licensing | Prescriber matched to patient jurisdiction in code |
| Prescribing | Standard messages, pharmacy chosen by rule, cold chain watched |
| Signatures | Cryptographic sign-off, FHIR R4 records |
| Payments | Card data tokenised, screens at WCAG 2.2 AA |
| Incidents | Breach runbook and patient-request paths written |
How we apply it
Our US and UK GLP-1 platform runs 38 clinic tenants (10 operating at scale) and 12,400+ patients, built by a dedicated pod of 33 engineers, architects and QA, with HIPAA and UK GDPR in the architecture from day zero. Read the case study, the overview of telehealth software development, or the guide to how to build a GLP-1 telehealth platform.
