Telehealth Data Architecture: Complete Guide for Data Engineers (2026)

What Makes Telehealth Data Architecture Different

Telehealth platforms generate a distinct mix of data that traditional healthcare data models weren't designed for. A single virtual visit produces:

• A scheduling record (appointment time, platform, provider NPI)
• A video session log (duration, connection quality, participant IDs)
• An encounter record (linked to the EHR)
• Clinical notes (unstructured text, often dictated)
• One or more ICD-10 diagnosis codes
• CPT procedure codes for billing
• An HL7 or FHIR message sent to the payer
• A claims record for adjudication

📋

Free Tool

Parse this HL7 message →

Each of these hits a different system, in a different format, at a different time. The data architecture challenge is bringing them together into a coherent, queryable model while maintaining HIPAA compliance and audit trails.

---

Core Entities in a Telehealth Data Model

Members / Patients

The patient table is the anchor of any telehealth schema. Key columns:

CREATE TABLE member (
    member_id        VARCHAR(36)   NOT NULL PRIMARY KEY,
    first_name       VARCHAR(100)  NOT NULL,
    last_name        VARCHAR(100)  NOT NULL,
    date_of_birth    DATE          NOT NULL,
    gender_cd        CHAR(1),
    zip_cd           CHAR(5),
    plan_id          VARCHAR(36),
    medicaid_id      VARCHAR(20),
    medicare_id      VARCHAR(20),
    created_at       TIMESTAMP     NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at       TIMESTAMP     NOT NULL DEFAULT CURRENT_TIMESTAMP
);

🔄

Free Tool

Convert this DDL to Snowflake, BigQuery, or PostgreSQL instantly →

Telehealth-specific addition: track whether the member has a patient portal account and consented to telehealth visits — this matters for care gap reporting and outreach.

---

Providers

Every telehealth visit is tied to a licensed provider identified by their NPI (National Provider Identifier). Your provider table must store the NPI and validate it against the NPPES registry.

CREATE TABLE provider (
    provider_id      VARCHAR(36)   NOT NULL PRIMARY KEY,
    npi              CHAR(10)      NOT NULL UNIQUE,
    first_name       VARCHAR(100),
    last_name        VARCHAR(100),
    specialty_cd     VARCHAR(20),
    taxonomy_cd      VARCHAR(20),
    state_license_no VARCHAR(30),
    telehealth_eligible BOOLEAN   NOT NULL DEFAULT FALSE,
    created_at       TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP
);

NPI validation is non-negotiable for claims — an invalid NPI will reject at the clearinghouse. Use the NPI Lookup tool to validate provider NPIs before loading them into your warehouse.

---

Appointments and Encounters

The appointment is what's scheduled; the encounter is what actually happened. Keep these as separate tables — appointments are often cancelled or no-showed, and you need both for operational reporting.

