From a Screenshot to a Structured Report: Integrating Patient-Generated Continuous Glucose Data Into the Electronic Health Record
Student Name
Master of Science in Nursing Program, Aspen University
N538: Advanced Health Care Informatics
Instructor Name
Month Day, Year
From a Screenshot to a Structured Report: Integrating Patient-Generated Continuous Glucose Data Into the Electronic Health Record
At the adult diabetes clinic of a composite community health system, about 600 patients now wear continuous glucose monitors, sensors that read interstitial glucose every few minutes and send the values to a phone app. The data are rich, but they rarely reach the record. Patients arrive with screenshots, forward emailed reports that land in a scanned-document folder, or forget their phones. The diabetes nurse educators spend part of each visit logging into the manufacturer's web portal, and between visits nobody reviews the data at all unless the patient calls.
Continuous glucose data are an example of patient-generated health data: clinically relevant information captured by patients outside the traditional care setting. Bringing such data into the electronic health record is an integration problem with technical, workflow and professional dimensions. This paper describes the problem, reviews what is known about integrating patient-generated data, examines a proof of concept for continuous glucose data, and proposes a design and implementation plan for the clinic, with attention to the nurse's role.
Why Continuous Glucose Data Matter Clinically
Continuous monitoring changed how diabetes control is judged. An international consensus defined standard metrics for reading the data, including time in range, the percentage of readings between 70 and 180 mg/dL, with a target above 70% for most adults with type 1 or type 2 diabetes, and time below range, with a target of less than 4% of readings below 70 mg/dL (Battelino et al., 2019). These metrics show patterns that a hemoglobin A1c cannot: a patient with an acceptable A1c may be spending hours each night below range. A clinician who cannot see the data cannot act on those patterns, and a record that holds only a screenshot cannot show trends, trigger alerts or support population reports.
What Is Known About Integrating Patient-Generated Data
The field is young. In a scoping review that screened 9,463 abstracts, Tiase et al. (2020) found only 19 studies describing complete, partial or in-progress integration of patient-generated data into electronic health records, most of them pilots published between 2013 and 2019. Biometric and activity data made up 57.9% of the data types, and diabetes was the most common condition, at 42.1% of studies. The authors grouped the lessons into three steps of data flow, from capture by the patient to delivery into the record to review by clinicians, and found recurring themes about the resources required, how data should be delivered to the record and how clinicians preferred to review them. They concluded that integration was at an early stage and that resources, delivery standards and clinical workflow all needed attention.
That conclusion matches the clinic's experience. The technical connection is only one step. Someone must decide which data enter the record, in what form, who reviews them and how quickly, and what happens when a pattern is dangerous.
A Proof of Concept for Continuous Glucose Data
One pediatric endocrinology program showed that direct integration is feasible. Espinoza et al. (2020) described a partnership between the hospital's information technology department, its diabetes clinicians and a monitor manufacturer that used Health Level Seven messaging standards to link patient accounts and bring data into the record without a third-party platform. Linking and data requests both used the record's standard order entry interface, data arrived in real time, and customized reports appeared in the results section of the record, available with or without the patient present. The authors noted that documented capture and review of the data could also support billing for remote interpretation.
The design choices in that project answer several of the clinic's problems. Using the order interface means a clinician or nurse deliberately starts the data flow for a specific patient, with consent, rather than every patient's data flowing automatically. Filing a summary report in the results section means the data appear where clinicians already look for laboratory values, instead of in a scanned-document folder. And real-time availability makes review between visits possible.
Design for the Clinic
The clinic's integration should follow four design rules. First, the record should receive a summary, not every reading. A standardized report of time in range, time below range, mean glucose, glucose variability and an ambulatory glucose profile over 14 days is what clinicians need; thousands of raw values in a flowsheet would bury them. Second, the data should be labeled as patient-generated, with the device and the date range, so that no one mistakes them for a laboratory result. Third, patients should enroll deliberately, through an order placed after a conversation about what the clinic will and will not monitor. Fourth, the design must answer the question of responsibility: once the data arrive, who looks at them, and when?
The fourth rule is where nursing matters most. The clinic proposes that its diabetes nurse educators review a worklist of enrolled patients every two weeks, flagging those whose time below range exceeds 4% or whose time in range has fallen by ten percentage points, and contacting them under existing protocols. Patients will be told plainly that the data are reviewed on that schedule and are not monitored continuously, so they do not wait for a call during a low glucose episode.
Implementation and Evaluation
Implementation will require the manufacturer's integration agreement, an interface build and testing by the analysts, a report template agreed by the endocrinologists and nurse educators, and a consent and enrollment script for patients. A pilot with 100 patients over four months will test the workflow before enrollment opens to all monitor users. Evaluation will track the percentage of enrolled patients with a report in the record before each visit, the time nurse educators spend per visit retrieving data, the number of between-visit contacts triggered by the worklist and the change in average time in range and time below range for enrolled patients over six months. A reasonable target is that 90% of enrolled patients have a current report at each visit and that data retrieval time falls by at least ten minutes per visit.
Conclusion
Continuous glucose monitors produce some of the most useful patient-generated data in medicine, but data that arrive as screenshots and portal logins cannot guide care between visits or inform population management. The evidence shows that integration of patient-generated data is still early and depends as much on workflow as on technology, and a proof of concept shows that direct, standards-based integration is achievable. For the composite clinic, the plan is to bring in summaries rather than raw readings, label them clearly, enroll patients deliberately and give nurse educators a defined review role. Integration succeeds when someone owns the data after they arrive, and in this clinic that someone is a nurse.
References
Battelino, T., Danne, T., Bergenstal, R. M., Amiel, S. A., Beck, R., Biester, T., Bosi, E., Buckingham, B. A., Cefalu, W. T., Close, K. L., Cobelli, C., Dassau, E., DeVries, J. H., Donaghue, K. C., Dovc, K., Doyle, F. J., Garg, S., Grunberger, G., Heller, S., ... Phillip, M. (2019). Clinical targets for continuous glucose monitoring data interpretation: Recommendations from the international consensus on time in range. Diabetes Care, 42(8), 1593-1603. https://doi.org/10.2337/dci19-0028
Espinoza, J., Shah, P., & Raymond, J. (2020). Integrating continuous glucose monitor data directly into the electronic health record: Proof of concept. Diabetes Technology & Therapeutics, 22(8), 570-576. https://doi.org/10.1089/dia.2019.0377
Tiase, V. L., Hull, W., McFarland, M. M., Sward, K. A., Del Fiol, G., Staes, C., Weir, C., & Cummins, M. R. (2020). Patient-generated health data and electronic health record integration: A scoping review. JAMIA Open, 3(4), 619-627. https://doi.org/10.1093/jamiaopen/ooaa052
How this N 538 Module 3 example is structured
Aspen does not publish N538 module prompts, so check your classroom for the exact instructions. This example opens with a data-flow problem, establishes the clinical value of the data, reviews the evidence on integrating patient-generated data, draws design principles from a proof of concept, sets four design rules including who reviews the data, and closes with a pilot and evaluation plan.
N538 Module 3 questions, answered
What does N538 Module 3 usually ask for?
N538 treats integration as one of its core informatics problems, and a module paper that takes one data source or device and analyzes what bringing it into the EHR involves is a typical shape. Your classroom prompt sets the exact focus and length.
What are patient-generated health data?
Clinically relevant data that patients capture outside the traditional care setting, such as glucose monitor readings, home blood pressure, activity tracker data and symptom questionnaires completed at home.
Should every reading from a patient device go into the EHR?
Usually not. Clinicians need summaries and patterns, such as time in range over 14 days, and the record should label the data as patient-generated. Raw readings can be kept in the device platform and linked if needed.
Write yours, or have the desk draft it
This paper is an original model document written by our desk, not a submitted student paper and not an official Aspen University document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.