Patient-Generated Health Data for RWE

In plain language

Patient-generated health data are health measurements or observations patients or caregivers create outside the clinic, such as home blood pressure readings, symptom diaries, medication notes, or portal questionnaires. They are valuable because they show what happens between visits. They are risky because the people who submit data, the devices they use, and the moments they choose to measure are not random.

Patient-generated health data (PGHD)

are health-related data created or gathered by patients, family members, caregivers, or patient-controlled tools outside the usual clinical encounter. In RWE, PGHD includes home blood pressure and glucose logs, symptom diaries, patient-entered medication use, home spirometry, diet and activity logs, patient-uploaded device readings, caregiver observations, and patient-reported outcomes collected through portals or apps. The operational point is not merely "who typed the value." PGHD has a distinct data-generating process: the patient decides whether, when, how often, and through which device or app the measurement is produced and shared.

PGHD is therefore a bridge between primary data collection and secondary real-world data. It can supplement EHR and claims data with information that normally disappears between encounters: pain flares, home function, inhaler use, over-the-counter medications, diet, activity, sleep, falls, patient preference, and caregiver burden. It can also create a new bias surface. A home systolic blood pressure value can be more decision-relevant than an isolated clinic value, but only if the device is validated, the patient is trained, the timestamp is reliable, the measurement protocol is known, and non-submission is treated as informative missingness rather than normal follow-up.

Core conceptual distinction

PGHD is broader than patient-reported outcomes and broader than wearable-device data. A PRO is a standardized patient questionnaire or score. A wearable feed is device-generated sensor data. PGHD includes both, but also includes manually entered symptoms, home vital signs, treatment history, photographs, patient-owned records, and caregiver-entered observations. The defining feature is patient-side generation and sharing. That makes PGHD different from EHR data generated by clinicians, claims data generated by billing transactions, and registry data generated by protocolized data abstraction.

For an analyst, the central estimand question is whether PGHD is being used as an exposure, outcome, covariate, adherence measure, safety signal, or feasibility screen. The same stream can support one use and fail another. A patient-entered daily inhaler log may be useful for identifying non-adherence patterns in a pragmatic trial, weak as proof of drug exposure, and dangerous as a primary safety endpoint if sicker patients stop logging symptoms. Fitness for use depends on the measurement protocol, data completeness, representativeness of contributors, device/app versioning, and whether the stream can be linked to EHR, claims, registry, or mortality data.

Pros, cons, and trade-offs

- vs EHR: PGHD captures between-visit information and home context that the EHR misses, including symptoms, function, home vitals, and treatment experience. Cost: EHR has a clinical workflow, authenticated users, and source documentation; PGHD has variable device quality, user behavior, and completeness. Prefer PGHD when the question hinges on home burden or between-visit trajectories; prefer EHR when clinician-adjudicated diagnoses, labs, or encounter-anchored care are decisive. - vs claims: Claims provide a defined enrollment denominator and paid utilization, dispensing, and cost. PGHD provides direct patient experience and home measurements but usually lacks a clean denominator and is prone to opt-in selection. Prefer claims for incidence, utilization, and adherence based on fills; prefer PGHD for symptoms, function, and daily burden. - vs PRO-only collection: Standardized PROs offer validated scoring and interpretation. Broader PGHD can include contextual and physiologic signals around the PRO, but unstructured or non-validated entries are harder to compare across patients. Prefer a validated PRO instrument when the endpoint is patient-reported benefit; use broader PGHD as context or exploratory evidence unless the measure has been validated. - vs wearable-device-generated data: Wearables can automate dense sensor capture. Manual PGHD can capture intention, experience, reasons for non-adherence, and symptoms that sensors cannot infer. Prefer wearables for continuous objective movement or physiology; prefer manual PGHD when the construct is subjective, contextual, or caregiver-observed.

When to use

Use PGHD when a study needs information that routine data do not capture: symptom flares between visits, home blood pressure or glucose control, patient function, home oxygen or spirometry, over-the-counter and sample-medication use, treatment tolerability, falls, patient preference, adherence barriers, or caregiver observations. It is especially useful in pragmatic trials, decentralized studies, registries, postmarket surveillance, and hybrid EHR/claims studies where PGHD fills a specific relevance gap identified in a fit-for-purpose assessment.

When NOT to use - and when it is actively misleading

Do not use PGHD as if it were passively complete. Non-submission is usually informative: people stop entering data because they feel better, feel worse, lose access, become hospitalized, change phones, or disengage. Do not treat patient-entered medication use as a verified dispensing or administration record without claims, pharmacy, device, or EHR confirmation. Do not use consumer-device or manual-entry measurements as a regulatory-grade endpoint without a measurement protocol, device validation, training, audit trail, and missingness plan. Do not estimate incidence or population prevalence from an opt-in PGHD cohort without a defensible source population and selection adjustment. It is actively misleading to report "no symptom worsening" when the worsening patients are the ones who stopped submitting symptom data.

