Healthcare Data Model

Healthcare Data Model

8 data marts56 fieldsVlad FlaksRus Obolonsky

Patients move from a booked appointment through the clinical encounter to the insurance claim that pays for it, while daily bed census tracks capacity alongside providers, payers and departments.

Overview

A hospital system modeled end to end — from a patient booking an appointment, through the clinical encounter that follows, to the insurance claim that pays for it. Patients, providers, payers and departments anchor the model, while appointments capture scheduling and no-show behavior, encounters capture diagnoses, length of stay and readmissions, claims capture the revenue cycle (billed, allowed and paid amounts, denials, days in accounts receivable), and daily bed census tracks capacity and patient flow across inpatient units. Together they tell the operational and financial story of running a health system: who is being seen, how care converts into cash, and where capacity is tight.

Example Questions

  • How does no-show rate vary by booking lead time and insurance type, and what would tightening scheduling windows save in lost capacity?
  • What is the claim denial rate by payer, and how much longer do denied claims sit in accounts receivable than clean claims?
  • Which departments are running closest to bed capacity, and how does occupancy relate to admissions and discharges over time?

Explore on canvas →

Appointments Data Mart

Appointments

One row per scheduled appointment, capturing how a visit was booked and whether the patient actually showed up. Each row links a patient, a provider and a department, records the scheduled date and time, how far in advance it was booked (lead time), how long the patient waited past that time, whether they were a no-show, and the appointment's final status. This is the front door of the clinical and revenue cycle — every encounter and claim downstream starts as a booked appointment here.

Fields

ColumnTypeAliasDescription
appointment_idSTRINGAppointment IDPK. Unique appointment identifier.
patient_idSTRINGPatient IDPatient who booked the appointment. FK to Patient
provider_idSTRINGProvider IDProvider seeing the patient. FK to Provider
scheduled_atTIMESTAMPScheduled AtScheduled date and time of the appointment.
department_idSTRINGDepartment IDDepartment where the appointment takes place. FK to Department
statusSTRINGStatusAppointment status (e.g. booked, completed, cancelled).
is_no_showBOOLEANIs No ShowWhether the patient failed to show up.
wait_minutesINTEGERWait MinutesDoor-to-provider wait.
lead_time_daysINTEGERLead Time DaysBooking-to-visit lead time — no-show driver.

Relationships

Related data martOnCardinalityMeaning
Departmentdepartment_id = department_idN:1The department the appointment was booked into.
Patientpatient_id = patient_idN:1The patient the appointment was booked for.
Providerprovider_id = provider_idN:1The clinician the appointment was booked with.

Bed Census (daily) Data Mart

Bed Census (daily)

One row per department per day, tracking inpatient bed capacity and patient flow over time. Each row records how many beds were staffed and how many were occupied that day, alongside the day's admissions and discharges — the numbers that drive occupancy rate and reveal whether a department is filling up or emptying out. This is the operational pulse of capacity management across the health system.

Fields

ColumnTypeAliasDescription
census_idSTRINGCensus IDPK. Unique identifier for the daily census record.
department_idSTRINGDepartment IDDepartment the census covers. FK to Department
census_dateDATECensus DateCalendar day of the census.
staffed_bedsINTEGERStaffed BedsBeds staffed and available that day.
occupied_bedsINTEGEROccupied BedsBeds occupied at census time — utilization numerator.
admissionsINTEGERAdmissionsAdmissions during the day.
dischargesINTEGERDischargesDischarges during the day.

Relationships

Related data martOnCardinalityMeaning
Departmentdepartment_id = department_idN:1The department these staffed beds belong to.

Claims Data Mart

Claims

One row per claim submitted to a payer for a clinical encounter — the revenue-cycle record that turns care into cash. Each claim tracks the billed, payer-allowed and actually paid amounts, its submission and payment dates, current status, the denial reason when one applies, and the number of days it has sat in accounts receivable. This is the mart that answers how well the health system gets paid for the care it delivers, and how quickly.

Fields

ColumnTypeAliasDescription
claim_idSTRINGClaim IDPK. Unique claim identifier.
encounter_idSTRINGEncounter IDEncounter the claim is billed for. FK to Encounters
payer_idSTRINGPayer IDPayer responsible for the claim. FK to Payer
submitted_atDATESubmitted AtDate the claim was submitted.
paid_atDATEPaid AtDate the claim was paid.
billed_amountNUMERICBilled AmountAmount billed to the payer.
allowed_amountNUMERICAllowed AmountPayer-allowed amount.
paid_amountNUMERICPaid AmountAmount actually paid.
statusSTRINGStatusClaim status (e.g. submitted, paid, denied).
denial_codeSTRINGDenial CodeCARC/RARC denial reason, when denied.
ar_daysINTEGERAr DaysDays in accounts receivable — revenue-cycle speed.

Relationships

