Integrating a Patient Engagement App into an Electronic Health Record-Enabled Workflow Using Interoperability Standards

Keywords

clinical decision support - interoperability standards - patient-generated health data

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

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

1. 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.

2. 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.

• References

• 1 Cushing A, Manice MP, Ting A, Parides MK. Feasibility of a novel mHealth management system to capture and improve medication adherence among adolescents with asthma. Patient Prefer Adherence 2016; 10: 2271-2275
• 2 Cooley ME, Abrahm JL, Berry DL. et al. Algorithm-based decision support for symptom self-management among adults with cancer: results of usability testing. BMC Med Inform Decis Mak 2018; 18 (01) 31
• 3 Fiks AG, Mayne S, Karavite DJ, DeBartolo E, Grundmeier RW. A shared e-decision support portal for pediatric asthma. J Ambul Care Manage 2014; 37 (02) 120-126
• 4 Saleem JJ, Wilck NR, Murphy JJ, Herout J. Veteran and staff experience from a pilot program of health care system-distributed wearable devices and data sharing. Appl Clin Inform 2022; 13 (03) 532-540
• 5 Cohen DJ, Keller SR, Hayes GR, Dorr DA, Ash JS, Sittig DF. Integrating patient-generated health data into clinical care settings or clinical decision-making: lessons learned from project HealthDesign. JMIR Human Factors 2016; 3 (02) e26
• 6 Patient Safety Network. Alert Fatigue. Patient Safety 101: Primers. Published September 7, 2019. Accessed August 3, 2021 at: https://psnet.ahrq.gov/primer/alert-fatigue
• 7 Ye J. The impact of electronic health record-integrated patient-generated health data on clinician burnout. J Am Med Inform Assoc 2021; 28 (05) 1051-1056
• 8 Rudin RS, Fanta CH, Predmore Z. et al. Core components for a clinically integrated mHealth App for asthma symptom monitoring. Appl Clin Inform 2017; 8 (04) 1031-1043
• 9 CDC. Coronavirus Disease 2019 (COVID-19). Centers for Disease Control and Prevention. Published February 11, 2020. Accessed October 15, 2021 at: https://www.cdc.gov/coronavirus/2019-ncov/science/science-briefs/underlying-evidence-table.html
• 10 Cash JJ. Alert fatigue. Am J Health Syst Pharm 2009; 66 (23) 2098-2101
• 11 Index - FHIR v4.0.1. Accessed October 15, 2021 at: http://hl7.org/fhir/
• 12 Marceglia S, Fontelo P, Rossi E, Ackerman MJ. A standards-based architecture proposal for integrating patient mHealth apps to electronic health record systems. Appl Clin Inform 2015; 6 (03) 488-505
• 13 Dolin RH, Alschuler L, Boyer S. et al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc 2006; 13 (01) 30-39
• 14 Patient-Centered Outcomes Research Clinical Decision Support. Current State and Future Directions | Digital Healthcare Research. Accessed November 9, 2021 at: https://digital.ahrq.gov/ahrq-funded-projects/patient-centered-outcomes-research-clinical-decision-support-current-state-and#h=future%20directions
• 15 Osheroff JA. Healthcare Information and Management Systems Society, eds. Improving Outcomes with Clinical Decision Support: An Implementer's Guide. 2nd ed. HIMSS; 2005
• 16 Strasberg HR, Rhodes B, Del Fiol G, Jenders RA, Haug PJ, Kawamoto K. Contemporary clinical decision support standards using Health Level Seven International Fast Healthcare Interoperability Resources. J Am Med Inform Assoc 2021; 28 (08) 1796-1806
• 17 Johnson C, Richwine C, Patel V. Individuals'. Access and Use of Patient Portals and Smartphone Health Apps 2020; 2021 (57) 14
• 18 Barker W, Johnson C. The ecosystem of apps and software integrated with certified health information technology. J Am Med Inform Assoc 2021; 28 (11) 2379-2384
• 19 Ayaz M, Pasha MF, Alzahrani MY, Budiarto R, Stiawan D. The Fast Health Interoperability Resources (FHIR) Standard: systematic literature review of implementations, applications, challenges and opportunities. JMIR Med Inform 2021; 9 (07) e21929
• 20 KLAS Research. Trends in EMR Interoperability. Published online January 2021. Accessed November 4, 2021 at: https://chimecentral.org/wp-content/uploads/2021/01/Trends-in-EMR-Interoperability_CHIME_KLAS.pdf
• 21 21st Century Cures Act. Vol H.R.34.; 2016. Accessed August 24, 2022 at. https://www.gpo.gov/fdsys/pkg/BILLS-114hr34enr/pdf/BILLS-114hr34enr.pdf
• 22 Dullabh P, Hovey L, Heaney-Huls K, Rajendran N, Wright A, Sittig DF. Application programming interfaces in health care: findings from a current-state sociotechnical assessment. Appl Clin Inform 2020; 11 (01) 59-69
• 23 Sayeed R, Gottlieb D, Mandl KD. SMART Markers: collecting patient-generated health data as a standardized property of health information technology. NPJ Digit Med 2020; 3 (01) 9
• 24 Gordon WJ, Landman A, Zhang H, Bates DW. Beyond validation: getting health apps into clinical practice. NPJ Digit Med 2020; 3: 14