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.
