A novel application of SMART on FHIR architecture for interoperable and scalable integration of patient-reported outcome data with electronic health records

Abstract

Objective

Despite a proliferation of applications (apps) to conveniently collect patient-reported outcomes (PROs) from patients, PRO data are yet to be seamlessly integrated with electronic health records (EHRs) in a way that improves interoperability and scalability. We applied the newly created PRO standards from the Office of the National Coordinator for Health Information Technology to facilitate the collection and integration of standardized PRO data. A novel multitiered architecture was created to enable seamless integration of PRO data via Substitutable Medical Apps and Reusable Technologies on Fast Healthcare Interoperability Resources apps and scaled to different EHR platforms in multiple ambulatory settings.

Materials and Methods

We used a standards-based approach to deploy 2 apps that source and surface PRO data in real-time for provider use within the EHR and which rely on PRO assessments from an external center to streamline app and EHR integration.

Results

The apps were developed to enable patients to answer validated assessments (eg, a Patient-Reported Outcomes Measurement Information System including using a Computer Adaptive Test format). Both apps were developed to populate the EHR in real time using the Health Level Seven FHIR standard allowing providers to view patients’ data during the clinical encounter. The process of implementing this architecture with 2 different apps across 18 ambulatory care sites and 3 different EHR platforms is described.

Conclusion

Our approach and solution proved feasible, secure, and time- and resource-efficient. We offer actionable guidance for this technology to be scaled and adapted to promote adoption in diverse ambulatory care settings and across different EHRs.

INTRODUCTION

A patient-reported outcome (PRO) is a metric reported directly by the patient about their own health and quality of life, presenting an opportunity to inform patient care on an individual and population-level.¹ PROs offer a complementary perspective to that of provider assessments and may provide greater insights into a patient’s health status, function, symptom burden, adherence, and health behaviors. Historically, PROs have been captured through structured interviews or paper forms in the provider’s office, limiting their use and usability by patients and healthcare providers.² Recently, there has been a proliferation of digital applications (apps) that can be rapidly developed to collect PRO data. These apps now allow patients to answer PRO surveys on devices such as smart phones or tablets, or on a computer, making it easier to collect PRO data.^3–5 Research has shown that these apps can address previously documented challenges around usability and accessibility and can reduce patient burden from cumbersome and repeated data entry.

The widespread adoption of PRO apps by patients and healthcare facilities is still limited in large part because apps must be customized to their specific instances of use, including customization to integrate with a healthcare facility’s electronic health record (EHR). With EHRs used by over 90% of healthcare facilities in the United States, as well as many other countries, PRO data should be integrated in the EHR to support provider workflow and, ultimately, clinical decision-making. Instances where PRO apps have been integrated with the EHR have shown promise. Yet, researchers who have done this work note that a core set of cross-cutting standards for app and EHR integration are necessary to provide a platform for widespread adoption.⁶ The convergence and optimization of PRO data collection for clinical use and research is dependent on a standards-based solution that is secure, interoperable, and scalable to enable the connection of now widely developed PRO apps with EHRs.⁴

The lack of standards for the capture and exchange of PRO data, as well as the integration of PRO data in EHRs, poses several specific challenges. First, it makes it difficult for app developers to uniformly use validated PRO measures, such as the Patient-Reported Outcomes Measurement Information System (PROMIS) since there is variability in the way the items and responses can be represented. Second, providers may want patients to complete different PRO measures, and, without standards, the methods of assigning measures to patients can vary across apps and result in data that are harder to interpret. Finally, without standards for how PRO data are represented, integration with the EHR requires a customized approach for each PRO and EHR instance, which can be burdensome and limits scalability.

To begin to address these challenges, the Office of the National Coordinator for Health Information Technology (ONC), part of the United States Department of Health and Human Services, developed standards specific to PROs and released a new PRO Fast Healthcare Interoperability Resources (FHIR) implementation guide (IG) detailing such standards.⁷

OBJECTIVE

