FHIRedApp: a LEAP in health information technology for promoting patient access to their medical information.

OBJECTIVE: Our aim is to develop a patient engagement technology that makes it easy for patients to access their own medical information and share it with others.
MATERIALS AND METHODS: This paper describes our design through an adapted Community Engagement Studio methodology to identify the needs and preferences of a diverse group of Latinx, African-American, and Asian-American individuals in the community. We use Human-Centered Design to interpret these needs and preferences to build a digital app platform, using national data standards, clinical data aggregators, and privacy-preserving solutions while maintaining the security and confidentiality of patients.
RESULTS: We designed and developed FHIRedApp, an app platform, that allows patients to access their data and to share that access as HL7® FHIR® application programming interfaces with third-party app developers. We accomplished 2 major tasks: first, to demonstrate the use of interoperability and authentication standards, such as HL7® FHIR and OAuth2, to help develop patient engagement technologies, and second, to co-develop and co-design FHIRedApp with active involvement of African-American, Latinx, and Asian-American community members. Usability results show high satisfaction rates for FHIRedApp.
CONCLUSION: The development of FHIRedApp demonstrates how technology innovations using national interoperability standards can be informed through a methodology of community engagement and human-centered design that involves local racial and ethnic groups.

BACKGROUND AND SIGNIFICANCE

The release of the final regulations of the 21st Century Cures Act was a landmark legislation in health information technology to prevent information blocking by healthcare providers and to enhance patient access to their medical records. These regulations are based on the recognition that healthcare has not kept pace with other industries in the adoption and utilization of modern interoperable technologies and in empowering consumers. Despite widespread adoption of Electronic Health Record (EHR) systems in the United States, patients’ access to their medical data is still elusive. Regulatory barriers, technical roadblocks, literacy challenges, and adverse financial incentives have been identified as some of the reasons why patients are not able to easily and efficiently access their medical information even though there is substantial evidence on the benefits of patients’ involvement in their health management through data access., The problem is exacerbated with a technology access gap that greatly affects underserved minority populations and further increases health inequality nationally.

While patient portals offered by healthcare providers can be considered as patient engagement technologies (PETs) they are usually in the control of the provider or their EHR vendor, usually limited to facilitating simple tasks of scheduling and billing for patients. Since every provider, payer, and pharmacy have their own portals that are not interoperable, a patient is left with multiple portals to manage. Federal policy has supported patient access to their data through regulations such as in Meaningful Use requirements, and has also provided direct incentives for healthcare organizations to foster the use of PET. However, no widespread or significant progress has been achieved in more closely engaging patients in their health management through PET. Many factors have contributed to the lack of adoption and adherence to PETs including the (a) fragmentation of health data across providers resulting in incomplete information at each source; (b) variety of PET designs for online and mobile access to information; (c) variability of features across PETs by different vendors with no standardization or uniformity; (d) complex user password and access management features requiring a higher than average health and technology literacy; and (e) frequent changes of software design and features that confuse users.

FHIRedApp is designed for and co-designed by patients from ethnic minorities in the local community of Central Texas. Most well-known commercial platforms (including Apple Health, CommonHealth) do not claim to be designed specifically for the needs of the most vulnerable., There is evidence that digital interventions can improve healthcare utilization and healthcare costs in underserved populations and there is a need to improve the design and usability of digital apps for these low socioeconomic, minority and rural populations. Cheng et al also show that socially disadvantaged groups have lower access and skills to use technologies and are at risk of being digitally marginalized leading to the potential of widening of health disparities. At the same time, culturally appropriate health education using digital platforms has shown to make statistically significant improvements among socially disadvantaged groups for chronic conditions. There is, therefore, a need to engage more racially/ethnically diverse populations to help develop digital interventions to improve health outcomes in racially/ethnically disadvantaged groups.

OBJECTIVES

Our objective is to develop a patient engagement technology that (a) fulfills the essence of the 21st Century Cures Act and provides patients easy access to their clinical data; (b) is designed for populations that includes underserved and underrepresented populations in healthcare and research; (c) uses national standards for interoperability, security, and authorization; and (d) opens up new opportunities for an ecosystem of PETs by empowering patients to share their data with third-party app developers. This effort was funded by the Office of the National Coordinator for Health IT (ONC) in 2019, as part of ONC’s Leading Edge Acceleration Projects (LEAP), to design, develop, and demonstrate an enhanced PET platform. The goal of the ONC program was to modernize patient engagement tools, engage diverse populations including the underserved, enhance opportunities for underrepresented populations to participate in research while addressing security and privacy concerns, allowing data transport from various digital devices, and applying user-centered design principles.

