Patient Portal vs Telehealth Platform: How to Choose the Right Architecture

There are 3 practical ways to approach the architecture.

You can build a patient portal first, introduce telehealth separately, or create a unified platform that handles both through shared authentication, data services, and workflows.

The right choice depends less on which technology appears more advanced and more on what your organisation actually needs to deliver.

A patient portal centres on authenticated patient access.

Typical functionality includes:

The portal normally connects to existing healthcare systems rather than replacing them.

For organisations already operating a mature clinical environment, patient portal development can provide a focused digital layer around existing EHR workflows.

The important architectural question is what information must move between the portal and your clinical systems. That determines the integration model, authentication approach, permissions, and data synchronisation requirements.

During healthcare implementations, we have scoped portal architecture by first identifying the patient journeys that require real-time data rather than assuming every EHR function belongs inside the portal.

A portal can therefore remain relatively focused while still providing meaningful patient access.

A telehealth platform focuses on remote clinical interaction.

Depending on the care model, it may include:

The architecture becomes more operational because the system must support a live or asynchronous care process.

A telehealth platform may need to manage the sequence from appointment booking through intake, provider review, consultation, treatment decisions, prescribing, and follow-up.

Telehealth platform development therefore requires more than adding a video component to an existing website.

The video layer needs to fit the clinical workflow around it. Authentication, permissions, patient identity, provider identity, session controls, and records integration all become architectural considerations.

A unified platform combines portal and telehealth functionality around shared services.

A patient might sign in once and access medical records, messages, appointments, forms, and an upcoming video consultation from the same authenticated environment.

The underlying architecture can share:

The main benefit is not simply having more features. Shared infrastructure can reduce duplicated workflows when the same patient journey crosses records access and virtual care.

However, a unified architecture also creates a larger initial scope. It requires more decisions around permissions, data ownership, integrations, testing, and clinical workflows.

The architecture should therefore follow the care model rather than the feature list.

The decision becomes clearer when you separate immediate requirements from future possibilities.

A clinic may need secure records access without offering remote consultations. A telehealth provider may need virtual visits first and only later require deeper patient record access.

The architecture should reflect that starting point.

A portal-first approach may make sense when your primary requirements centre on patient information and communication.

Look for signals such as:

A portal can also establish the authentication and integration foundation needed for later expansion.

That does not mean telehealth should be ignored during architecture planning. Future requirements should influence API design, identity management, permissions, and data models even if video is not part of the first release.

For a broader comparison, see our comparison of patient portals and standard websites. A public healthcare website and an authenticated patient portal solve different parts of the patient journey.

A unified architecture becomes more relevant when patient journeys naturally move between portal and telehealth functions.

Consider combining the systems when:

Integration depth matters here.

A video consultation without relevant patient context can force providers to switch between systems. A portal without a useful route into virtual care can leave patients navigating separate experiences.

During healthcare implementations, we have assessed whether a unified architecture made sense by mapping the patient journey rather than counting requested features.

That approach reveals whether shared infrastructure actually reduces operational complexity.

A unified platform sounds efficient because several capabilities share one environment. The problem starts when teams combine functions before validating the workflows that connect them.

A premature unified build can introduce unnecessary complexity around:

For a smaller practice, that complexity may not produce enough operational value to justify the initial scope.

For a large health system, the opposite can be true. Building separate systems without a clear integration strategy may create duplicated authentication, patient identity management, appointment data, and messaging workflows.

The decision should therefore consider both present requirements and credible near-term expansion.

Patient portals are no longer an experimental addition to healthcare delivery.

ASTP/ONC reported that 65% of individuals nationally were offered and accessed their online medical records or patient portal in 2024, while 77% were offered online access.

That makes portal access an important baseline when considering the next layer of digital care.

Frequency matters because occasional access and repeated digital engagement create different product requirements.

The share of frequent patient portal users, defined as logging in 6 or more times a year, doubled from 15% in 2019 to 34% in 2024.

According to ASTP/ONC, frequent use indicates that patients are increasingly returning to digital health records rather than treating portal access as a one-time activity.

For architecture teams, that changes the question.

You are no longer designing only for a patient who checks a lab result once. You may be supporting a recurring relationship involving appointments, messages, documents, treatment information, and virtual consultations.

Frequent access can justify deeper patient-facing functionality when it matches the clinical model.

For example, a patient who repeatedly accesses records may also benefit from:

That does not mean every organisation should build all these functions.

Instead, use patient behaviour to determine where integration creates meaningful value.

A hospital with established portal usage may gain more from connecting virtual visits into the existing authenticated environment. A small practice may initially need only secure messaging and appointment access.

The architectural decision should follow the journeys patients actually need to complete.

FHIR can also affect how deeply those systems connect. Our web focused guide to FHIR API integration provides additional context when planning standards-based exchange between patient-facing applications and healthcare systems.