In this implementation project, we implement a novel application of Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR architecture to better and more efficiently integrate PRO app data with multiple EHRs. We instantiate the ONC’s standards to determine whether they enable greater interoperability and scalability between different PRO apps and EHRs. Using SMART and the PRO FHIR IG, two different PRO apps were integrated with multiple EHRs in different ambulatory care settings. We describe the process and results of our implementation and discuss implications of the standards and architecture for scalable PRO data capture and use.

MATERIALS AND METHODS

Applying the architecture across different apps, EHRs, and healthcare facilities

Two different apps were integrated and pilot-tested at 18 ambulatory care facilities across MedStar Health, a large, not-for-profit, integrated healthcare delivery system in the Maryland/Washington, DC region. The apps were tested in 2 phases (Figure 1). A commercially available app was the focus of Phase 1. After completion of this integration and pilot assessment, a second, newly developed app was integrated and pilot-tested during Phase 2, leveraging lessons learned from the phase 1 integration. Participating sites were of various sizes and geographies (rural, urban, suburban), had varied workflows, and served different patient populations.

Figure 1.

Timeline for Phase 1 and Phase 2.

Phase 1: The commercial app was a cloud-based PRO app hosted by HIPAA-compliant Amazon Web Services. The original app’s ecosystem relied on proprietary standards and technologies. Clinicians and patients accessed the app by using an individual login created by registering an account for each user. The app was previously used in an orthopedic setting to collect demographic and PRO data by implementing logic to adaptively serve content. It was not integrated with the EHR and required providers to navigate to an external, vendor-hosted site with separate credentials to retrieve and view the PRO data. We modified the app to bring it up to the industry standard of Health Level Seven (HL7) SMART on FHIR using the ONC PRO FHIR IG. Patients accessed and completed the PRO instrument using tablets provided at each clinic.

Phase 2: The second app, developed specifically for the Agency for Healthcare Research and Quality (AHRQ) challenge competition focused on PROs and was built using the ONC PRO FHIR IG, resulting in an architecture where the chosen cloud provider hosts and scales the solution. In this phase, we used the “bring your own device” (BYOD) approach to determine feasibility of having patients complete the PRO instrument on their own device at each of the 9 additional sites. All aspects of this study were approved by an independent Institutional Review Board (IRB).

RESULTS

We integrated 2 different PRO apps, 1 commercially available product and 1 product newly developed specifically for the AHRQ challenge competition. The same ONC PRO FHIR IG was used to modify the commercial app and to develop the new app.⁷ The resulting apps were built on a SMART on FHIR security framework. SMART is a security standards-based platform that allows the development of interchangeable healthcare apps that draw from and communicate with any EHR data in a healthcare facility.⁸ The PRO apps were developed to enable patients to answer validated assessments (eg, PROMIS including using a Computer Adaptive Test [CAT] format⁹). Both apps were developed to populate the EHR in real time using the HL7 FHIR standard allowing providers to view patients’ data during the clinical encounter. We describe the overall architecture and the specific components developed to integrate the apps.

Architecture overview

The primary objective of our architecture was to instantiate the ONC PRO FHIR IG and design a secure and scalable method by which structured PRO survey data collected from a third-party app could be integrated with different EHRs. We developed an architecture enabling the display of patient data “On Demand” (described below), and an overall template adaptable for implementation at different clinical sites addressing data storage and retrieval as well as administration and analysis of survey responses using FHIR endpoints. The patient-centric dataflow originated with the patient and flowed to the provider in a clinical setting. The architecture consisted of 4 main components: the patient-facing FHIR-enabled PRO data collection app, a cloud-based FHIR data hub, an external assessment center (EAC), and a web-based provider-facing interface in the EHR (see Figure 2 and Table 1).

Figure 2.

Components of the Data on Demand architecture showing directional data flow.

Table 1.

Data on Demand architecture component descriptions

