A telehealth minimum viable product can look deceptively familiar to a developer: authentication, calendars, video, messages, forms, payments, and a few integrations.
The architecture gets harder when you draw the data flow instead of the screens. Patient information can cross identity providers, scheduling systems, video services, EHRs, pharmacies, payment processors, messaging vendors, support tools, logs, and analytics. Every handoff introduces an access decision, a failure mode, and an operational owner.
That is why I would not start a telehealth MVP by picking vendors. I would start by defining one care journey and making seven architecture decisions around it.
This is a technical planning guide, not legal advice. HIPAA obligations depend on the organization’s role, data, contracts, and operating environment, so the final control set should be reviewed with the appropriate privacy, security, and legal stakeholders.
Write the smallest end-to-end workflow the MVP must support. For example:
patient invited → identity verified → consent captured → intake completed → appointment scheduled → visit launched → provider documents outcome → follow-up sent.
Now mark every place where protected health information is created, received, copied, displayed, transmitted, cached, logged, or exported.
This creates a much better architecture discussion than a vendor checklist. It tells you which services are in the sensitive data path and which can be kept outside it. It also exposes accidental copies: notification payloads, support tickets, application logs, analytics events, exports, and temporary files.
For each handoff, document four things: data in, data out, system of record, and fallback if the downstream service is unavailable.
Authenticated user is not a sufficient authorization model for telehealth.
A patient, clinician, care coordinator, scheduler, organization administrator, support user, and service account should not receive the same access simply because they can log in.
Define roles in terms of actions on specific records: who can view intake data, edit an appointment, launch a visit, access clinical notes, export records, change another user’s permissions, or resolve an integration failure.
Keep administrative access separate from clinical access where possible. Record privileged actions. Make session and token lifetimes intentional rather than inheriting defaults.
Consent also needs a state model. The application should know what was accepted, by whom, when it was accepted, which version was shown, and what happens when consent is withdrawn or replaced.
The API call to create a video room may be simple. The data boundary around it is not.
Decide what identifiers are sent to the video provider, whether recordings exist, whether chat is retained, how support personnel can access session data, and what is written back to the application after the call.
The same applies to secure messaging. A message thread can become part of the care record even if the original product team thought of it as “just chat.” Define retention, attachment handling, notification content, and the difference between a clinical message and a generic reminder.
A useful design goal is to keep the minimum necessary patient context inside each external service. The application can own the richer workflow while the vendor receives only what it needs to perform its function.
Scheduling is where a lot of cross-system state begins.
The patient app, provider calendar, organization schedule, video vendor, EHR, and reminder system may all need to know that a visit exists. Do not let each service become an independent source of truth.
Choose one owner for appointment state. Give external systems identifiers that allow the application to reconcile updates. Define what happens when a reminder sends successfully but the appointment is later canceled, or when an external calendar update arrives out of order.
Notifications deserve the same discipline. Keep PHI out of SMS, email, push notifications, and logs unless the workflow genuinely requires it and the communication channel is appropriate for that use.
“The EHR has FHIR APIs” is the beginning of the integration plan, not the end.
A production connection still needs application registration, authorization, scopes, token handling, patient and practitioner matching, read-versus-write decisions, and a support plan.
SMART App Launch defines OAuth-based patterns commonly used to authorize apps against FHIR systems. The architecture should request the smallest practical scope and preserve the user and patient context needed for the workflow.
Then decide what the application is allowed to write back. Reading demographics and appointments is a different risk profile from creating notes, observations, documents, or schedule changes.
For every state-changing call, plan for an uncertain outcome. A timeout does not prove that the downstream action failed. The application may need an operation identifier, safe retry rules, later reconciliation, and a manual path that lets the provider continue while the integration catches up.
Finally, log enough context to answer operational questions without putting unnecessary PHI into the log itself.
Payments and e-prescribing are both important, but they should not spread vendor-specific assumptions through the entire product.
For payments, keep card data outside the application wherever possible by using a payment provider’s hosted or tokenized flow. The telehealth application usually needs the payment state, not the underlying card details.
For e-prescribing, treat the pharmacy network and prescribing workflow as an external capability behind a clear adapter. Onboarding, identity proofing, controlled-substance requirements, medication data, and vendor certification can make the integration timeline different from an ordinary REST API.
The application should own the care-journey state. External services should own the regulated or commodity capability they are designed to provide.
The happiest demo path should not be the architecture.
For each external dependency, define the timeout, retry policy, duplicate-event behavior, circuit or back-pressure behavior where appropriate, reconciliation job, support owner, and user-facing fallback.
Use correlation identifiers so a single appointment or operation can be traced across services. OpenTelemetry’s context-propagation model is useful background for correlating work across process boundaries.
Record meaningful application events: who did what, which record or operation was affected, the external system involved, the outcome, and whether follow-up is required. Security logs should be intentional and consistent; OWASP’s logging guidance is a useful baseline.
Then put every vendor behind an interface you can replace. A clean adapter does not make migration free, but it keeps vendor-specific payloads, webhooks, authentication, and error handling out of the product core.
The exit test is simple: if the vendor changed tomorrow, which parts of the application would have to know?
Before calling the first telehealth release “ready,” I would want clear answers to these questions:
• Can one patient and provider complete the target care journey end to end?
• Is every PHI handoff documented?
• Are roles and privileged actions explicit?
• Can the workflow continue when a non-critical external service is down?
• Are state-changing integrations safe to retry or reconcile?
• Can the team trace an operation across services?
• Is read-only versus write-back scope documented for the EHR?
• Are vendor data retention and export terms known?
• Can production onboarding be completed on the planned timeline?
• Is there an owner for each operational failure path?
That checklist is deliberately less exciting than a feature roadmap. It is also much closer to what decides whether an MVP survives first contact with real users, real vendor outages, and real production data.
A fast telehealth MVP is not the one with the fewest lines of code. It is the one with the smallest complete workflow and the fewest unresolved boundaries.
Map the care journey first. Keep external services narrow. Decide where data and state live. Design failure and reconciliation before launch. Make every vendor replaceable enough that the product does not inherit the vendor’s entire architecture.
Top comments (0)