METHODS

We developed FHIRedApp as an app platform that allows patients to gain access to their data, grant access to all or part of their data, and make it available to third-party app developers via FHIRedApp’s HL7® FHIR® (Fast Healthcare Interoperability Resources) APIs (application programming interfaces). This allows for innovative solutions to be built and provided to patients to harness the value of their medical data.

The design and development of FHIRedApp comprised 3 innovative and closely connected interventions. First, to develop meaningful, practical, and impactful PET, we started by engaging community partners throughout the development process as co-designers and key informants. Second, we used human-centered design principles to translate the guidance from community partners into technical and user features for the app platform. Third, we used FHIR APIs, secure authorizations, and privacy-preserving record linkage technologies to develop FHIRedApp.

Design through Community Engagement Studios and Human-Centered design

The overall development of FHIRedApp was informed by Community Engagement Studio (CES) and Human-Centered Design (HCD) methodologies. CES is a structured-forum, designed to gain valuable community insights on a research topic. CES provides researchers with a real-time, in-person opportunity to share their research projects and goals with community members, advocates, and other stakeholders, and to receive direct feedback and guidance via a facilitated conversation. CES meetings are led by a community navigator. Unlike traditional CES that often take place at a single point in time, we adapted the CES to meet on multiple occasions throughout the life of the project, with each meeting guided by the objectives of the research and the active participation of community members that are considered experts and consultants for the research team. We selected CES members from the Austin metropolitan area in Texas. We ran 5 CES sessions concurrently with 3different subgroups from the local African–American, Asian–American, and the Latinx communities, respectively, throughout the development process. The study was approved by the institutional review board of the University of Texas at Austin.

Two oversight boards, the Community Advisory Board (CAB) and the Community Strategy Team (CST), were established to advise in the multiple stages of the project. The CST team within the Dell Medical School’s Department of Population Health, a body of 9 community leaders with lived experience, were asked for advice on scope of the project and community engagement. CAB, another group of 10 researchers and community members, provided guidance on community engagement aspect of the project. The CAB helped with the process of recruiting the members of CES. All community experts in CES and advisory members in CST and CAB were compensated for their time.

The role of the HCD team was to extract themes and particular requirements from the CES discussions to inform the design of FHIRedApp. HCD is defined as an approach that ensures that the needs and requirements of the user are taken into consideration throughout the design process. The insights gained from CES sessions informed the HCD work and helped identify features and capabilities that these representative racial and ethnic groups in the community desired from a health app platform. The HCD methodology included: (a) a comparative analysis of currently used similar digital platforms; (b) scenario creation based on input from CES meetings and surveys; (c) development of early low-fidelity designs; (d) usability tests with consented patients; and (e) iterative 1-on-1 design sessions with users to develop high-fidelity designs.

We conducted a beta test of the FHIRedApp prototype and finalized the design through an iterative process with 10 participants. The participants were recruited through a convenience sampling and personal networks, ensuring that CES or CST members who had previously seen the FHIRedApp prototype were not included in such testing. We had 1 Asian–American, 2 African–American, and the rest Latinx participants. Strengths and limitations of the prototype were assessed through interviews with each participant. Data from these interviews guided the modification and refinement of the prototype, prior to testing. Data regarding feasibility, acceptability and barriers that could limit effectiveness of the platform were used to guide modifications to finalize the software and platform development. We also conducted 60-min semistructured interviews with 10 participants from the 3 user groups (Latinx, African–American, and Asian–American). Participants completed a series of tasks on the FHIRedApp platform and were asked to complete a protocol to capture comprehension of the goals and purpose of the system. The post-task surveys, including the validated System Usability Scale (SUS), a validated measure for assessing the strengths and weaknesses of digital systems including PETs, helped identify any points of confusion, opportunity, and delight.

Development of FHIRedApp Using FHIR APIs