Based on our healthcare IT experience, the most useful integration plan starts with specific data journeys rather than simply asking whether an API exists.

Adding telehealth changes the technical risk profile because the platform now supports live or asynchronous clinical communication.

A portal primarily manages authenticated access to information and services. Telehealth introduces communication sessions, real-time data flows, additional access controls, and potentially clinical actions such as prescribing.

HHS Office for Civil Rights' COVID-19 era Notification of Enforcement Discretion provided temporary flexibility around certain telehealth communication technologies. That flexibility ended after the COVID-19 public health emergency and its transition period.

HHS states that providers must consider applicable HIPAA Privacy, Security, and Breach Notification Rule requirements when providing telehealth outside that enforcement discretion.

A static portal does not conduct a live clinical video session.

A telehealth platform must protect information moving through the consultation and control who can participate.

The architecture should therefore consider:

Encryption alone does not establish a complete HIPAA safeguard framework.

Your vendor should explain how the video architecture fits within the broader security model, including identity, access, logging, infrastructure, and third party services.

Across recent compliance projects, we have incorporated session level audit logging into telehealth architecture after confirming that pandemic era HIPAA flexibility could no longer be treated as an active design assumption.

Audio consultations introduce similar access and security considerations.

The platform needs to distinguish the patient, provider, and authorised participants. It also needs a clear record of relevant system activity without creating unnecessary access to sensitive information.

Session level logging can help establish what happened within the application.

The precise events recorded should reflect the platform's risk model and operational requirements. Excessive logging can create additional sensitive data, while insufficient logging can make investigation and support difficult.

That balance belongs in the architecture discussion, not after launch.

The temporary telehealth enforcement discretion was tied to the COVID-19 public health emergency.

HHS OCR announced that the relevant HIPAA notifications would expire on May 11, 2023, with a 90-calendar-day transition period for covered providers. That transition period ended on August 9, 2023.

The practical implication for a 2026 platform is straightforward.

Do not scope telehealth around assumptions that applied during the emergency period. The platform should be designed around the applicable HIPAA requirements and the actual services, vendors, and data flows involved.

E-prescribing introduces another important architectural relationship.

The telehealth platform may collect information, the clinical workflow may generate a prescription, and an external e-prescribing service may handle the prescription transaction.

That creates a chain of systems that must be considered together.

When a third party handles PHI on behalf of a covered entity or business associate, the applicable contractual relationship needs to be assessed.

DoseSpot is an example of a third party e-prescribing service that can sit within a telehealth workflow.

The key issue is not simply whether DoseSpot is connected through an API. The project needs to establish what information moves between systems, which party performs each function, and what contractual safeguards apply.

A BAA relationship should therefore be considered during architecture and procurement rather than after the prescription workflow has already been developed.

Based on our healthcare IT experience, structuring the DoseSpot BAA relationship early helps prevent a late compliance blocker before launch.

The most common problem is not necessarily the API itself.

A project can have technically functional e-prescribing while leaving unanswered questions about:

Those gaps can surface late because e-prescribing often sits near the end of the clinical workflow.

RxHere provides an example of how pharmacy and prescribing workflows can introduce additional integration and operational considerations within healthcare platforms.

The safest approach is to map the entire transaction before development begins.

Start with the prescription event, then identify which system creates it, which system receives it, what information travels with it, and which party remains responsible at each stage.

Herexa Health required more than a patient-facing telehealth website.

The platform needed to connect patient onboarding, medical intake, clinical review, treatment management, provider operations, and e-prescribing within one healthcare workflow.

That made a unified architecture more relevant than treating telehealth and patient access as unrelated products.

The platform combined patient-facing workflows with provider-side operations and clinical processes. Its architecture included Next.js, Express.js, Prisma ORM, PostgreSQL, secure session handling, audit logging, and healthcare-specific data workflows.

The project demonstrates why the portal versus telehealth decision should happen at the workflow level.

A patient may begin with intake, move into a consultation, receive treatment management, and require prescribing. If those stages depend on disconnected systems, the operational burden increases.

A unified platform can instead establish shared identity, patient context, permissions, and workflow states where those capabilities genuinely overlap.

However, the Herexa model should not be treated as a template for every organisation.

The appropriate architecture depends on your existing EHR, clinical workflow, patient demand, telehealth model, integration requirements, and expected product scope.

The useful lesson is architectural rather than feature-based. Where patient access and virtual care share the same clinical journey, designing the relationship early can prevent duplicated infrastructure later.

Our Herexa Health case study provides further context on how those workflows were structured around a healthcare-specific digital platform.

Qrolic Health perspective: We work on healthcare platforms where patient-facing access, provider workflows, integrations, security controls, and operational requirements need to be considered together before development starts.