CREATE TABLE appointment (
    appointment_id   VARCHAR(36)   NOT NULL PRIMARY KEY,
    member_id        VARCHAR(36)   NOT NULL REFERENCES member(member_id),
    provider_id      VARCHAR(36)   NOT NULL REFERENCES provider(provider_id),
    scheduled_dt     TIMESTAMP     NOT NULL,
    visit_type_cd    VARCHAR(20)   NOT NULL,
    platform_cd      VARCHAR(30),
    status_cd        VARCHAR(20)   NOT NULL,
    created_at       TIMESTAMP     NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE encounter (
    encounter_id     VARCHAR(36)   NOT NULL PRIMARY KEY,
    appointment_id   VARCHAR(36)   REFERENCES appointment(appointment_id),
    member_id        VARCHAR(36)   NOT NULL REFERENCES member(member_id),
    provider_id      VARCHAR(36)   NOT NULL REFERENCES provider(provider_id),
    encounter_dt     DATE          NOT NULL,
    encounter_type   VARCHAR(20)   NOT NULL,
    session_min      INT,
    place_of_svc_cd  CHAR(2)       NOT NULL,
    created_at       TIMESTAMP     NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Place of service codes matter for billing. CMS uses code 02 for telehealth provided in a facility setting and 10 for telehealth provided in a patient's home. Getting this wrong causes claim denials.

---

Diagnoses and Procedures

CREATE TABLE encounter_diagnosis (
    encounter_diag_id  VARCHAR(36)  NOT NULL PRIMARY KEY,
    encounter_id       VARCHAR(36)  NOT NULL REFERENCES encounter(encounter_id),
    icd10_cd           VARCHAR(10)  NOT NULL,
    diag_seq_no        SMALLINT     NOT NULL,
    poa_ind            CHAR(1),
    created_at         TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE encounter_procedure (
    encounter_proc_id  VARCHAR(36)  NOT NULL PRIMARY KEY,
    encounter_id       VARCHAR(36)  NOT NULL REFERENCES encounter(encounter_id),
    cpt_cd             VARCHAR(10)  NOT NULL,
    proc_seq_no        SMALLINT     NOT NULL,
    units              SMALLINT     NOT NULL DEFAULT 1,
    modifier_cd        VARCHAR(10),
    created_at         TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP
);

For telehealth, certain CPT codes require telehealth-specific modifiers (95, GT). Your procedure table should capture these modifiers — they affect reimbursement.

---

HL7 and FHIR Integration

Telehealth platforms exchange clinical data via HL7 v2 messages or FHIR APIs. The two most common message types:

ADT A04 (Patient Registration) — fired when a patient is registered for a telehealth visit. Contains demographics, insurance, and provider assignment.

ORU R01 (Observation Result) — used to transmit clinical notes, vitals, and lab results back to the EHR after the visit.

If your platform receives HL7 v2 messages, you need a parser to extract structured data before it can land in your warehouse. Use the HL7 Parser tool to validate and parse HL7 messages before ingestion.

For FHIR R4 APIs, the key FHIR resources for telehealth are:

---

HIPAA Compliance Considerations

Telehealth data is PHI from end to end. Architecture requirements:

Encryption:

• At rest: AES-256 minimum for all tables containing PHI columns
• In transit: TLS 1.2+ for all API calls and data transfers

Access controls:

• Column-level security on date_of_birth, diagnosis columns in Snowflake/BigQuery
• Row-level security so analysts only see members in their assigned population
• Audit logging for every SELECT on PHI tables

Data retention:

• Clinical records: 7 years minimum (state laws vary — some require 10)
• Billing records: 7 years per CMS requirements

---

HCC Risk Adjustment for Telehealth Populations

If you're a payer managing a Medicare Advantage or Medicaid managed care population, telehealth encounters must feed your HCC (Hierarchical Condition Category) risk adjustment pipeline.

Key rule: only diagnoses from qualified encounter types count for RAF scoring. Telehealth visits qualify if they meet CMS criteria — but your ETL must flag and validate this correctly. A diagnosis captured in a video visit that isn't classified as a qualifying encounter type won't count toward the member's risk score.

Use the HCC Calculator tool to model risk score changes as you ingest telehealth encounter data.

---

Common Mistakes in Telehealth Schema Design

1. Conflating appointment and encounter tables. Appointments and encounters are different business events with different lifecycles. Separate them from the start.

2. Not capturing place of service code at the encounter level. POS code drives reimbursement rates and claim validity. It must be stored at the encounter, not derived later.

3. Storing NPI without validation. An invalid NPI will cause claim rejections. Validate at load time, not after the fact.

4. Missing telehealth modifiers on procedure codes. CPT modifier 95 (synchronous telehealth) must be captured with the procedure. Without it, some payers will deny the claim.

5. Inconsistent column naming across telehealth and in-person encounter tables. Enforce consistent naming standards with the Naming Auditor tool.

---

Where to Start

If you're building a telehealth data architecture from scratch:

1. Define your source systems — EHR, scheduling platform, video platform, clearinghouse.
2. Model your core entities — member, provider, appointment, encounter, diagnosis, procedure. Get naming conventions right before you write the first CREATE TABLE.
3. Build your HL7/FHIR ingestion layer — parse and validate incoming messages before loading.
4. Add HIPAA controls — encryption, access control, audit logging from day one.
5. Connect to your claims pipeline — telehealth encounters must flow into your claims adjudication and risk adjustment pipelines correctly.

Tools like mdatool can accelerate steps 2–3: generating DDL from your schema designs, converting between database dialects, validating NPI numbers, and parsing HL7 messages before they hit your warehouse.