The current regulatory environment will require that EHR vendors provide HL7® FHIR® API endpoints that can be leveraged by app platforms such as FHIRedApp. Apps will then be able to connect to those endpoints to access the data and deliver valuable features to patients. While this feature may be available in some EHRs today, it may not be until 2023, when this API ecosystem becomes available to app developers across all EHRs. Additionally, there is no national patient identity record or master patient index that would allow a user of such apps or app platforms to easily connect to a patient’s data from all healthcare providers that they have visited previously. Current app platforms require users to directly authenticate to each and every EMR manually in order to gain access to a user’s data and deliver value. FHIRedApp is designed to leverage current national healthcare data aggregators such as Health Information Exchanges (HIEs), Clinical Data Research Networks (CDRNs), or the CMS Blue Button 2.0. These aggregators not only store the medical records of millions of individuals, but they also have normalized the data to national standards and linked the records of patients across the healthcare providers they serve, making these aggregators a feasible way to deliver data to patients “without special effort.”

While FHIR APIs and SMART on FHIR are designed to make it easy for app developers to access data, FHIRedApp provides value beyond the usual EHR-based FHIR API. An app that retrieves data from one EHR has the view of one EHR, however, by using an HIE as its data source, FHIRedApp provides the view of many care sites the patient has visited. Additionally, HIEs are aggregators of other pieces of information not found in EHRs natively such as homeless status, social needs assessments, etc. This also avoids the need to require the user to login to each EHR portal to gain access to their data which can limit adoption due to technical literacy. Users should not have to know what the underlying data structure is to get to their information. HIEs provide a way to simplify that process as a data aggregator. Furthermore, the FHIRedApp back-end infrastructure leverages privacy-preserving record linkage and limited dataset (LDS) capabilities to reduce regulatory and legal burdens in the sharing and access of the data while also more effectively maintaining the security and privacy of patients’ data.

RESULTS

After the initial CES meetings and HCD process, the designs of FHIRedApp were developed as shown in Figure  1. The home screen of FHIRedApp contains a search tool to easily find any app or resource within the platform, a quick access section to get users quickly to the most used apps or resources such as their records or the FHIRedApp App Store, and a navigation menu to take users to the key features of the platform (Home, Notifications, My Records, App Plug-ins, and Account). The other screenshots in Figure  1 show the designs of the My Records, Notifications, and the App Store with 2 third-party apps that were integrated to the platform to test its functionalities.

Figure 1.

FHIRedApp front-end high-fidelity designs.

Figure  2 depicts a flow diagram on how the FHIRedApp back-end infrastructure is able to aggregate clinical data and seamlessly deliver such data as APIs to users of the FHIRedApp platform. We partnered with the Integrated Care Collaboration (ICC), an HIE in Central Texas, that aggregates data of over a million patients across various healthcare providers in the region. ICC data contributors include 3 hospital systems accounting for about 80% of all hospital services in the region, federally qualified health centers, behavioral health providers, the Austin-Travis County Emergency Medical Services (EMS), and several primary care provider organizations sharing Medicare, Medicaid, and uninsured patients’ data across all participants in the exchange. ICC houses all its data in a Clinical Data Repository (CDR) after patient records are linked across providers through an Enterprise Master Patient Index (EMPI) and normalized to national standards such as the International Classification of Diseases Tenth Revision (ICD-10), the Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT), and the Current Procedural Terminology (CPT) codes. The CDR stores patient demographics, encounters, diagnosis, procedures, medications, labs, and vitals.

Figure 2.

DMS data integration and linkage to serve FHIRedApp users. Abbreviations: DMS: Dell Medical School; ICCHashID: IDs generated by hashing tool for protected health information from HIE (ICC); PatID: actual patient ID in the HIE; FAHashID: hash created by FHIRedApp for users that sign up for the platform; DMS-AWS: Dell Medical School Amazon Web Server; CDR: clinical data repository; ETL: extract, transform, load.

Additionally, we adopted a Privacy-Preserving Record Linkage (PPRL) solution that is utilized by several large national data research networks such as PCORnet (www.pcornet.org) and N3C (covid.cd2h.org) to link patient records without storing Personally Identifiable Information (PII) such as names, addresses, or phone numbers and enhance the security and privacy of the data. PPRL effectively generates HIPAA compliant hashes using the National Security Agency (NSA) Secure Hash Algorithm (SHA-512) from PII at each node involved in a process of record linkage. These hashes are further enhanced to prevent dictionary attacks that could reveal the originating data by adding a salt or seed that is unknown to the parties involved in the process. In Figure  2, the salt is generated by an External Party that does not have any access to the demographic data that will be used in the process of hashing and consequently linkage. The overall process generates a combination of hashes that are then used by a matching tool using deterministic and probabilistic algorithms that have shown to match individuals correctly close to 100% of the time (0.9569 sensitivity and 0.9999 specificity). The process of data integration and linkage for FHIRedApp back-end infrastructure happens on Amazon Web Service (AWS) accounts managed by our team through the following steps:

ICC deploys a Hashing Tool that accesses demographics information (names, date of birth, gender, etc) to generate salted hashes that comply with HIPAA’s de-identification methods and a cross-table of IDs between the hashes generated and the CDR. The salted hashes are then submitted to our team along with a limited dataset as defined by HIPAA which excludes most PII elements except for dates and zip codes through Extract, Transform and Load (ETL) processes;

When a user signs up and consents to use the platform, FHIRedApp collects basic demographic information from the user (name, email, phone number, and gender) that will be used by the PPRL solution (hashing and matching tools) to link users to their medical records. The hashing tool deployed at the back-end receives the user’s demographic information and also generates salted hashes and a cross-table of IDs that links users to their hashes;

Finally, an ETL process utilizing the IDs linked by the Matching Tool combines the records from the LDS and the users’ database (DB) to generate the FHIRedApp DB. That database is translated or mapped into FHIR APIs and exposed using a HAPI Server to the mobile FHIRedApp front-end app.

FHIRedApp also utilizes other technology architecture solutions to deliver the services needed to serve users and third-party apps. It also controls data access to maintain users’ security and privacy. Figure  3 shows how the whole platform is protected by an authentication and authorization framework utilizing OAuth2 (https://oauth.net/2/) where all data access is API-based. Additionally, FHIRedApp includes messaging, alert and notification services among others that third-party apps can leverage to provide services to users. Finally, all data and services aspects of the back-end platform are segregated and protected individually so that unauthorized access to any part of the platform is not possible.

Figure 3.

FHIRedApp back-end infrastructure segregation and security.

The project also includes the development of a pilot app (StudyApp) to help with recruitment for research studies and the integration of a social services referral network (Aunt Bertha) to demonstrate FHIRedApp’s ability to allow users to share the access to their data with other apps so that additional features, services and value is delivered to them. Individuals that download, install, and consent to FHIRedApp are also able to install the StudyApp and Aunt Bertha apps onto their FHIRedApp. Individuals that install StudyApp consent to allow 2-way communication between study participants and researchers through StudyApp Messaging and Notification features. Individuals that install Aunt Bertha consent to allow Aunt Bertha to access individuals’ ZIP codes and diagnoses codes so that Aunt Bertha can provide customized social services referrals to the users of the app.

We analyzed data from 10 participants where usability metrics were collected to inform the redesigns of the platform that were initially created based on the research team’s specifications and requirements informed by CES sessions. Participants were selected considering their age, gender, tech literacy, and ethnicity to equally represent the views and perceptions of each group. Age ranged from 27 to 48 years old; gender (male and female) and tech literacy (expert or novice) were 50/50 distributed; and ethnicity included 1 Asian–American, 2 African–Americans, and 7 Latinx. The usability evaluation included 8 tasks that participants had to complete over 1 h remote conference call which was followed by a post-task survey (SUS). The final aggregate score for the surveys was 79.6 on the SUS scale where a score above 68 is considered above average, 72 is considered good, 85 is considered excellent, and 100 the best imaginable app.

Likert scores for using the app were also captured and all users completed all tasks (10 out of 10) successfully (see Supplementary Appendix 1 for the usability questions). Likert score success rates ranged from 4.4 to 4.9 for each of the 8 tasks for an average score of 4.65 which is considered a great score on the 0 to 5 scale (Table  1). One-on-one interviews after the usability tests also revealed insights that helped guide the redesigns of FHIRedApp. For instance, 4 users expected more instructions from the app on how to use it, 5 expressed confusion during the onboarding process and what FHIRedApp was trying to achieve, 3 users were unsure about what the search buttons were, and half (5) of the users were unclear about the icons on the home screen, Finally, the interviews also helped identify additional features, capabilities or shortcomings of other sections of the platform, such as medications and third-party app browsing. Examples include the desire for more detailed information on medications, the ability to print a medication list, and better app browsing features and details.

Table 1.

Likert score of satisfaction with FHIRedApp features

Task	Activity	Success rate	Satisfaction Likert score (0–5)
Task 1	– Onboarding	10/10	4.9
Task 2	– Looking around the app freely	10/10	4.6
Task 3	– Check the list of medications	10/10	4.9
Task 4	– Navigate lab results,	10/10	4.5
	– Find out and export the report
Task 5	– Navigate specific medication	10/10	4.4
	– Navigate prescription data
Task 6	– Browse third-party app	10/10	4.8
	– Jump over the 2 platforms
Task 7	– Receive notifications from third-party app	10/10	4.7
	– Sign up for clinical trial with StudyApp
Task 8	– Manage unread notifications	10/10	4.4
	– Participate in a survey in the messenger system

The results were positive, the SUS revealed an above average index score and the minimum post-task satisfaction Likert scores averaged a 4.4 out of 5 showing that the participants subjectively found the tasks easy to complete. Participants completed most common tasks with 100% success.

DISCUSSION

We described the design and development of FHIRedApp, an app platform that allows patients to access their data and to share that access as HL7® FHIR® APIs with third-party app developers. As a LEAP project for health information technology sponsored by ONC, we accomplished 2 major tasks: first, to demonstrate the use of interoperability and authentication standards approved by ONC and the industry, such as HL7® FHIR and OAuth2, to help develop responsive patient engagement technologies, and second, to co-develop and co-design FHIRedApp with active involvement of African–American, Latinx, and Asian–American community members to help address health disparities in the use and benefits of PETs in underserved populations. We hope that the methodology and design of FHIRedApp will facilitate further development of these approaches and meaningful engagement of patient population in fulfilling the mandate of 21st Century Cures Act to allow patients to ‘access, exchange, and use’ their health data ‘without special efforts’.

There are limitations to our proposed solution. First, our solution is informed specifically by 3 ethnic and racial groups in the Austin metropolitan area. This provides us some diversity in feedback, but it is possible that other groups or the same groups in other regions of the country may have different needs and perspectives of what a PET like FHIRedApp should include. Second, we have done preliminary usability studies, but a more detailed implementation and usability study can help us better understand the factors and variations in adoption by different groups within underserved populations. Third, our solution does not exhaust all possibilities of what a platform such as FHIRedApp can be used for by patients. For instance, it can help with ordering refills, getting labs, scheduling appointments, creating alerts, etc. While we test some of these features as a proof of concept, there is further development required, which will help in engaging patients from underserved populations to actively participate in healthcare and research.

Our future research in this area will focus on scalability using other HIEs and data sources like CMS Blue Button 2.0, a rigorous evaluation of factors affecting adoption, acceptability, and appropriateness of FHIRedApp for various racial and ethnic groups, and testing the impact of the use of FHIRedApp on patient behaviors and outcomes. The federal policy and HIT industry direction toward an API-based ecosystem, will facilitate the use and further development of FHIRedApp platform and other such PETs, thus creating a helpful environment for innovation and entrepreneurship for digital apps that are easily available and customizable to the needs of various subgroups in a diverse population.

CONCLUSION

We developed and demonstrated the development of a patient engagement technology with active participation and collaboration of various racial and ethnic groups in our community, while using national HIT standards. This research highlights the need for further work in the use of technology standards and innovations to empower patients with easy access to their own medical data and the development of an API-based ecosystem that allows app developers to work directly with patients within a privacy and security architecture. More importantly, the development of FHIRedApp demonstrates a methodology of community engagement and human-centered design that engages racial and ethnic groups that have not been traditionally well-represented and engaged in health care and clinical research.

FUNDING

The authors want to acknowledge funding support from the Office of the National Coordinator for Health Information Technology (ONC) of the U.S. Department of Health and Human Services through its Leading Edge Acceleration Projects funding, Award#90AX0025/01-00. The information or content and conclusions are those of the author and should not be construed as the official position or poicy of, nor should any endorsements be inferred by ONC, HHS, or U.S. Government.

AUTHOR CONTRIBUTIONS

AK and EO conceived the research; AK, EO, VL, and VA implemented the development of the application and contributed to the technical details in the manuscript; AK, EO, EN, and VL performed literature review of patient engagement tools and usability studies. AK drafted the manuscript, and all authors contributed substantially to its revision. AK takes responsibility for the paper as a whole.

SUPPLEMENTARY MATERIAL

Supplementary material is available at JAMIA Open online.

CONFLICT OF INTEREST

None declared.

DATA AVAILABILITY STATEMENT

The data related to usability studies presented in the paper will be available upon request from the authors.

Click here for additional data file.