Component	Task
A	Patient opens the PRO app to access assigned instrument
B	Patient enters credentials
C	Patient credentials verified through the FHIR authorization server
D	The now authorized app retrieves patient’s profile from the “data hub” and serves patient the first survey item from the EAC
	Patient’s survey response determines subsequent survey item served via CAT in the EAC
	EAC serves subsequent items until patient completes ‘n’ items determined by CAT
E	Completed survey responses are stored in the FHIR enabled data hub
F	Provider ready to view patients’ data logs into HER
	Provider accesses patient’s chart through HER
G, H	EHR pulls survey responses from ‘data hub’ and transfers to EHR for real time display
Q1-n	Question 1 (through n)/first to nth survey item served from EAC to the patient
A1-n	Answer 1 (through n)/first to nth survey response from patient to EAC

FHIR-enabled PRO collection app

Our app integration and implementation were designed to facilitate data collection either using an approach in which the healthcare facility provided a device (tablet) for patients to use, or a BYOD approach using a patient’s own compatible smartphone. Both approaches allowed patients to register and complete their assessments within the app (in this case, validated PROMIS questionnaires). Patients who used the practice’s device accessed the pre-loaded app once they arrived for their appointment. In the BYOD model, patients who consented to share their PRO data with their providers downloaded the app on their device, completed the assigned assessment, and were able to review their results.

In both scenarios, patients’ accounts were linked to their unique medical record identifier in the EHR, allowing providers to securely retrieve these responses immediately upon data entry by the patient. The apps used SMART authentication and the latest FHIR protocol to authenticate patient credentials, administer the assessments, and transfer the responses to the data hub (described in section (2) Cloud-Based FHIR Data Hub). The apps also used a cloud-based middle layer architecture and were hosted on secure Health Insurance Portability and Accountability Act (HIPAA) compliant platforms. To initiate data flow, the apps first ensured patients were correctly registered through a SMART Standalone App Launch Sequence, authenticating their details with the FHIR authorization server before allowing the app to proceed to data collection. Once the patient was authorized, the app retrieved the patient’s profile from the data hub and exchanged responses with an external assessment center (EAC) to appropriately administer the instrument, which utilized computer adaptive testing (CAT). The responses were then stored as FHIR Questionnaire Response items in the data hub.

Cloud-based FHIR data hub

The ONC PRO FHIR IG instantiated in our architecture has not yet been widely adopted by EHR vendors resulting in the potential need for custom development to integrate the app with each EHR product. To address this issue, a key feature of our approach was to reduce the complexity of integration needed between the PRO app and EHRs by using an intermediary data hub. The data hub is a secure cloud database and FHIR endpoint that handles patient authentication along with exchange and storage of PRO data. Storing PRO data in this intermediary layer facilitates an easily scalable “light” EHR integration where data can be retrieved from the hub when needed by providers. This approach leveraged FHIR standards for exchanging PRO data to shift the burden of storing PRO data within each EHR implementation’s unique and often complicated clinical data model onto the cloud where it could be dynamically accessed through a secure web interface embedded in the EHR. The data hub also includes an administrator interface which allows clinic staff to register patients in the system, review their completed PRO surveys, and troubleshoot issues that patients may have with their account access.

External assessment center

The external assessment center (EAC) is an agnostic decentralized engine that serves survey questions based on predetermined logic and/or previous responses to a survey. The EAC was used to administer CAT and to track and analyze patients’ PRO data. The EAC implemented the logic to capture the PROMIS assessments, producing a FHIR-formatted bundle of responses and scores in a standardized format. The FHIR IG provided specifications for the EAC, allowing a more generalizable, scalable, and more secure solution to building a survey question distributor. We used SMART on FHIR and Questionnaire Response resources as per HL7 FHIR R4. The standardization of bidirectional data flow provides a streamlined solution relying on open standards.

Web-based provider app

