Keywords
patient-generated data - mHealth - atrial fibrillation - patient–provider portal
Background and Significance
Background and Significance
Across the health care ecosystem, organizational governance is shifting to allow incorporation of patient-generated data into electronic health records (EHRs).[1] This is driven by several factors, including a cultural shift that places increased importance upon patient autonomy. For example, the OpenNotes movement has encouraged the use of Shared Notes, or progress notes in which documentation is a duty shared by patients and providers.[2] Beyond this cultural change, technological drivers also underlie growing use of patient-generated data. These drivers include the increasing use of patient portals,[3]
[4] a vision that big data including nonclinical data elements will enable improvements in early detection and treatment of disease,[5] and the increasing use of consumer-directed devices that measure health-relevant data points like heart rate.[6]
Notably, many investigators are working to identify irregular heart rhythms using portable devices that track heart rate and electrocardiogram (ECG) data, based on the idea that early detection would allow for treatment that could lessen morbidity or mortality.[7] Results, whether raw ECG data, pictures of ECGs, or just patient reports or interpretations of ECGs and heart rates, will be reported by patients to their providers, and in some cases, uploaded to EHRs via existing patient portals.
This represents a major break from past practice. Traditionally, clinicians have served as gatekeepers determining which tests should be ordered and which clinical information should be incorporated in the medical record. In the era of paper medical records, many physicians saw themselves as both the primary stewards and decision makers for their patient's medical records.
There is a long tradition in clinical medicine of asking patients to bring symptom diaries or test data (e.g., blood sugar logs and blood pressure measurements) to their appointments.[8]
[9] Most clinicians have been overwhelmed at one time or another by the amount or granularity of information presented by an eager patient. Nonetheless, the extent to which this information was incorporated into a patient's medical record remained dependent upon the clinician seeing a patient at a given visit. We use the term patient-initiated data (PAIDA) to refer to clinical data, or data with potential clinical relevance that may be introduced into the EHR by a patient without the cooperation or even knowledge of any clinician.
In 2015, our organization began inviting patients to sync personal fitness tracker and other consumer-directed health devices to automatically upload personal health data into our EHR. We initially sought to develop a protocol to address millions of unreviewed heart rates, with a goal of balancing the potential benefits of allowing patients to address clinically concerning heart rates with the potential risks of breaching the confidentiality of patients who had not requested review. Furthermore, we sought to generalize this protocol into a governance framework to help guide future efforts, especially for cases with large amounts of data and where abnormal values could represent concerning but treatable pathology.
Methods
Setting and Population
This project utilized CS-Link, Cedars-Sinai Health System's (CSHS) branding of the EpicCare enterprise EHR product (Epic Systems Corporation, Verona, Wisconsin, United States). CS-Link is used at Cedars-Sinai Medical Center, a large, nonprofit hospital and at many local associated provider organizations both within and outside CSHS. These organizations provide multidisciplinary care across the care continuum to a socioeconomically diverse population.
Informatics Intervention
To advance organizational goals of engaging patients via our patient portal, we began inviting patients to sync personal fitness tracker and other consumer-directed health devices to CS-Link on April 25, 2015. In our prior publication describing this initiative, we reported on the demographics and other characteristics of the earliest adopters, who were more likely than nonadopters to be younger, male, white, and health system employees.[10] As of July 3, 2019, 7,128 patients had synced 7,584 distinct devices (users may sync more than one device), and approximately 175 more devices are synced monthly. Once devices are synced, they automatically upload data into the EHR daily. Our interfaces initially only supported heart rate data from Apple HealthKit software framework, which was coming almost entirely from Apple Watches. Apple Watches usually reported one heart rate reading in every 10 seconds while users were wearing the watch, although there were periods triggered by exercise or user setting changes that increased reading frequency to once per second. This data element differed from other data elements in that readings could not only be concerning (as opposed to steps), but also in that the passive and continuous data collection mechanism generated enormous volumes of data.
Initial Physician Informaticist Response
Within months of the project go-live date, the physician informaticist leading the team implementing the health device (HD) linking project noticed that HDs were at times recording heart rates over 200 beats per minute, including among older patients. Anecdotal experiences of a few such cases indicated that neither sophisticated patients nor their providers were generally aware of this abnormal data, even though it was available in the EHR with other vital signs, stored as flowsheet data. Although this was predominantly because providers are accustomed to reacting to tests that they have ordered, it was also at least partially due to a lack of user interfaces designed for easy access to and visualization of this data. After further discussion, in June 2016, the Cedars-Sinai physician informaticist team determined that they should further explore these HD-reported abnormal heart rates as a quality improvement initiative. The goal was to determine whether they might reveal pathology that could be amenable to treatment, or whether such rates might only represent device error, user error, or physiologic variation. Furthermore, there were questions regarding whether patients and physicians were aware of this abnormal data, and whether they would want to be notified about it.
Initial Data Review Process
To begin aggregating clinically concerning heart rates, we initially extracted all HD heart rates below 40 and over 200. These and other cut-offs were based on the clinical experience of the physician informaticist team and were refined over time based on accumulating experience. We first analyzed this data in a deidentified manner, linking the heart rates only to patient age and sex. This was based on the idea that these variables could improve our pretest estimate of the likelihood of having an arrhythmia, but that they would not allow for identification of patients. We subsequently focused our evaluation of patients with low heart rates on those with age over 65 years and multiple heart rates below 39 years at least hours apart. For high heart rates, we isolated patients over 55 years old and ranked all recorded heart rates as a percentage of predicted maximal heart rate, as determined by a previously described sex-specific formula.[11] For each patient, we made a histogram of all recorded heart rates to check for bimodal distributions that we hypothesized of indicating an arrhythmia. To further minimize confidentiality risk, we focused our initial efforts on a few patients with the most potentially concerning heart rates. In these cases, if searching by medical record number revealed the name of a patient who had any nonclinical relationship with the authors, we did not open their chart. Once patients with potentially concerning heart rates were identified, we convened a group of clinical informaticists, including a cardiologist, to discuss each case. In cases with concern for pathology, a subset of physician informaticists reviewed the patient's chart. In a narrower subset of cases where we felt it was warranted, the cardiologist contacted patients' physicians to alert them of our findings. Prior to submitting this report for publication, we obtained approval from the Cedars-Sinai Institutional Review Board.
Results
Details of Initial Physician Informaticist Findings
When we began this process in June 2016, there were 1,738 users with linked devices, including 591 uploading HD heart rates. Of 591 patients with over 6 million uploaded HD heart rates, our data extract contained 151 patients with 5,693 heart rates <40. There were 61 patients with 4,444 heart rates >200, although one patient accounted for 3,074 of these rapid heart rates and another patient accounted for 402 others ([Fig. 1]). These patients also had heart rates recorded during consecutive seconds. Otherwise, recording frequency varied in a way that we could not easily understand. Histograms revealed no bimodal distributions clearly suggestive of tachyarrhythmia, but one histogram had three pronounced peaks in the 50s, 130s, and 180s. After applying the aforementioned criteria and convening our group of informaticists, we excluded the four patients with thousands of abnormal heart rates (attributed to artifact because the frequency of abnormality was substantially higher than any other patients, including those found to have known arrhythmia) and determined that six patients' EHRs should be examined to determine whether the recorded heart rates represented pathology warranting further evaluation. The six patients were those who met the aforementioned low heart rate criteria, and those with the highest heart rates in the aforementioned rankings. More detail for each of these six patients is shown in [Table 1]. Two of these patients' physicians were contacted, but in neither case did the information affect patient outcomes. In one case, low heart rates were found to have preceded death by a few days. Chart review suggested that the cause of death was likely sepsis, rather than a primary cardiac pathology. Nonetheless, physician informaticists speculated that the patient might have had a better clinical outcome if this illness had been identified and treated earlier. However, such identification would require near real-time monitoring, rather than retrospective review at monthly meetings.
Table 1
Abnormal heart rate data with accompanying clinical history, informaticist group decision, and subsequent outcome
|
High heart rates (HRs): age > 55 years and highest outliers on (recorded HR/sex-adjusted predicted maximal HR)
|
|
HR data
|
Clinical history obtained via review of EHR
|
Informaticist group decision and subsequent outcome
|
|
37,901 HRs, mean 85, median 83, standard deviation 18, 17 (0.04%) HRs >200
|
History of palpitations. Prior Holter showed maximum HR in 130s
|
Patient's cardiologist contacted, who was grateful. Zio patch ordered, which showed maximum HR of 136. No further action taken
|
|
81,816 HRs, mean 101, median 95, standard deviation 28, 0.6% HRs >200
|
History of anxiety
|
Differential diagnosis: anxiety vs exercise vs device error. Decision not to contact providers
|
|
28,769 HRs, mean 134, median 101, standard deviation 47, 110 (0.4%) HRs >200. Histogram with pronounced peaks in 50s, 130s, and 180s
|
No relevant symptoms or history
|
Multipeaked histogram due to targeting heart zones during exercise? Decision not to contact providers
|
|
Low HRs: age > 65 years and multiple HRs <39 at least hours apart
|
|
HR data
|
Clinical history obtained via review of EHR
|
Informaticist group decision and subsequent outcome
|
|
10 HRs <40 during waking hours, mostly over 2 weeks
|
Known sick sinus syndrome, but without permanent pacemaker. Prior Holter showed minimum HR of 48
|
Patient's cardiologist contacted, who was grateful and discussed the low HRs with the patient. Patient felt that watch HRs were sometimes inaccurate. No further workup ordered
|
|
2 HRs <40 over a 5-day period (all tracked HRs over a 5-day period, several low)
|
Patient admitted to hospital soon after low HRs initially detected on personal fitness tracker device (unknown if patient/family aware). Inpatient vitals tracked with uploaded HRs. Patient decompensated while hospitalized, later admitted to hospice before expiring
|
Patient deceased. Informaticists suspect that the personal fitness tracker may have been placed on the patient due to clinical suspicion that the patient was declining
|
|
5 HRs <40 over 6 months
|
No relevant symptoms or history
|
Decision not to contact providers
|
Fig. 1 Scheme for identifying the six patients with the most clinically worrisome abnormal heart rates (HRs).
Revised Physician Informaticist Process
During ensuing months, we refined our protocol. Although we systematized several steps of this process ([Table 2]), we ultimately used clinical gestalt to consider the three major decisions of whether to discuss a patient's deidentified data at our meeting, whether our cardiologist informatician should review protected health information, and whether a patient's physician should be contacted. In each case, the potential benefit of identifying concerning but treatable cardiac pathology was weighed against the risks of false positive results, breaching confidentiality, and unwanted intrusions into physician–patient relationships.
Table 2
Steps taken with anonymous heart rate, age, sex, and step data to determine whether to open a medical chart to get more information
|
1. Using clinical dashboard, restrict dataset to age above 65 years
|
|
2. Rank patients by percentage of abnormal heart rates
|
|
3. If highly ranked patients have been considered before, are there changes in their recorded heart rates that would merit further discussion (e.g. abnormalities worsening in terms of absolute or relative frequency, or in terms of severity)?
|
|
In cases with high heart rates
|
|
1. How high are they compared to the patient's age and sex-adjusted predicted maximal heart rate?
|
|
2. Are there also low heart rates? (more concerning)
|
|
3. When are they occurring? (greater concern during usual sleeping hours and less concern during common exercise hours)
|
|
4. Is the patient's watch also reporting high step numbers consistent with vigorous exercise, especially on days when high heart rates are reported? (less concerning)
|
|
In cases with low heart rates
|
|
1. How many low heart rates are recorded, and how many episodes of low rates are there? (fewer incidents are more suggestive of artifact and thus less concerning)
|
|
2. Are there also high heart rates? (more concerning)
|
|
3. When are they occurring? (less concern during usual sleeping hours)
|
Two physician informaticists met ahead of time to jointly identify patients whose heart rates merited consideration in a monthly meeting of the larger group. In both cases, we reviewed deidentified data including heart rate data provided by HDs with corresponding date and time, gender, age, and other HD data including device names and step counts. We developed a Tableau-based (Tableau Software, Inc., Seattle, Washington, United States) dashboard to visualize data across and within patients. To answer important clinically relevant questions, the homegrown Tableau-based dashboard was refined over several meetings. The dashboard allows for ranking of patients based on their number or percentage of total abnormal or abnormally high or low heart rates over a given time period. It also allows for restricting patients based on age. Once an individual patient is selected, it allows easy visualization when abnormal heart rates occurred across a timeline of dates. Time of day information is available to help understand whether abnormal heart rates occurred during usual waking or sleeping hours. Daily step count can sometimes aid in understanding whether abnormal heart rates might be due to vigorous exercise. In cases where the group determined that a patient's physician should be contacted, the cardiology informaticist did so. The results of such interactions were discussed at subsequent meetings, and in some cases the chart was reviewed again to monitor new developments.
[Fig. 2] shows the dashboard being used to filter out patients younger than 65 years, and is currently ranking them by the number of recorded heart rates below 40 and above 180 over the last 60 days. Review of the histogram of recorded heart rates might initially be concerning, as there are many heart rates above 200, including over 60 of them on 3 days. However, review of the timeline along the bottom of the figure shows that the high heart rates always occurred at the beginning of a recording sequence, probably when the watch was first strapped on. Furthermore, this pattern occurs on most days, although the rates are not usually so high. Our review of charts identified many patients with a similar pattern. We believe, this is due to artifact related to the device having difficult with initial capture, and this patient's physician was thus not contacted.
Fig. 2 Example of abnormal heart rate patterns due to artifact.
[Fig. 3] shows a 43-year-old male who is highlighted as an example of abnormally high heart rates likely attributable to exercise. Although we initially looked for second peaks of high heart rates in the histogram because we hypothesized that they might represent arrhythmia, there are several reassuring factors in this case. First, the younger age makes pathologic arrhythmia less likely. Although we initially focused on patients across a wider age range, we later filtered out patients less than 65 years old. Second, the patient has a relatively high step count, as represented by the blue diamonds with the step count next to them. Finally, the high heart rates are occurring only in the early mornings (time of day is viewable only by hovering), a common time for exercise. Our experience with reviewing many similar charts is that this pattern is most likely due to exercise, and this patient's physician was thus not contacted.
Fig. 3 Example of abnormal heart rate patterns due to exercise.
[Fig. 4] shows a 63-year-old male with 1.75% of heart rates above 180. The second peak is seen again, and there are many heart rates reported even over 200. High heart rates are not limited to a certain time of day, and occurred almost every day. In this case, chart review revealed a relevant history of hyperlipidemia. The clinical informaticists determined that the risk of a treatable arrhythmia was sufficiently high to warrant contacting the patient's physician. The patient's physician discussed the abnormal results with the patient, but the patient elected not to pursue further workup. Over a year later, the watch itself alerted the patient of a possible diagnosis of atrial fibrillation, and physician consultation was advised. A Zio patch was subsequently placed and it confirmed a diagnosis of paroxysmal atrial fibrillation.
Fig. 4 Example of abnormal heart rate patterns due to atrial fibrillation.
Overview of Later Findings
By the final 6 months of review, our protocol was better established. During that time, the two physician informaticists charged with screening selected 38 cases representing 22 unique patients for discussion at five larger meetings occurring between July 20, 2017 and January 2, 2018. Because the number of synced Apple Watches increased from 2,197 to 2,927 during this time period, this represented approximately 0.75% of patients. A higher threshold was used to warrant repeat discussions of the same patient, and was dependent upon the outcome of the first discussion. Twenty-two cases representing 13 unique patients were selected for discussion based at least in part on three or more heart rates of 40 or lower. Nineteen cases representing 11 unique patients were selected for discussion based at least in part of 13 or more heart rates of 185 or higher. Six cases representing four patients met both criteria. In 14 cases representing 11 unique patients, a committee decision was made that charts should be opened for review of further data by a cardiologist informatician. In three of these cases, chart review raised sufficient concern that a decision was made to contact a patient's physician.
In nearly all cases when physicians were contacted (including several cases from before the final 6 months of analysis), physicians had not been previously aware of the abnormal HD-recorded heart rates, even though this data were accessible through our EHR. In no cases were physicians upset to learn that they not involved in their patients' care had accessed and reviewed their chart, but they were frequently surprised about the existence of this data. One physician expressed vague recollection that patients were able to upload such data. The physicians were also skeptical that abnormal values represented pathology.
In general, the cases identified remained clinically similar to the cases in [Table 1]. The most common presumptive causative pathology identified by chart review based on abnormal heart rates was atrial fibrillation. Although our methodology successfully identified five cases of known atrial fibrillation, we are unaware of any cases where our HD data resulted in a new diagnosis of atrial fibrillation, or of any case where HD data improved any patient outcome, other than possibly the case in [Fig. 4]. Based on this experience, the physician informaticist team determined that our EHR could continue to offer this functionality, which might be used by patients seeking to track heart rate data for themselves or their physicians, without routine oversight, and without unreasonable safety or liability concerns. For this reason, proactive reviews of abnormal HD data were halted in February 2018. Using the knowledge gained from this experience, we are working to develop and validate an algorithm that would combine HD device data with clinical data in the EHR to identify patients at sufficient risk for arrhythmia and other disease that further workup would be indicated.
Discussion
In this report, we describe our experience with enabling patients to sync their HDs to our EHR, allowing for nearly passive and continual collection and incorporation of heart rate data into their medical records. Within weeks of offering this functionality, several hundred patients synced their devices. Although this represents only a small proportion of our patient population, HDs' passive and continuous sensing quickly led to millions of new data points, including many outside the normal range.
In the traditional paradigm of test ordering, clinicians have been responsible for determining when the pretest probability of a condition exceeds a certain threshold, such that it makes sense to investigate further by ordering a test with known receiver operating characteristics. Clinicians have also been trained to only order tests if the results will affect patient care, and to formulate this plan prior to ordering any test. Finally, in ordering any test, the clinician accepts responsibility for following-up on the test result.
It was this sense of responsibility that compelled our physician informaticist team to follow-up on the abnormal heart rates described here. Viewed only from that perspective, the project did not identify any abnormal heart rates that ultimately led to improved health outcomes, with one possible exception. Furthermore, we feel reassured that allowing heart rate and the other currently supported PAIDA in our EHR is a reasonable way to allow patients to track these data elements over time, and to share them with their providers. Nonetheless, we believe this to be a function of several modifiable characteristics (e.g., the generally good health status of the patient populations with synced HDs, the relatively small size of this population). We expect that not only will PAIDA increasingly populate EHRs, but also that it will become increasingly useful in managing health. For these reasons, we expect physician informaticists will need to lead the development of strategies to help physicians better access, monitor, and understand the clinical implications of this data.
Perez et al recently shared results from the Apple Heart Study, which also sought to use pulse data from HDs to identify arrhythmias.[7] That study shared similarities with our own, including that patients were self-selected and that neither analysis reached the expected rate of identification of arrhythmias. Differences included our use of the EHR, which meant that patient comorbidities and other risk factors had likely been verified by health care personnel, as opposed to only patient report. To the extent that HD use is shown to benefit health, we expect it to increasingly be incorporated into the EHR.
Limitations and Strengths
Limitations and Strengths
To be sure, our report has several limitations. First, because this project stemmed from a quality improvement initiative that focused only on those patients with abnormal heart rates, we lacked data from other patients. Ideally our protocol would be validated among a population of patients with a sufficiently high pretest probability to justify periodic review. Sensitivity could be assessed by applying our protocol to patients with known arrhythmia.
Despite these limitations, we identified the lessons learned from this project that could help other provider organizations benefit from PAIDA. First, we realized that in the absence of a pretest probability being generated by an ordering provider, one can sometimes be estimated with other data in the EHR, such that the test result can be combined with other data to form a posttest probability. In this case, we initially focused on age, but in some cases, chart reviews provided other valuable context. Second, we had little insight into whether devices were being used correctly, or even by whom they were being worn. This could be at least partially addressed with a patient–provider–portal compact, whereby patients agree to some responsibilities that come with the privilege of uploading data to an EHR monitored by others. Such compacts already tend to exist, whether implicitly or explicitly, for clinicians with EHR access. These compacts, and other avenues of communication, could help clinicians understand what means patients have for adding PAIDA to the EHR, how this PAIDA can be accessed and visualized, what type of electronic and manual monitoring and data summarization services might be available, and whether responsibilities for monitoring this data fall to patients, physician, informaticists, or others. Third, we experienced challenges in understanding the measurement accuracy and receiver operating characteristics of consumer-directed devices. There is emerging research around wrist-worn heart rate monitors,[12] but we would suggest more generally that companies interested in encouraging the use of their HDs to improve health should also offer more publicly available information about how and how well these devices work, including for different populations and in different circumstances. Finally, and perhaps most at odds with our initial beliefs, we realized that physicians need not always serve as gatekeepers of the medical record. Indeed, review of prior literature in this area shows that others have previously recognized that PAIDA may have multiple use cases, including not only usual clinical care but also patient self-care, which reinforced our acceptance that not all PAIDA will require clinician review.[13] Taken together, our response offers a framework for responding to other types of PAIDA ([Table 3]).
Table 3
A framework to address new patient-initiated data (PAIDA) in the electronic health record, and how we applied it
|
General principle
|
How applied in this case
|
|
1. Identify new PAIDA type that will become available and the typical workflows by which it will populate the electronic health record (EHR), including data collection devices used, if any. Anticipate ramifications of abnormal values
|
1. In this initial case, although we planned to allow patients to sync devices with these data elements, we did not fully realize the implications of abnormal values until after they began getting incorporated into the electronic health record
|
|
2. Consider whether any organizational information about the patient–provider–portal requires modification. Consider creating or modifying an explicit patient–provider–portal compact to address this data type (e.g. agreement to only take a patient's own measurements with a device linked for continuous uploading)
|
2. Our patient portal website explains that this information may not be routinely monitored by patients' physicians. We expect that more detailed patient–provider–portal compacts to be developed at all sites
|
|
3. Convene group of clinical informaticists to gather information regarding and to discuss the affected patient population, relevant providers, patient and provider awareness regarding abnormal data, data accuracy, clinical implications
|
3. This was begun approximately one year after the technical capability was launched. This team included one informaticist with technical experience in building the interface and one cardiology informaticist
|
|
4. Consider how other data in the EHR might be leveraged as context to better understand what data might represent treatable pathology, and whether such data might be best incorporated into decision making via mathematical modeling or data visualization
|
4. We used age, sex, steps, and time of day to help estimate a pre-test probability for pathologic arrhythmia for each patient with abnormal heart rates
|
|
5. Consider potential adverse consequences of informaticist monitoring, including entering charts without explicit patient or provider permission, and the risks of false positive results
|
5. We developed a three-stage protocol that started with looking at coded data and was followed by each of two subsequent steps (having a cardiologist informatician enter patients' record, and contacting patients' physicians) only when clinical concern warranted it
|
|
6. Iteratively refine any monitoring efforts with contributions from a team of information technology professionals, clinician informaticists, and relevant clinicians and patients
|
6. After realizing that there was some artifact, we stopped looking at cases with one low heart rate. For high heart rates, we began looking for non-pathologic patterns that might explain them (e.g. high heart rates every morning or afternoon, especially in patients whose devices were reporting a very high rate of daily steps, suggesting exercise)
|
From the standpoint of usual clinical care, the lack of physician awareness of the PAIDA discussed in our study highlights a challenge to its clinical use. Because physicians cannot continuously monitor data feeds of many patients, clinical use of this data would require a system of computer and/or human processing to provide clinicians with summarized results, with subsequent socialization efforts to gain physician buy-in. We appreciate that in the long run, most PAIDA will be continuously consumed by algorithms that alert physicians or trigger other actions when necessary. However, there will also be ongoing development of new data elements and new measurement devices that may need to be considered for manual monitoring by informaticists prior to the development of monitoring algorithms. Experience gained with manual monitoring may also identify common patterns of artifact and shape algorithm development. Our experience provides insight into the challenges associated with the introduction of PAIDA into patients' medical records.
Conclusion
These lessons extend beyond patient-initiated heart rate data. For example, shared notes represent a type of PAIDA that may include new concerning symptoms (e.g. suicidal ideation and chest pain). Genomic data, which is increasingly available for ordering by both patients and providers, will need periodic monitoring to search for sequences newly found to be pathologic or otherwise actionable. Indeed, to the extent that health care embraces the vision of using big data for earlier detection, prevention, and treatment of disease, we expect myriad nontraditional data sources will require monitoring, summarization, and explicit assignment of responsibility. We hope that the details of our abnormal heart rate dashboard might be useful for others enabling the uploading of patient-initiated heart rate data to the EHR in the near term, and we see even more widespread potential for application of our lessons learned and aforementioned framework in addressing the many new real-world challenges inherent in the use of PAIDA.
Clinical Relevance Statement
Clinical Relevance Statement
In 2015, we began allowing patients to upload data to our EHR without physician orders, which we henceforth call patient-initiated data (PAIDA). We developed (1) a heart rate visualization dashboard to identify concerning heart rates; (2) experience regarding which combinations of heart rates and EHR data were most clinically worrisome, as opposed to representing artifact; (3) a protocol whereby only concerning heart rates would trigger a cardiologist review revealing protected health information; and (4) a generalizable framework for addressing other PAIDA. Our governance framework can help guide future efforts, especially for cases with large amounts of data, and where abnormal values may represent concerning but treatable pathology.
Multiple Choice Questions
Multiple Choice Questions
1. Patient-generated data coming from patient portals, including patient-entered text in shared notes, patient-reported outcomes, and biosensor data is increasingly prevalent. Challenges associated with incorporating this patient-generated data into the electronic health record (EHR) include:
-
Continuously monitoring large numbers of patients' electronic charts to detect abnormal data.
-
Instantly presenting providers with all data generated by each of their patients.
-
Identifying actionable pathology as the cause of each abnormal finding.
-
Making providers responsible for identifying and responding to abnormal patient-generated data.
Correct Answer: The correct answer is option a. In many cases, systems must be put in place to monitor patient-generated data, which differs from most prior EHR data in that physicians haven't initiated data collection (e.g. physician-ordered blood tests). Option b is wrong because instead of instantly presenting providers with all of the data generated by each of their patients, informaticists will need to organize, simplify, and clearly present patient-generated data to the relevant clinicians. Option c is wrong because abnormal findings frequently represent normal variation, user misunderstanding or error, or device error instead of actionable pathology. Option d is wrong because informaticists must work to develop organizational rules regarding whether patients, providers, or information technology departments are responsible for identifying and responding to abnormal patient-generated data.
2. Which of the following represents the best overall strategy for informaticists to process patient-generated data that will be presented to clinicians and their patients?
-
To ensure that patients don't become unnecessarily confused or anxious, informaticists should require clinicians to review and manually release any patient-generated data to their patients.
-
Examining prior patient-generated data for a given patient, and population-based normal ranges to determine whether abnormal values represent a change.
-
Firing alerts to clinicians and patients for each abnormal data point.
-
Organizing and summarizing patient-generated data, and leveraging other electronic health record data to calculate a pretest probability for each test result, such that a posttest probability can be used to understand whether data may represent addressable pathology.
Correct Answer: The correct answer is option a. This strategy doesn't appropriately respect patients' ownership of their health record data, and would almost certainly be met with resistance from clinicians, who could end up with lots of new unreimbursed work. Option b is wrong because although this could be one useful tactic as part of an overall strategy, it is inferior to the overall strategy discussed in D. Option c is wrong because this strategy would overwhelm and frustrate clinicians and patients with false-positive results. Option d is correct because this overall strategy attempts to maximize automation and to minimize any new clinician burden involved in addressing this new data source.
