For most of the EMR's history, the chart held data the practice produced: notes, orders, results, vitals taken in the exam room. That is changing. Home blood pressure readings, continuous glucose monitor traces, weight from a connected scale, step counts from a wristband, and symptom questionnaires completed on a phone are all arriving in the chart, sometimes daily. Patient-generated health data, usually shortened to PGHD, is one of the fastest-growing categories of information in ambulatory EMRs, and it forces practices to answer a question they never had to before: what do we do with data we did not ask for at a moment we did not choose?
What counts as patient-generated data
The federal health IT office defines PGHD as health-related data created, recorded, or gathered by patients or their caregivers to help address a health concern. In practice it falls into a few groups:
- Device readings from home blood pressure monitors, glucose meters and continuous monitors, pulse oximeters, scales, and spirometers, often transmitted automatically through a cellular or Bluetooth gateway.
- Wearable and consumer app data such as activity, heart rate, sleep, and irregular-rhythm notifications, which patients may share through a portal-connected app.
- Patient-reported outcomes and questionnaires such as depression screens, pain scales, and condition-specific surveys completed before a visit or on a schedule.
- Patient-entered history including medication lists, allergies, and family history submitted through digital intake.
The distinction that matters clinically is between data the practice prescribed (a remote monitoring program with defined thresholds) and data the patient volunteered. The first has an owner and a protocol; the second often does not.
How the data reaches the chart
Three pathways dominate. The first is the EMR's own patient portal, which increasingly supports linking consumer health apps and importing readings as flowsheet rows. The second is a remote patient monitoring vendor whose platform collects device data, applies thresholds, and pushes summaries or discrete values into the EMR through an interface. The third is standards-based app integration using FHIR, where an app writes Observation resources to the record with the patient's authorization.
Each pathway lands data somewhere different. Portal imports usually go to a flowsheet the clinician has to open. Vendor platforms often keep the detailed data on their own dashboard and file only a periodic summary document to the chart, which keeps the EMR clean but splits the record across two systems. FHIR-based writes can populate discrete fields that trend alongside clinic-measured vitals, which is the most useful form but also the most work to configure.
Ask where it lands before you turn it on. A blood pressure reading that files as a scanned PDF is nearly invisible. A reading that files as a discrete vital with a source flag can drive alerts, trend graphs, and quality measures. The difference is in the interface design, not the device.
The review-burden problem
The most common failure with PGHD is not technical. It is that data arrives and nobody has time to look at it. A hypertension program with 200 patients transmitting twice a day generates 400 readings before lunch. If each one lands in a physician's in-basket, the program will collapse within a month, and the practice will have created a record of unreviewed abnormal values, which is both a safety problem and a liability problem.
The practices that make this work treat PGHD like lab results: most readings are normal and need no action, a defined subset triggers a protocol, and only exceptions reach the clinician. That requires three things: thresholds set per patient or per condition, a person or team (often a nurse or medical assistant) who works the exception queue, and documented standing orders for what that person can do without escalating.
Designing the workflow
Start with one condition and one device type. Hypertension with home blood pressure monitoring is the usual entry point because the thresholds are well established and the intervention (medication titration) is familiar.
- Enrollment: define who qualifies, obtain consent for the monitoring program, and document the device and the target ranges in the chart.
- Data routing: configure readings to file as discrete values with a source indicator, and route threshold breaches to a team pool rather than an individual in-basket.
- Triage protocol: write the standing order that says what the nurse does for a mildly elevated reading, a critically elevated reading, and a missing reading, and when the physician is notified.
- Patient communication: set expectations about when readings are reviewed. Patients often assume a transmitted reading is seen instantly; the enrollment materials should say otherwise and tell them when to call or seek emergency care.
- Review cadence: schedule the periodic clinician review of trends, separate from the exception queue, and document it.
For volunteered wearable data with no program behind it, many practices set a policy that the data is available in the chart for reference but is not actively monitored, and they tell patients that. That is a reasonable position as long as it is stated and consistent.
Documentation and billing considerations
Remote physiologic monitoring and remote therapeutic monitoring have their own billing codes with requirements about device type, number of days of data, and time spent in management. The EMR needs to capture the elements those codes require: device supply, transmission days per period, and management time. Vendor platforms typically produce a monthly report designed for this purpose; if you build the program on native EMR tools, plan how those elements will be tracked. Regardless of billing, the clinical record should show that abnormal values were reviewed and what was done, which is why routing everything through a documented protocol matters.
Note also that once PGHD is incorporated into the designated record set, it is part of the patient's record for access and amendment purposes, and it is electronic health information subject to the information blocking rules. Data you accepted into the chart has to be treated like data you created.
Where this is heading
Several developments are converging. Certified EMRs are expanding standards-based APIs that allow patients to write data to the record, not only read from it. The federal data standard that defines the minimum content certified systems must support has added elements for patient-reported data, and later versions continue to expand. Device manufacturers are increasingly shipping cellular-connected models that need no phone pairing, which removes the biggest barrier for older patients. And payers are broadening coverage for monitoring programs in chronic disease, which gives practices a financial reason to build the infrastructure.
The net effect is that the EMR is becoming a continuous record rather than an episodic one. Practices that build the triage and review workflows now will be able to absorb the volume. Those that simply switch on the data feeds will be buried by it.
Common questions
Are we obligated to review every reading a patient sends?
There is no single rule, but once data is accepted into the record, unreviewed abnormal values are a clinical and legal risk. The safer approach is a documented protocol that defines what is monitored, by whom, on what schedule, and what is stored for reference only, and telling patients which is which.
Should wearable data from consumer devices go into the chart at all?
It can, with a clear policy. Many practices accept it as reference data that is not actively monitored and say so during enrollment, while running formal monitoring only for prescribed devices with defined thresholds.
What is the difference between remote patient monitoring and PGHD?
PGHD is the broad category of any health data a patient generates. Remote patient monitoring is a structured program using specific devices, thresholds, and clinical management, and it has its own billing codes and requirements.
Does a remote monitoring vendor need a business associate agreement?
Yes. The vendor collects, stores, and transmits protected health information on the practice's behalf, so a signed agreement is required before the program starts.