Once the patient completed their PRO assessment, their provider was able to access these data through the patient’s chart in the EHR. This was enabled by a single page embedded application, which authenticated the provider’s credentials and retrieved patient data specific to the chart the provider was accessing. To view the PRO data, the provider had access to a visualization of the PRO scores through webpages that were viewable within the EHR. Each EHR product had pathways to surface custom visualizations using modern web programming languages including HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript. These custom visualizations can natively communicate with Representational State Transfer (RESTful) APIs using JavaScript Object Notation (JSON) upon which the FHIR standard is modeled. The general structure for each interface was able to take advantage of general, system-level SMART on FHIR authorization and authentication standards to seamlessly validate the provider’s access to the data, preventing the need for an additional authentication step. Finally, as the web component was embedded in the patient’s chart, the provider interface only retrieved data relevant to that specific patient.

App usage and site implementation

Phase 1

All 90 consenting patients were able to access and use the app to enter their PRO data immediately prior to their appointment. Patients all used tablets provided by the clinic at registration. All practices had full technical assistance to support the integration and implementation, learnings from which informed Phase 2 integration and implementation. None of the patients had difficulties using the PRO app, and none of the providers had difficulty accessing PRO data in their respective EHR.

Phase 2

At the end of the enrollment period, 84 patients consented, and 58 patients were able to successfully access and download the app on their devices to enter their PRO data across the 9 practice sites. The remaining patients were unable to use the app to completion due to technical challenges related to their smartphones. This included connectivity issues (lack of access to wi-fi or insufficient broadband access), or lack of compatible smartphone or operating system on their devices. A total of 13 providers accessed the patients’ previously entered data during their encounter with the patients. Each practice had varying levels of technical assistance to support the integration and implementation. The challenges the patients faced with using the PRO app were unrelated to the standards and architecture. The providers were able to access the PRO data, when successfully entered through the app, without any challenges.

DISCUSSION

The widespread adoption of PRO apps requires a more standardized process to capture PRO data from patient-facing apps and to integrate this information with the EHR for clinical use. The ONC has developed the PRO FHIR IG to address these needs; however, to date, these standards have not been instantiated in an architecture and implemented across apps, EHRs, and healthcare facilities. We have demonstrated that these standards can be used to seamlessly capture PRO data, and these data can be made available to clinicians on-demand.

Adaptation of the architecture to different EHRs

Even with the ONC PRO FHIR IG there were some challenges and key lessons learned as we implemented our architecture to connect PRO data from the 2 apps with different EHRs. Several of these were realized in the Phase 1 implementation, allowing for a more optimized implementation in Phase 2.

EHR-specific differences in provider web app implementation: Implementation of the provider-facing web app at the 18 clinical sites yielded key insights related to their EHR differences. The implementation processes in 2 different EHRs were found to have different underlying browser stacks, which resulted in the creation of 2 different provider-facing visualizations. The advantages of standards-based SMART security and FHIR data exchange do not eliminate the vendor and EHR-specific variations in how these data visualizations may be rendered. One salient example is if the EHR only provides older platforms for custom data visualization, the suite of tools for development of advanced visualizations may not be available. In some cases, this may introduce variability in the methods by which the provider-facing web interface brokers communicate with servers. We found having a consistent target platform for web app development is critical to cross-site provider-facing visualization implementation.

Necessity to design for the least amount of client variability: EHRs can be installed in workstations in a variety of ways, including a local installation or as a remote display such as Citrix. The EHR installation method can affect performance and render any third-party app unless that rendering is tightly coupled with the client. We therefore implemented the PRO provider-facing app in a way that allowed us to manage client level variability as much as possible, and in a way that made it easier to address technical issues from installation variability without extensive support from the EHR vendor. This was achieved by using basic tools for implementing the custom data visualization as well as providing a middle tier (the data hub).

Avoiding user re-authentication by using the EHR as the trusted app: Under our current architecture, because the provider was already logged into the EHR, the most efficient workflow was achieved by launching the provider-facing web app within the EHR and avoiding user re-authentication. This approach treated the EHR as the trusted app. We locked down our web app to specific EHR Internet Protocols (IPs), thus allowing it to work securely from within the EHR. The provider-facing app that was visible from within the EHR never stored any data locally and always used HT TPs for secured transmission of data. These functions were all achieved with minimum modification to the actual EHR, making it relatively easy to install on different EHRs, and scalable as a result.