Related data martOnCardinalityMeaning
Encountersencounter_id = encounter_idN:1The encounter being billed.
Payerpayer_id = payer_idN:1The insurer billed for this claim.

Department Data Mart

Department

Reference list of the clinical departments that make up the health system, each with the clinical specialty it serves and its staffed-bed capacity. Departments are the organizational unit behind appointments, provider assignments and daily bed census — staffed beds is the denominator for every occupancy and capacity calculation in the model.

Fields

ColumnTypeAliasDescription
department_idSTRINGDepartment IDPK. Unique department identifier.
nameSTRINGNameDepartment name.
specialtySTRINGSpecialtyClinical specialty the department serves.
staffed_bedsINTEGERStaffed BedsNumber of staffed beds — the utilization denominator.

Encounters Data Mart

Encounters

One row per clinical encounter — the actual visit that followed a scheduled appointment. Each encounter records its type (outpatient, inpatient or emergency department), the primary diagnosis, admission and discharge timestamps, the resulting length of stay, and whether it was an unplanned readmission within 30 days. This is where the clinical story lives: what patients are being treated for, how long they stay, and how often they come back unexpectedly.

Fields

ColumnTypeAliasDescription
encounter_idSTRINGEncounter IDPK. Unique clinical encounter identifier.
appointment_idSTRINGAppointment IDAppointment that led to this encounter. FK to Appointments
patient_idSTRINGPatient IDPatient seen in the encounter. FK to Patient
provider_idSTRINGProvider IDProvider who delivered care.
admit_tsTIMESTAMPAdmit TimeAdmission date and time.
discharge_tsTIMESTAMPDischarge TimeDischarge date and time.
encounter_typeSTRINGEncounter Typeoutpatient / inpatient / ED.
primary_diagnosisSTRINGPrimary DiagnosisPrimary ICD-10 code.
length_of_stay_daysFLOATLength Of Stay DaysLength of stay in days.
is_readmission_30dBOOLEANIs Readmission 30dUnplanned readmission within 30 days.

Relationships

Related data martOnCardinalityMeaning
Appointmentsappointment_id = appointment_idN:1The booking that brought the patient in.
Patientpatient_id = patient_idN:1The patient treated in this encounter.

Patient Data Mart

Patient

One row per patient, the demographic and coverage anchor for every appointment, encounter and claim in the system. Each patient carries a birth year and gender for age-banded analysis, a postal code for geographic reach, an insurance type (commercial, Medicare, Medicaid or self-pay) that determines how their care gets billed, a risk-stratification tier used by care management to flag patients who need closer follow-up, and the date they first registered with the system.

Fields

ColumnTypeAliasDescription
patient_idSTRINGPatient IDPK. Unique de-identified patient identifier.
birth_yearINTEGERBirth YearYear of birth, used for age banding.
genderSTRINGGenderPatient gender.
postal_codeSTRINGPostal CodePatient postal/ZIP code for geographic analysis.
insurance_typeSTRINGInsurance Typecommercial / Medicare / Medicaid / self-pay.
risk_tierSTRINGRisk TierRisk-stratification band for care management.
registered_atDATERegistered AtDate the patient was first registered.

Payer Data Mart

Payer

Reference list of the insurance payers and plans that reimburse the health system for care, each identified by name and plan type — HMO, PPO, EPO or government (Medicare/Medicaid). Every claim is billed to one of these payers, so this mart is the lookup behind any payer-mix or reimbursement analysis.

Fields

ColumnTypeAliasDescription
payer_idSTRINGPayer IDPK. Unique payer identifier.
nameSTRINGNamePayer / insurance plan name.
plan_typeSTRINGPlan TypeHMO / PPO / EPO / government.

Provider Data Mart

Provider

One row per clinician, the roster behind every appointment and encounter. Each provider is identified by name, clinical specialty, home department, and National Provider Identifier (NPI) — the standard identifier used to credential and bill for a clinician's services. This is the lens for looking at care delivery by clinician: who is seeing patients, in what specialty, and out of which department.

Fields

ColumnTypeAliasDescription
provider_idSTRINGProvider IDPK. Unique provider identifier.
full_nameSTRINGFull NameProvider's full name.
specialtySTRINGSpecialtyClinical specialty of the provider.
departmentSTRINGDepartmentDepartment the provider belongs to.
npiSTRINGNPINational Provider Identifier.

Apply to your project

  1. 1

    Install the Import Model plugin

    One plugin, installed once, in your own OWOX workspace.

    Get the plugin →

  2. 2

    Import this model

    Point it at this bundle and it creates every data mart above, joins and all.

    Open the model →

  3. 3

    Plug in your data and destinations

    Connect your own sources and send the results where your team already works.

    Browse connectors →

4. Optional — customize as you wish. Rename a column, drop a mart, add your own: once it is imported it is yours, and nothing here syncs back.