Keywords
clinical decision support - interoperability standards - patient-generated health
data
Background and Significance
Background and Significance
Apps external to the electronic health record (EHR) that seek to engage patients and
collect patient-generated health data (PGHD) are increasingly used during care delivery,
including in remote patient monitoring (RPM).[1]
[2]
[3]
[4] These apps must be tightly integrated with the EHR system used by clinicians to
enable them to make care decisions informed by the full set of data: those recorded
clinically in the EHR and those contributed by patients via apps. However, these apps
are often not integrated with the EHR for multiple reasons including deficient standards
for data exchange and lack of syntactic and semantic interoperability. The lack of
integration can lead to an increased workload for the clinician,[5]
[6]
[7]
[8] duplicate data entries, and insufficiently informed decisions. For example, in coronavirus
disease 2019 (COVID-19) monitoring, critical values for oxygen saturation are lower
for patients who have a preexisting respiratory illness such as chronic obstructive
pulmonary disease (COPD). A RPM app that does not integrate with EHRs may inappropriately
alert a clinician about a low oxygen saturation value reported via the app by a patient
who has COPD.[9] The inappropriate alert can lead to inappropriate care, add to clinician's burden,
and result in alert fatigue.[10]
We developed the COVID-19 Tracker application (COVID-19 Tracker) for clinicians to
remotely monitor patients who tested positive for severe acute respiratory syndrome
coronavirus 2 (SARS-CoV-2). A requirement from the intended clinical users of this
application at the initial clinical site was that it must integrate into their existing
EHR-based workflow. Since we wanted to make the application widely available and easy
to integrate with EHRs, we decided to use interoperability standards. The informaticians
(A.B., D.L., and N.K.) chose to use Health Level 7 (HL7)'s Fast Healthcare Interoperability
Resources (FHIR) standard[11] because it provides application programming interfaces (APIs) commonly used in contemporary
software systems. FHIR-based APIs exchange data in the form of objects known as resources.
Prior work by others has described integrating patient apps with EHRs using the HL7
CDA standard.[12]
[13] This case report describes our design for integration using FHIR, the challenges
encountered when implementing this design at the clinical site, and the lessons we
learned. This project was undertaken as part of the Patient-Centered Outcomes Research
Clinical Decision Support: Current State and Future Directions project funded by the
Agency for Healthcare Research and Quality to advance research, development, and implementation
of patient-centered clinical decision support (CDS) solutions.[14]
Context
Below we describe the setting and existing workflow for COVID-19 RPM and the design
and implementation of the COVID-19 Tracker within Yale New Haven Health (YNHH) System's
Epic EHR. YNHH is a large academic health system in New Haven, Connecticut serving
3.6 million ambulatory visits and 150,000 annual hospital discharges. The care setting
involved two existing RPM programs (one for YNHH patients and one for YNHH employees)
employing 15 care coordinators (CCs) primarily responsible for monitoring individuals
with SARS CoV-2 infection from April 2020 through August 2021. Members of the project
team included clinical informaticians, software developers, and information technology
(IT) personnel from YNHH, National Opinion Research Center at the University of Chicago
(NORC), and Elimu Informatics; the implementation effort at YNHH was led by its Associate
Chief Medical Informatics Officer (N.K.). The subject matter expert (SME) group included
leaders of the two CC groups, physicians overseeing the RPM programs, and technology
specialists from Epic.
Beginning in January 2021, the informaticians interviewed the CC staff to understand
the current system function and workflows and desired technology enhancements. The
software developers (led by A.B. and T.R.) used agile development methods for rapid
development, review, and enhancement cycles with the SME team. This project was reviewed
and approved by the Institutional Review Boards at YNHH and NORC.
The COVID-19 Tracker was deployed at YNHH as a technological enhancement in an existing
COVID-19 RPM program. Prior to the COVID-19 Tracker deployment, the RPM worked as
follows: patients who tested positive for SARS-CoV-2 but did not require hospital
admission were referred for RPM via an order placed in the EHR. These patients were
contacted and invited to use a patient portal form to transmit their data to the CCs.
Patients were verbally assented by CCs via phone. Oxygen saturation monitors were
shipped to patients when they were enrolled in the monitoring program. Patients were
asked to submit their symptoms, oxygen saturation level, and heart rate through the
YNHH patient portal every morning. CCs telephoned patients who did not report data
by noon. These data, reported in the portal or obtained on the phone, were entered
in the patient's electronic chart and collated for review in a spreadsheet-style program
report in the EHR. The report displayed multiple patients simultaneously including
newly identified referrals in need of enrollment ([Fig. 1]). Patients who received a referral for monitoring from network clinicians could
be manually added to or deleted from the report by CCs.
Fig. 1 A screenshot of an EHR report from test environment of patients being remotely monitored
for COVID-19. This screenshot is from a test environment with synthetic data. The top of the screen
shows the list of patients being monitored. The bottom field shows detailed data of
the selected patient, including the responses completed in the Patient Tracker app.
© 2022 Epic Systems Corporation. COVID-19, coronavirus disease 2019; EHR, electronic
health record.
This workflow created a burden for the patients and the CCs. More than 60% of the
patients had never used the portal before their COVID-19 diagnosis. Furthermore, the
patient portal did not effectively issue daily reminders to prompt patients to report
their data. Consequently, the CCs called many patients daily. At peak periods of the
pandemic in 2020, 15 CCs were monitoring over 300 patients.
Methods
The informaticians extracted themes, tasks, and challenges from notes from project
meetings and from semistructured discussions among the application development team
to track the design and implementation processes. Below we describe the main steps
in these processes including how we informed our design with the Five Rights of CDS.[15]
Coronavirus Disease 2019 Tracker Application Design
The COVID-19 Tracker's purpose was to enable CCs to monitor the patients more efficiently
and to enable patients to conveniently update the CCs with their data. The clinician
workflow in the EHR was designed around standard EHR capabilities in YNHH Epic instance
(e.g., viewing reports). CCs would identify and contact new patients from the EHR
report and document the patient call as an encounter. Once the patient orally assented
to proceed with the remote monitoring program, the CC would create an “Episode of
Care” in the EHR that would tag all future encounters for this program under this
episode. If the patient agreed to the text-based monitoring program, the CC would
create a different “Episode of Care” which triggered a request from the EHR to a COVID-19
Tracker API that enrolled the patient into the text-based monitoring program. The
application then requested demographics from the EHR to complete the enrollment. Upon
enrollment, patients were sent welcome text messages to their phones via SMS. Patients
subsequently received SMS reminders every morning at 8 am containing an individualized link to a mobile-friendly web app for entering data
([Fig. 2]).
Fig. 2 Screenshot of the COVID-19 Tracker App Component for Patients. COVID-19, coronavirus
disease 2019.
Patients had the option to unenroll from the program at any time by replying “STOP”
in a text message. If patients entered out-of-range values that indicated a possible
deterioration in health (e.g., oxygen saturation <92%) into the component of COVID-19
Tracker used by patients (Patient Tracker app), patients were immediately prompted
to contact their clinician's office. Patient responses in the Patient Tracker app
were filed as PGHD in the EHR. The responses were viewed in the same program report
for the CCs described earlier. Further details of the implementation are described
in the challenges section. [Table 1] describes how this design aimed to align the solution with the Five Rights of CDS.
[Fig. 3] illustrates the data flows between the clinician, CC, patient, Patient Tracker app/phone,
COVID-19 Tracker, and EHR.
Fig. 3 COVID-19 Tracker Data flow and workflow showing the sequence of steps that occurred
during patient enrollment and monitoring. Green boxes indicate manual processes. Orange circles indicate automated processes.
Yellow stars represent points in the workflow where challenges were identified, and
numbers correlate with the challenges listed in [Table 2]. COVID-19, coronavirus disease 2019; EHR, electronic health record.
Table 1
Alignment of COVID-19 Tracker application with the Five Rights of CDS
|
The CDS “right”
|
Patient
|
Care coordinator
|
|
Right person
|
Provides information, receives recommendations
|
Reviews information
|
|
Right information
|
Recommendations based on symptoms
Prompts to contact clinician's office when abnormal values were entered
|
Report of patients being tracked with latest data
|
|
Right format
|
Text messaging for reminders
Light-weight web app for providing information and receiving recommendations
|
Report ability to drill down into single patient
|
|
Right channel
|
Via SMS and mobile browser
|
Within EHR
|
|
Right time in the workflow
|
Every morning
|
CC initiated, on-demand
|
Abbreviations: CDS, clinical decision support; COVID-19, coronavirus disease 2019;
EHR, electronic health record; SMS, Short Message/Messaging Service.
Integration Requirements and Approach
A critical component of integration was maintaining data integrity and security as
would be necessary for all systems handling sensitive data. The informaticians identified
the following points of integration between the application and the EHR based on the
data flows in [Fig. 3]. Further, the informaticians identified potential FHIR APIs that could satisfy these
integration requirements.
Identifying a Patient for Engagement
The COVID-19 Tracker needed to enroll patients who tested positive for SARS-CoV-2
and who were referred for RPM by their clinicians. In other applications where patient
monitoring is needed, patients who are candidates for enrollment could be automatically
identified by the entry of a new diagnosis (e.g., hypertension) or by prescribing
a specific medication (e.g., anticoagulant). For the COVID-19 Tracker, the trigger
for enrollment was an RPM order. In the FHIR standard, this order can be expressed
as a ServiceRequest resource, that is, a record of a request for a procedure or other
service to be performed. To allow an app to request notifications when such events
occur, FHIR provides a Subscription resource, that is, the app can subscribe to be
notified when a ServiceRequest matching its criteria is created in the EHR. The subsequent
push notification from the EHR could allow the COVID-19 Tracker to prompt the CC to
consent and enroll the patient for RPM and indicate the consent in the EHR.
Requesting Enrollment of a Patient
Once RPM consent was documented within the EHR by a CC, the EHR needed to notify the
COVID-19 Tracker to enroll the patient and initiate contact ([Fig. 3], steps F and G). Typically, a patient engagement app would require data from the
EHR to enroll a patient, such as patient demographics, contact information, relevant
clinical data, and parameters for engagement (e.g., when to engage and for how long).
In FHIR, there are no resources or implementation guides for communicating these enrollment
requests to external applications like the COVID-19 Tracker.
Patient Tracker App Retrieves Data from the Electronic Health Record
The COVID-19 Tracker application should customize the frequency of interactions and
follow-ups based on comorbidities and other data from the EHR, including data entered
by the CCs in the EHR report. Many types of clinical data can be obtained from the
EHR via FHIR APIs. The availability of APIs for different FHIR resources in EHR products
is rapidly increasing.
Inform the Patient of Enrollment
The COVID-19 Tracker application had to communicate with patients about their enrollment
(step H). Such notification commonly is done via messages through the patient portal,
emails, or text messages. In FHIR, the CommunicationRequest resource provides the
functionality to send a message to the patient.
Authenticate Patient
To authenticate a patient (during step I) when using the Patient Tracker app, the
COVID-19 Tracker could use the patient's login credentials for the patient portal
and, therefore, not require the patient to maintain an extra set of credentials for
this application. The SMART on FHIR specification that is implemented by the patient
portal allowed such authentication.
Integrating Data into the Clinician Workflow
To minimize disruptions to the CCs' workflow from the use of the COVID-19 Tracker,
the design was to write the patient-reported data into the EHR report used by CCs
for monitoring patients. FHIR provides Observation and QuestionnaireResponse APIs
to write these types of data.
Identifying Critical Values for Clinicians
The COVID-19 Tracker needed to identify critical values for CCs that were individualized
to the patient by including comorbidities, laboratory test results, and medications.
A design option considered was to notify the CCs via a message in their EHR inbox.
In FHIR, the CommunicationRequest resource provides the capability to send notifications.
FHIR's Observation resource also includes a data field for interpretations that can
be used to mark values that are considered critical.
Results
The COVID-19 Tracker was developed to meet the design and workflow requirements described
above and deployed on cloud servers. Cloud deployment reduced the burden on IT staff
at YNHH and positioned the app for rapid deployment to other sites. FHIR APIs enabled
the integration of the application with the EHR at many integration points. However,
the software developers encountered several integration challenges that required the
developers to use alternate integration mechanisms than those described in the previous
section. [Table 2] summarizes these challenges and how the developers and informaticians addressed
them.
Table 2
COVID-19 Tracker application integration challenges
|
No.
|
Capability needed
|
FHIR or other standard
|
Challenge in using the standard
|
Our solution
|
|
1
|
Identify patient for enrollment
|
Subscription resource or Health Level 7 (HL7) v2 message
|
Subscription not implemented by EHR;
HL7 v2 not implemented by the COVID-19 Tracker
|
Used EHR's rule engine
|
|
2
|
Request app to enroll patient
|
None
|
No appropriate standard available
|
Used CDS Hooks
|
|
3
|
Update patient data from EHR to app
|
Patient, Practitioner, and ObservationResources
|
Hospital firewall blocked access from the cloud-hosted application
|
Added exception to firewall
|
|
4
|
Inform patient of their enrollment
|
CommunicationRequest resource
|
Not implemented by EHR
|
Used text message
|
|
5
|
Authenticate patient using the app
|
Substitutable Medical Applications, Reusable Technologies on FHIR
|
Requires patient to have portal account and remember login credentials
|
Sent patient short-lived links to web-based intake form
|
|
6
|
Update patient data from app to EHR
|
QuestionnaireResponse and Observation resources
|
QuestionnaireResponse not implemented by EHR;
Observation partially implemented
|
Used Observation resource with proprietary codes
|
|
7
|
Alert clinician of abnormal values
|
CommunicationRequest resource or interpretation added to Observation
|
Neither implemented by EHR
|
Prompted patients to contact clinician's office when abnormal values were entered
|
Abbreviations: CDS, clinical decision support; COVID-19, coronavirus disease 2019;
EHR, electronic health record; FHIR; Fast Healthcare Interoperability Resources.
Identifying a Patient for Engagement
The FHIR Subscription API was not implemented in the EHR at YNHH. An alternative,
the HL7 version 2 standard, could be used to send the RPM order to the COVID-19 Tracker.
This standard has limitations in its semantics and uses legacy networking protocols,
and therefore, many modern apps, including the COVID-19 Tracker, do not use it. Instead,
the developers used the event-triggering capabilities within the proprietary rule
engine of the EHR to initiate the engagement/enrollment process.
Requesting Enrollment of a Patient
Currently, FHIR does not provide a mechanism for communicating enrollment requests
to external services like the COVID-19 Tracker. The developers integrated the enrollment
request with customized use of CDS Hooks,[16] a specification that can be considered part of FHIR. The CDS Hooks specification
is meant to integrate external CDS services into health IT tools and not intended
for exchanging enrollment requests. They used CDS Hooks out of convenience as it was
a feature available in the YNHH EHR that could be leveraged in the emergent scenario
of the pandemic. The alternative would have required additional custom development
work within the EHR by the YNHH IT staff who were already overburdened with other
activities triggered by the pandemic. The CDS Hooks request (where the hook was patient
view) was triggered automatically by the backend when the CC entered consent and enrollment
information in the EHR. The COVID-19 Tracker API did not send any CDS cards in the
response.
Patient Tracker App Retrieves Data from the Electronic Health Record
The YNHH EHR had FHIR APIs for the COVID-19 Tracker to retrieve the needed data. However,
the developers encountered a hurdle due to network firewalls preventing our cloud-hosted
application from accessing the institution's FHIR APIs. They resolved this issue by
creating exceptions in the institution's firewall to allow the Patient Tracker app
to access the EHR data. This trust in the COVID-19 Tracker was established following
a security design review of the application by YNHH's IT security personnel. This
review is a common approach followed at health care organizations adopting applications
developed by third parties.
Inform the Patient of Enrollment
Neither the EHR nor the patient portal at YNHH had implemented the FHIR CommunicationRequest
API precluding the COVID-19 Tracker from sending the message to the patient using
that mechanism. As an alternative, the COVID-19 Tracker itself sent a text message
to inform the patient of enrollment.
Authenticate Patient
While it was possible for an app to require patients to use their portal credentials
to log in, the challenge is that patients often do not have portal accounts or do
not remember those credentials. In 2020, during the time of this study, only 40% of
the YNHH patients had used the portal.[17] Instead of requiring patients to log in with a username and password, COVID-19 Tracker
sent them a text message via SMS with short-lived links to a web app. The link incorporated
a randomly generated identifier that was unique to each patient allowing patients
to submit data without entering their credentials.
Integrating Data into the Clinician Workflow
While YNHH's EHR did not provide an FHIR API to write a QuestionnaireResponse, it
provided the FHIR API for writing an Observation. The Patient Tracker app recorded
patient response data internally as a FHIR QuestionnaireResponse resource and transformed
the responses to FHIR's Observation resource patient response data to send to the
EHR instead of the QuestionnaireResponse resource. In addition, the developers had
to use proprietary EHR installation-specific identifiers in the Observations instead
of codes from standard terminologies such as LOINC or SNOMED that are supported by
FHIR. Using these proprietary identifiers allowed the Observations to be placed automatically
in the CC's workflow.
Identifying Critical Values for Clinicians
The EHR at YNHH did not provide the CommunicationRequest API so that the COVID-19
Tracker could notify the CCs via a message. Further, an inbox message would alter
the existing CC workflow. The Observation API in the YNHH EHR did not accept the data
field for interpretation. The solution was to have the Patient Tracker app immediately
prompt the patients to contact their clinician's office if they reported a critical
value.
Discussion
We described our experience with integrating a patient engagement application to monitor
patients remotely. Our objectives were to avoid significant changes to the existing
clinical workflow, engage patients through text messaging for data collection and
guidance provision, and facilitate EHR interoperability. Application integration with
the EHR was essential to achieve this objective. The informaticians used interoperability
standards for the COVID-19 Tracker and EHR integration to reduce the effort at YNHH
relative to a nonstandard-based approach and to make the COVID-19 Tracker portable
to other organizations.
Our implementation of the COVID-19 Tracker encountered barriers that have hampered
EHR integration for years; however, our approach benefited from the considerable progress
that has been made in allowing apps to integrate with EHRs using standards, and FHIR
in particular.[18]
[19] Compared with prior standards, FHIR resources provide more structure and semantics
to the data that is exchanged during integration.[19] The development and integration of the COVID-19 Tracker application would have been
difficult without FHIR APIs and would have taken longer to implement. FHIR APIs made
it easier for the COVID-19 Tracker to obtain data from the EHR because the software
developers already had software libraries that could request data using FHIR APIs
and integrate the responses into apps. Our informaticians and developers have experience
with FHIR which made authoring of specifications for integration faster.
However, the project encountered many challenges that required adopting alternative
approaches to integration. The implementation barriers resulted from the following
factors: (1) partial implementation of current FHIR standards in the EHR at YNHH that
were relevant to patient engagement,[20] (2) still evolving experience with the use of FHIR standards and API-driven integration
especially at health care organizations, and (3) gaps in the current FHIR standard.
These factors can be attributed to the recent introduction of the FHIR standard and
the regulations that have encouraged or required its use.[21] Thus, EHR products, such as the one in use at YNHH, are still incorporating additional
APIs for many FHIR resources.
Currently, EHRs provide APIs with appropriate clinical data, such as those for diagnoses,
vital signs, or diagnostic test results. However, APIs for writing data to the EHR
are limited. Most EHRs have limited support for apps to write QuestionnaireResponses
or Observation data,[22] despite the fact that these are the most common types of data obtained from patients.[23] The developers could not write QuestionnaireResponses at all, and writing Observations
had missing capabilities (e.g., no interpretation, no standard codes). The lack of
a CommunicationRequest API added challenges to creating a patient engagement application
where clinicians and patients could be made aware of situations and requests. We are
not aware of any EHR or a widely used notification product that supports this resource,
though some EHRs provide proprietary APIs for this purpose. The novelty of the FHIR
standard with an API-based approach means health care organizations may have outdated
practices and policies, and their IT staff may still be gaining expertise.
The developers encountered a barrier due to a firewall that prevented our application
from accessing the FHIR APIs. While the organization added exceptions to the firewall
for the application, this approach is not scalable. With the wider adoption of patient
engagement apps, which typically are hosted by cloud computers, adding firewall exceptions
will increase security risks. Accordingly, newer practices, policies, and technologies
may be required for patients to securely access and transmit their data via apps.
Finally, we encountered only one significant gap in the FHIR standard itself which
is the ability of EHRs to request the enrollment of a patient in the app's engagement
program. Addressing this gap, coupled with the implementation of the Subscription
resources, is an essential first step if the vision for digital app formularies and
broader clinical adoption of patient engagement apps is to be realized.[24]
More complete implementation and adoption of FHIR standards to improve interoperability
of patient engagement apps with EHRs can increase the use of PGHD in clinical decision-making
and patient-centered care, reduce the potential workflow burden on clinicians of accessing
poorly integrated PGHD, and decrease the strain on a health care organization's IT
resources as they integrate a growing number of patient engagement apps. Developers
of EHR systems and of patient apps need to be encouraged to rapidly implement or adopt
the full functionality of FHIR resources relevant to patient engagement apps. Progress
in this direction might be accelerated by policy recommendations from large stakeholders
in health care such as the Office of the National Coordinator for Health Information
Technology or the Centers for Medicare & Medicaid Services.
The adoption of the following standards by relevant systems such as EHRs and patient
apps are critical to integrating third-party patient engagement apps into the workflow
across a range of clinical sites: (1) allow event notifications from the EHR to apps
(via Subscription) to facilitate selection and enrollment of patients and to make
apps aware of changes in a patient's data; (2) expand the capabilities to write more
PGHD from the app into the EHR (as Observation and QuestionnaireResponse) to access
PGHD easily in clinical workflows; and (3) enable apps to send notifications to patients
and providers (via existing EHR and portal channels such as workflow inboxes and emails)
leveraging the CommunicationRequest request. Further, we identified some gaps in the
standard itself, such as messages that communicate requests from the EHR to enroll
patients into an app. Similar functionality needs for the integration of patient apps
have been described by others.[8]
While this case report was focused on technological challenges in integration, as
a final albeit important reflection, we recognize the importance of the many roles
that impact the success of integration. As many implementation studies have shown,
the support of local champions and patient and clinician users is essential. The design
input of the users was key to creating a solution that seamlessly integrated into
their workflows and was usable by them. Local IT expertise is critical to integrate
and test the apps in the clinical environment even when the app uses standards. For
example, writing symptom observations to a patient's record using FHIR required an
order from a clinician. This need was recognized and addressed by YNHH's IT team.
Conclusion
The FHIR standard demonstrates promise in integrating patient engagement apps with
EHRs. The challenges we describe in this case report were largely due to the early
stages of development and adoption of FHIR. We recommend the continued development
of the standard, its further implementation in different healthcare settings, and
encourage sharing experiences with its use, as we do in this case report.
Clinical Relevance Statement
Clinical Relevance Statement
This case report highlights challenges that arise when implementing a third-party
patient monitoring and engagement application into a commercial electronic health
record (EHR). Seven specific challenges are identified, and a description is provided
for how each challenge was addressed and resolved. Addressing these challenges will
facilitate the integration of third-party applications into EHRs, thereby enabling
new functionality that can improve care and impact policy within the confines of current
interoperability standards.
Multiple Choice Questions
Multiple Choice Questions
-
When seeking to integrate a third-party application into a commercial electronic health
record, what is a primary obstacle for achieving interoperability?
-
Current standards do not support any third-party app integration with the EHR.
-
Standards search as Fast Healthcare Interoperability Resources (FHIR) are limited
in their extent of implementation and lack full functionality.
-
HL7 version 2 standards need to be customized to the specific third-party application.
-
Data cannot be transferred from the third-party application into the EHR.
Correct Answer: The correct answer is option b. FHIR standards are available to support data exchange
and transfer; however, these standards are relatively immature and are not yet ready
for plug-and-play functionality as eventually intended.
-
What techniques can developers leverage to facilitate the uptake of third-party application
integrated into the EHR?
-
Create the application to function as a standalone system outside of the EHR.
-
Provide extensive user training so that the app will be familiar to the intended users.
-
Integrate the application with existing workflows and familiar reports.
-
Create new workflows so users will be able to distinguish the new application from
prior systems.
Correct Answer: Option c is the correct answer. Creating a third-party application that leverages
familiar workflows and reports reduces barriers by decreasing the cognitive load for
using the new system.