Building an External Assessment Center to support the solution at different sites: Across both phases of PRO app integration, we employed different modifications to incorporate the EAC. The EAC is generally ‘buy-or-build'. Building an EAC to provide adaptive content requires domain expertise, is technically challenging, and resource intensive. However, the tradeoff for this is the cost incurred from licensing fees to implement the existing EAC. Not using an EAC for the management of content would lead to increased development costs, prolonged timelines, and greater customization for each implementation of the tool in different healthcare facilities and EHR products. In Phase 1 of our implementation, the EAC was built by the vendor. For Phase 2, it was licensed and customized for the build. Whether the approach is to buy or build, there is no additional security infrastructure to build since the EAC does not store any protected health information.

Health system level approvals necessary for full app integration and app deployment: One of the most significant barriers encountered, particularly in Phase 2, was unanticipated delays in implementation due to a health system’s institutional policies and regulations necessary to secure approval and clearance to integrate new PRO app technology with the health system’s native information systems architecture. These policies and regulations will likely be highly variable by institution but will need to be anticipated in any implementation timeline. Technical teams should allow significant time to navigate these processes and to meet institutional requirements, particularly when new vendors are working with a system for the first time (see “Demand Management” on timeline in Figure 1).

These issues all highlight critical points at which the coordination of human and technical processes is crucial to ensure the successful use of PRO data. There are a few limitations to our implementation study. First, PRO app implementation and patient and provider enrollment were closely controlled by the study team in Phase 1. This experience does not represent the clinical implementation processes and use “in the wild” where a dedicated study team and intervention by a research coordinator or other facilitator would not be available. However, this study demonstrated feasibility and, in Phase 2, provided key insights about the level of resources need for each component of implementation. These results are described separately. Second, there is likely selection bias in terms of the clinics, providers, and patients who agreed to participate. Actual adoption by providers and practices is likely highly variable. Despite these limitations, we successfully demonstrated feasibility that, with some modifications, the SMART on FHIR platform effectively bridges the gap between efficient collection of PRO surveys with highly usable patient-facing apps, seamless EHR integration, and real-time provider access and use of PRO data.

The SMART specification and design allow this solution to be deployed in any clinical setting and is not confined to ambulatory. Future work is needed to identify common implementation facilitators and barriers across different clinical contexts to inform future adoption.

CONCLUSION

We were able to successfully deploy this architecture in 18 clinical sites and across 3 EHR platforms, facilitating integration of PRO data into the ambulatory care workflow using the PRO FHIR IG. Our approach demonstrated the ability to take standards-based technical guidance specific to PROs and translate these into functional solutions for different systems and clinical settings. Further our implementation and testing in distinct ambulatory settings demonstrated the value of our novel architecture’s (“the hub”) scalability and interoperability. The use of SMART on FHIR standards was important in 3 distinct aspects: 1) Facilitated the creation of a data hub, which provided an intermediary layer capable of receiving PRO data from third-party apps in a structured FHIR format; 2) Facilitated secure SMART user authentication and storage of these data; and 3) Provided a standard target for web-based EHR interfaces that reduced the burden for “deep” integration of PRO data with complicated EHR clinical data models. These aspects are particularly important, given the hundreds of different EHR products used in ambulatory care settings.

FUNDING

This work was funded by the Agency for Healthcare Research and Quality’s Contract No. 233-2015-000221-4 which was funded by the Office of the Secretary Patient-Centered Outcomes Research Trust Fund under Interagency Agreement # HP-17-003.

AUTHOR CONTRIBUTIONS

All authors contributed to the analysis and drafting of the manuscript. All authors approved the final work and are accountable for the results.

DATA AVAILABILITY STATEMENT

The analyzed data set is available from the corresponding author upon request.

CONFLICT OF INTEREST STATEMENT

None declared. The findings and conclusions in this manuscript are those of the authors and do not necessarily represent the official position of the Agency for Healthcare Research and Quality.