Data-source operational depth

- Portal or app manual entry: Rich for symptoms, medication experience, OTC use, and patient preference. Failure modes are recall error, duplicate entries, backfilled dates, language/digital-access selection, and response fatigue. Require explicit windows, one-record-per-person-window collapse rules, and completion funnels by demographic subgroup. - Home measurement devices: Blood pressure cuffs, glucometers, pulse oximeters, scales, and spirometers can capture clinically interpretable values if the device is validated and the protocol is standardized. Failure modes include calibration drift, wrong cuff size, family-member use, timezone errors, and selective measurement after symptoms. - Caregiver-entered PGHD: Essential in pediatrics, dementia, frailty, and disability, but the reporter changes the construct. Keep reporter identity and role as variables; do not pool patient and caregiver reports without sensitivity checks. - Linked PGHD + EHR/claims: The strongest substrate. Claims provide denominator, fills, utilization, and death/coverage censoring; EHR provides severity and clinical context; PGHD supplies between-visit experience. The cost is linkage selection and date reconciliation across patient-entered timestamps, EHR encounter dates, and claim service dates.

Worked example

Question: after initiating a new antihypertensive, what share of patients have controlled home blood pressure at 90 days in a claims-linked portal program? (1) Time zero: first pharmacy claim for the antihypertensive, not the date the patient joined the portal. (2) Eligible PGHD source: patient-owned or study-provided blood pressure cuff documented as validated; require training completion and device ID. (3) Baseline window: home systolic/diastolic values from index_date -14 to index_date +7; if multiple values exist, average valid readings after excluding physiologically impossible values and same-minute duplicates. (4) Follow-up window: day 90 +/-14 days; require at least three valid readings on at least two different days. (5) Outcome: controlled home BP = mean systolic <135 and mean diastolic <85 in the follow-up window. (6) Missingness: report the full funnel from eligible claims cohort to invited, activated, baseline-submitted, and day-90-submitted; classify missing day-90 PGHD using linked claims and EHR as hospitalized, disenrolled, died, no portal activity, or unexplained. (7) Analysis: treat complete-case control as descriptive; use inverse-probability-of-response or multiple imputation for population-level estimates, and run a sensitivity analysis that assumes non-responders have worse BP control.

Worked example

Scenario

A claims-linked hypertension program asks patients to submit home blood pressure readings through a portal after starting a new antihypertensive. The analyst needs a 90-day home-control endpoint without pretending that every missing portal submission means good control.

Dataset

Simplified home blood pressure PGHD after treatment initiation.

Steps

• Anchor follow-up to the claims fill date, not to the first portal reading.

• Keep only readings from validated devices or pre-specified acceptable manual-entry sources.

• Build the 90-day window as index_date +90 days +/-14 days.

• Require multiple valid readings on different days before calling blood pressure controlled.

• Treat P003's missing PGHD as informative because linked claims show hospitalization near the window.

Result

P001 has a valid 90-day home BP average of 131/80 and is controlled. P002 fails device validation and should not be used for the endpoint without a sensitivity analysis. P003 is missing informatively and must stay in the completion funnel rather than being treated as controlled or event-free.

Runnable example

import pandas as pd

WINDOW_DAY = 90
WINDOW = 14

def day90_home_bp_endpoint(readings, index, status):
    df = readings.merge(index, on="person_id", how="inner")
    df["reading_date"] = pd.to_datetime(df["reading_datetime"]).dt.date
    df["days_from_index"] = (pd.to_datetime(df["reading_datetime"]).dt.normalize()
                             - pd.to_datetime(df["index_date"])).dt.days

    valid = df[
        df["device_validated"]
        & df["systolic"].between(70, 250)
        & df["diastolic"].between(40, 150)
        & df["days_from_index"].between(WINDOW_DAY - WINDOW, WINDOW_DAY + WINDOW)
    ].drop_duplicates(["person_id", "reading_datetime", "systolic", "diastolic"])

    summary = (valid.groupby("person_id")
                    .agg(n_readings=("systolic", "size"),
                         n_days=("reading_date", "nunique"),
                         mean_sbp=("systolic", "mean"),
                         mean_dbp=("diastolic", "mean"))
                    .reset_index())
    summary["valid_endpoint"] = (summary["n_readings"] >= 3) & (summary["n_days"] >= 2)
    summary["home_bp_controlled"] = (
        summary["valid_endpoint"] & (summary["mean_sbp"] < 135) & (summary["mean_dbp"] < 85)
    )

    funnel = (index[["person_id"]]
              .merge(status, on="person_id", how="left")
              .merge(summary, on="person_id", how="left"))
    funnel["valid_endpoint"] = funnel["valid_endpoint"].fillna(False)
    funnel["home_bp_controlled"] = funnel["home_bp_controlled"].fillna(False)
    return funnel