Development of a Mobile Personal Health Record Application Designed for Emergency Care in Korea; Integrated Information from Multicenter Electronic Medical Records

Abstract

Collecting patient’s medical data is essential for emergency care. Although hospital-tethered personal health records (PHRs) can provide accurate data, they are not available as electronic information when the hospital does not develop and supply PHRs. The objective of this research was to evaluate whether a mobile app can assemble health data from different hospitals and enable interoperability. Moreover, we identified numerous barriers to overcome for putting health data into one place. The new mobile PHR (mPHR) application was developed and evaluated according to the four phases of the system development life cycle: defining input data and functions, developing a prototype, developing a mobile application, and implementation testing. We successfully introduced the FirstER (First for Emergency Room) platform on 23 September 2019. Additionally, validation in three tertiary hospitals has been carried out since the launch date. From 14 October to 29 November 2019, 1051 cases registered with the FirstER, and the total download count was 15,951 records. We developed and successfully implemented the mPHR service, which can be used as a health information exchange tool in emergency care, by integrating medical records from three different tertiary hospitals. By recognizing the significance and limitations of this service, it is necessary to study the development and implementation of mPHR services that are more suitable for emergency care.

1. Introduction

Collecting data about underlying diseases, food or drug allergies, and prescribed medications is essential whenever physicians see patients [1]. These data make it possible to efficiently diagnose and treat patients by reducing unnecessary laboratory or imaging tests [2]. When patients go to an emergency department (ED) that they regularly visit, physicians can obtain medical information without any additional effort [3]. In South Korea, medical records are transferred by paper or telephone when patients decide to move from one hospital to the other. Meanwhile, in the case of an unexpected visit to a nearby hospital, especially in an emergency, it is hard to know a patient’s detailed history because patients do not remember exactly their prior illnesses, doses, or types of drugs taken [4]. Although hospital-tethered personal health records (PHRs) can provide accurate data, they are not available as electronic information when the hospital does not develop and supply PHRs [5].

Although the need for convenient access to medical information has been increasing, several factors have limited the development of a PHR platform: related laws, ownership of data, privacy, and security [6]. The patient Privacy Act states that electronic medical records (EMRs) must not be leaked or stored outside of hospitals [7]. However, on account of the high penetration rate of EMRs and the elevated usage rate of smartphones in the country, there has been sufficient social consensus for developing PHRs [8]. Meanwhile, established policies and systems for collecting and utilizing individual medical records have been implemented that have enabled the storage of EMR data in cloud systems outside the boundaries of hospitals. Additionally, operable PHR apps have become available that tether EMRs and link several hospitals [9].

In this context, the Korean government announced a voluntary program called “MyData” in 2019, which gives consumers increased access to their data in portable electronic devices, such as smartphones. This program is a paradigm shift of personal data storage and management that propels the current institution-centric system to a person-centric system, which has already been adopted in medical fields in numerous countries [10]. The MyData program has been applied to various fields, including the health industry, and enables individuals to manage their own health data more actively and efficiently. The development of a new PHR application for emergencies was carried out as the medical part of this program. This PHR application was designed to enable medical information to be owned by patients, not hospitals, and for patients to provide that information to healthcare providers by appropriately utilizing it when necessary. Two tertiary hospitals (Asan Medical Center (AMC) and Samsung Medical Center (SMC)) already have applications for PHR-tethered EMRs (My chart in my hand, SMC mobile) since 2015 and 2013 [11]. However, there are no applications that could link different hospitals across the country. Therefore, we formed a consortium that consisted of one application developer, called value through Technology and Wisdom (vTW) and three tertiary hospitals (AMC, SMC, and Dong-A Medical Center (DAMC)) and developed a new PHR platform that especially targets emergency situations.

The objective of this research was to evaluate whether a mobile app can assemble health data from different hospitals and enable interoperability. Moreover, we identified numerous barriers to overcome when putting health data into one place.

2. Methods

To develop a mobile PHR (mPHR) application for use in emergency situations, a consortium was formed consisting of data-providing hospitals, data-utilizing hospitals, and an application developer. Three academic tertiary hospitals (AMC, SMC, and Dong-A Medical Center (DAMC)) with integrated full-scale hospital information systems, which were essential for providing data to build a system, participated as data-providing and data-utilizing centers. These hospitals are located in two large metropolitan cities, Seoul and Busan, and have different EMR systems that were established in 2003, 2005, and 2013. The annual numbers of visits to the EDs of these centers are 100,000, 130,000, and 35,000, respectively. These centers have about 2000, 2000, and 990 inpatient beds. The application developer (vTW) designed a service model, built a platform and cloud service, and operated the mPHR service. The three hospitals built the foundation for the extraction of personal data from the EMRs, standardized medical records, and data to be used in the application. In addition, two local secondary-care hospitals (Hyemin Hospital, Chung Hospital) that are closely related to the three hospitals were offered the data provided.

2.1. Design of the mPHR Service for Emergency Situations

2.1.1. Functions and Input Data That Were Considered Necessary

Prior to the development of the mPHR application, there was consensus among the participating researchers that the input data, screen, and functions should emphasize two main aspects: (1) patient ownership to generate and review their own health data and (2) utilization of the PHR data by healthcare providers in cases of emergency. The general design and development process are presented in Figure 1.

The data structure and functionality design of the mPHR were based on the PHR and Emergency Department Information System (EDIS) functionality standards of Health Level Seven (HL7). Essential functions and data for inclusion in the mPHR were adopted from existing PHR applications developed by the participating researchers at AMC and SMC [11]. The data structure and formats were standardized to the National ED Information System (NEDIS) registry, which is a national database of prospectively collected ED patient data from all emergency medical institutions in Korea [12,13]. Essential items for inclusion in the mPHR were chosen based on a survey collected from potential users, including ED staff, EMS personnel, and ED patients and their family members, using a structured questionnaire.

The final decision on the inclusion of functionality and data items was made through discussion between participating researchers in the three hospitals based on previous research and the survey results mentioned above. The functionalities were categorized into patient information, previous ED visit information, and patient-generated health data (PGHD). There were disagreements about the items for inclusion in the application; therefore, the decision was made to limit the number of items at the initial development and expand later as necessary.

After the basic function of the PHR application was established, to make the mPHR useful in an emergency situation, a novel application service should provide not only a PHR function with which a user can review his or her previous medical records in ED, but also a “disclosure” function that enables ED staff to access a user’s previous ED records in an emergency situation. A server for integrating and transferring multicenter data was built, and a private cloud with protected privacy that was verified for compliance with the relevant laws was used outside the three hospitals.

Prior to the new development, the expected user groups for the user-centered interface configuration were specified as being three groups: patients and caregivers, medical staff, and managers. Because the required functions are different depending on who the user is, the interface and main functions are configured differently by applying them when a user logs in. When patients and caregivers log in, the function to check and manage health records is implemented, while medical staff authenticate themselves and implement the function to receive and view patient records by URL. In addition, in the manager mode, the notification function and dashboard function for user management is implemented as the interface (

Table 1. Functionalities required for targeted user groups.

Targeted User Groups	Functionalities Required
Patient	Registration
	Log-in
	Personal information management
	Customer service center
	Health records (Home)
	Medication alarm
	Download of medical record
	“Disclosure” of medical record
	Record of health condition
	Record of self-checked blood pressure
	Emergency ID
	Inquiry of ED records
	Inquiry of laboratory test results
	Inquiry of urinalysis test result
	Inquiry of list of ED visits
	Set-up of data-shareable institution
	Set-up of shareable details
	List of data utilization and withdrawal of sharing SOS to care-taker
ED staff	Receiving temporary URL of “ED record summary” via e-mail or SNS
	Authentication
	Inquiry of “ED record summary”
	Inquiry of details of ED records
Manager	Management of service usage
	Management of notice
	Dashboard
Others	Easy-to-read terms
	Selective sharing method
	Safe data collection and utilization process
	Explicit consent before downloading
	Receipt of utilized data

ID: identification, ED: emergency department, URL: uniform resource locator, SNS: social network service.

).

The patient’s information includes name, age, gender, blood type, allergy history, and each hospital’s identification numbers. Previous ED history consists of hospital visited, visiting date, visiting time, vital signs at the time of visit, the International Classification of Disease-10 (ICD-10) code diagnosed in the ED, medication prescribed, and results of laboratory tests. The three hospitals have different EMR systems and data recorded, which are coded in different ways for each hospital. For interoperability and standardization of data, an NEDIS conversion method was used. The coding method used to send data to the NEDIS is universal in all EDs across the country. This method enabled various information that existed in different forms at each hospital to be converted into one form.

Similarly, data on medications prescribed in the ED are sent to the National Health Insurance, which also uses the electronic data interchange (EDI) code of the country’s single insurer. Further, information for each medication was mapped using data from the Korea Pharmaceutical Information Center.

There are technical limitations when trying to include all the laboratory tests; thus, the most frequent test items were extracted from the three hospitals’ data. Two ED doctors from each hospital (Y.C., I.H.K., J.K., J.-H.L., T.K., and W.C.) reviewed the whole list of extracted laboratory tests and discussed the clinical importance of the laboratory tests for making treatment decisions in the ED.

The items of the PGHD were determined by considering those items that are valuable for suspecting and diagnosing a disease in the ED.

2.1.2. Development of the System and Server

A server for each data-providing hospital linked to a main server and a private cloud was planned for the system. When selecting the private cloud, legal considerations and the system’s suitability were taken into account. There were several discussions with the computer experts of the three hospitals and the app developer, leading to the building of the MyData server, which connects to the main server.

2.2. Development of the Prototype

Based on the previous arrangement of the core data and function, the application developer (vTW) developed a prototype of the PHR application by laying out the screen, modeling the data, constructing the technical architecture, and designing the interface using a design toolkit (Sketch© 2020, online. Sketch B.V.). Through several meetings, the participating researchers from the three hospitals corrected and supplemented the prototype by providing feedback on the user interface, correcting typos, and showing how to indicate the reference values of the laboratory test results.

2.3. Development of the mPHR Application

The new mPHR application was developed and evaluated according to the four phases of the system development life cycle. According to this method, it proceeded as a process consisting of planning, analysis, design, and implementation. Each phase was reviewed and advised on by the participating researchers and revised by the application developers. Based on the modified prototype, standards for details were defined, and each unit module was developed. To design a user-centered screen, we targeted three groups of users: patients, ED staff, and program managers. Mobile Application Content Accessibility Guideline 2.0, a modification of the Web Content Accessibility Guideline 2.0 for implementation in Korea, was complied with by vTW. The mPHR application was developed with the Android Software Development Kit 28 using Android Studio 3.5 (Google LLC) and Swift 4.0 using Xcode 11© (1999–2020 Apple Inc.). The Spring tool suite 4© (2020 VMware, Inc.) was used to program the web service.

In order to comply with the Privacy Act of Korea, legal advice was sought at the time of app development.

2.4. Testing the New mPHR Application

The developed application was subjected to unit tests and integration tests. Unit tests were conducted twice by the computer experts of the three hospitals and the app developer on 20–27 September. The integration test was conducted twice on 4–11 October in the same way.

3. Results

We successfully introduced the FirstER (First for Emergency Room) platform on 23 September 2019. Moreover, it has been implemented in three tertiary hospitals since the launch date.

3.1. Services Provided by the Novel PHR Application for Emergency Situations: FirstER

3.1.1. Main Function

The user-centered screen was designed considering the main functions (Figure 2). The essential functions for the patient as the owner of the entire set of information include registration, management of his or her health record, download and viewing, disclosure of the PHR-tethered EMR of the hospital, contact with care providers, and setting of the degree of information disclosure. ED staff receive a temporary URL so that a patient’s information could be viewed within the limits allowed by him or her.

3.1.2. Data Provided by FirstER

Patients’ ED records (name, gender, age, diagnosis, vital signs, hospital visited, visiting date and time, etc.) coded by the NEDIS method were integrated among the three data-providing tertiary hospitals. Medication information coded by the EDI mapped with different drug codes from each hospital was successfully extracted. Twenty-nine items most frequently referred to by emergency physicians were selected for the most frequent test categories (

Table 2. Extraction and standardization of the most frequent laboratory examinations.

Sample	Name of Laboratory Test
Blood	White blood cell count
Blood	Hemoglobin
Blood	Platelet count
Blood	Absolute neutrophil count
Blood	Prothrombin time
Blood	Activated prothrombin time
Blood	Blood urea nitrogen
Blood	Creatinine
Blood	Total bilirubin
Blood	Gamma glutamyl transpeptidase
Blood	Alkaline phosphatase
Blood	Alanine transaminase
Blood	Aspartate transaminase
Blood	Amylase
Blood	Lipase
Blood	Sodium
Blood	Potassium
Blood	Uric acid
Blood	Hemoglobin A1c
Blood	Creatine kinase
Blood	Creatine kinase-myocardial band fraction
Blood	Troponin I
Blood	C-reactive protein
Blood	N-terminal pro-B-type natriuretic peptide
Blood	Brain natriuretic peptide
Urine	pH
Urine	Occult hematuria
Blood	ABO blood typing
Others	Influenza antigen immunoassay

). These data extracted from the hospital information system constituted a “core dataset” to be sent to the private cloud.

3.1.3. Developed System and Server of FirstER

Based on privacy legislation, the medical cloud zone, an IaaS (Infrastructure as a Service) provided by Samsung Data System (Seoul, Korea), met the facilities and equipment standards necessary for the management and preservation of EMRs, which is a requirement for the remote storage of EMRs. Data transmission and reception between the hospitals and the MyData cloud servers were linked by RESTful API (Representational State Transfer Application Programming Interface), SSL (Secure Socket Layer, https), and JSON (JavaScript Object Notation, data format). (Figure 3).

A patient sends subscriber information (patient hospital ID) to the hospital information system (HIS) through the private cloud platform when the patient agrees to subscribe to the mobile app and to the collection/use of their personal information. After validation of the subscriber information, the ED core data of the patient are extracted from the HIS server to the MyData-linked server in the hospital. Afterwards, when a patient requests “download”, the core data of the patient are transferred from the connected server in the hospital to the MyData cloud platform.

3.2. Pre-Operation Testing

Unit testing and integrated testing were conducted two times each. Twenty-two items out of a total of 79 in the first unit test were evaluated as inadequate, and all these items were supplemented and corrected in the second unit test. In the first integrated test, 81 items from seven categories (registration, PHR function, ED record, management, etc.) were accessed, and 18 items were evaluated as inappropriate. All items passed in the second integrated test.

3.3. Flow of Services

An app user who is a patient or caretaker launches this app and registers using his or her e-mail and password after consent of privacy (Figure 4A).

After login, the main page shows the user’s picture, name, blood type, drug allergies, and recent visits to the ED at a glance. Additionally, there are four items linked on the main page: details of medical records from recent ED visits, medication that has to be taken today, “My recent health condition”, and recent self-checked blood pressure. Additionally, there is an SOS button to directly call the patient’s care provider on the top left and a plus-shaped button that included items associated with the ED records at the bottom right (Figure 4B).

When the user inputs “My recent health condition”, the most recent record is displayed on the main page. The user can choose a part of the body that is uncomfortable and add a note. In the same way, a record of self-checked blood pressure is shown. The systolic and diastolic blood pressures can be entered separately (Figure 4C).

Upon touching a button labeled “I have to take medicines today”, the screen displays the hospital and department, day, medication and dosage, and frequency prescribed. Each medication button is linked to a page with a description of it (Figure 4D).

To use the functions of the EMR-tethered PHR, the user touches the plus-shaped button on the main page and then touches the “Download” button. When the user selects the hospital and inputs the hospital ID number, the existence of newly generated data is checked and any such data are downloaded. Downloaded data are displayed as a button labeled “I went to the ED several days ago” on the main page. When the user touches the button, details of the ED records from the EMR system of the selected hospital are seen. The user can see the time of the visit and discharge from the ED, diagnosis, department, results of blood and urine tests, and medications prescribed at discharge. If the user has several ED visit records, the user can press the "List" button at the bottom and check each entry (Figure 4B,E).

When the button labeled “Emergency ID” in the plus-shaped button on the main page is touched, it shows at a glance the information—namely, the patient’s name, gender, age, blood type, drug allergies, hospitals recently visited, caretaker information, and a document on the decision to withdraw from life-sustaining treatment—that is needed immediately in an emergency situation (Figure 4D).

Upon touching a button labeled “disclosure” in the plus-shaped logo on the main page, the user enters his or her password for authentication and then selects the institution and items to share. After that, the user sends a temporary URL (limited to 24 h) of their previous ED records via SNS or e-mail (Figure 4D).

By adding a function of selecting the institution and items to share in his or her medical record to the fundamental setting function, the user can choose whether to share sensitive medical information.

Based on advice from a legal executive, the patient is required to provide consent for several steps of installing, using, and withdrawing FirstER. Accordingly, there are no major legal problems in installing and utilizing FirstER.

3.4. Frequency of System Access and Utilization

From 14 October to 29 November 2019, the registration desks were operated in three EDs. While the desks were running, about 5100 patients were discharged at the EDs, and about 20% of the patients (1051 patients) installed the mobile app with informed consent. The number of EMR-tethered records that were downloaded per user request was 15,951 records in total. These records were categorized into visiting records, consultation records, laboratory records, operation records, and prescription records (

Table 3. Frequency of system access and utilization. Numbers indicate counts of EMR-tethered data provided during the study period.

Category of EMR-Tethered Data Provided	Samsung Medical Center	Asan Medical Center	Dong-A University Hospital	Total (%)
Visit	4523	1694	2398	8615 (54.0)
Consultation history	16	0	0	16 (0.0)
Laboratory test	2699	886	1636	5221 (32.7)
Operation history	10	0	2	12 (0.0)
Prescription data	1285	241	561	2087 (13.1)
Total	8533	2821	4597	15,951

EMR: electronic medical record.

). In two local secondary hospitals that only received data, there were a total of 22 downloads. Additionally, 265 cases had PGHD inputted.

4. Discussion

In this study, we introduced a newly developed mobile app, called FirstER, which enables the aggregation of data from three hospitals and yields PHRs to others if needed. Even though FirstER needs further validation, it demonstrates that mobile apps can enable interoperability between different sources of PHRs from different hospitals.

Medical record interoperability has been recognized to improve convenience and clinical outcomes for patients. With the rapid uptake of smartphones and the digitalization of medical records, healthcare services have planned the development of mobile health apps. Jung et al. previously introduced a mobile application to provide diabetes self-management, including cardio-cerebrovascular risk evaluation, stress evaluation, and an exercise tutor [14]. Wagner et al. evaluated the usefulness of PHRs for patients with hypertension and concluded that they might have a limited impact. However, these studies focused on non-emergency situations [15]. One pilot study announced the development of a mobile emergency app to improve interoperability between pre-hospital services and hospitals in a mass-casualty situation [16]. Although this application might be useful for emergency physicians, it was not intended for patients. To the best of our knowledge, FirstER is the first mobile app prototype for patients who visit the ED and use their PHRs at other hospitals in an emergency. Whenever patients unintentionally first visited nearby hospitals, FirstER enabled medical personnel to know about the patients’ previous underlying diseases, the reasons why they visited other hospitals, and what they were prescribed [17]. Furthermore, we also enabled patients to input their health records (i.e., patient-generated health data), such as conditions and blood pressure results, into FirstER, which then provided physicians with these data to help understand patients’ conditions [18]. Using wearable devices with FirstER could provide more expansive and diverse datasets to help clinicians with decision-making about care plans [19,20].

In this investigation, we focused on variables that are commonly useful for emergencies by analyzing the frequencies of prescriptions. Furthermore, emergency medicine physicians discussed with each other the clinical importance of the variables and reached a consensus on which ones to include. The parameters needed to be reliable, accurate, and easy to access. Regarding the selection of such parameters, we considered numerous issues. At first, we attempted to insert radiologic examinations, which could be helpful for efficient diagnosis and treatment. Nevertheless, the final version of the app did not contain such data because of storage and bandwidth issues. Radiologic reports without images were not provided because these frequently mislead both patients and physicians. Secondly, we also did not include the results of bacterial or viral cultures, including those for multi-resistance bacteria, sexually transmitted diseases, or new emerging infections. We thought that hiding such data could be problematic in specific situations. However, after reviewing Korean Privacy Act issues, we decided to exclude sensitive health records, including those relating to sexually transmitted diseases. This was largely because there tends to be a stigma in our country around revealing delicate past medical histories. Even though there were several limitations, as we mentioned above, FirstER is well-designed and developed for our initial purpose. The usability of this prototype may be expanded by having more participating hospitals, containing admission records, and having other medical data, such as radiological examinations. Moreover, further updates would focus on covering detailed data on chronic medical illnesses and recent emerging infectious diseases.

Research about the validity and reliability of FirstER has been progressing in another study with survey analyses from both healthcare providers and patients. It is promising that FirstER has already been downloaded more than 1000 times, and most responses to questions about usability in the pilot surveys have shown user satisfaction. Meanwhile, dissatisfaction, because the app was hard to use the first time, was one of the most common answers on the surveys, especially for those patients who were not familiar with using a smartphone. After developing FirstER and installing the app on a user’s device, there were some cases in which the app did not work due to conflicts between the app and certain versions of mobile phones. Most such problems were solved by stabilizing the cloud server and updating the app. However, the app did not work in very remote versions in a few mobile phones despite continuously updating the app. Furthermore, the patients need to follow multiple steps with many instances of giving informed consent to provide their records to physicians. These complicated processes are largely to protect the patients’ privacy; however, involving patients’ caregivers to introduce manuals for the app and further updates would improve usability.

With the developing platform for the mPHR, ED physicians could diagnose and treat their patients more quickly and efficiently, because problems similar to previous ones could be solved without duplicated tests. Fewer clinical tests due to decreased duplicated tests might have a positive effect on improving overcrowding in EDs, though this needs further evaluation. Previous studies reported that the turnaround time for laboratory and radiologic tests negatively impacts ED overcrowding and length of stay [21,22]. Improving the quality of care and enhancing the safety of patients is multifactorial, and one of the most effective ways to diminish overcrowding can be by avoiding unnecessary laboratory and imaging examinations [23]. Future studies need to focus on which information on the PHRs can improve patient outcome. Also, research on PHR-based emergency medical services can further progress by expanding the mobile app.

Categorizing the data provided, it was found that the app users requested their laboratory results in addition to the visit data that are provided by default.

We noticed several limitations while developing and applying FirstER. First, the patients’ usability and satisfaction might be lower than expected because a relatively small number of hospitals participated. If the clinical data could be connected between tertiary hospitals and primary clinics, the app’s usability would be improved. For example, patients with mild infectious illnesses or simple minor trauma cases could provide their laboratory results and prescriptions to their primary healthcare provider through this app after adequate treatment in the emergency department. However, FirstER is the first platform in an emergency to support interoperability between hospitals, and further study could make it possible to share PHRs at many hospitals. Second, data for radiologic examinations, such as simple radiographs, computed tomography, and magnetic resonance imaging, could not be provided because of limited storage and bandwidth. Third, there were some reports of errors during the uploading and downloading of data in the mobile app. These errors were mostly because of the different existing platforms between hospitals and different data types with test codes. However, these technical challenges were recognized in the early phase and fixed by standardizing the data from each hospital. Fourth, this app only covered the clinical data from the emergency department. Information during admission could be more informative, especially for patients admitted for a long duration. Regretfully, this app was a prototype and only included the medical records from the emergency department, including laboratory results, presumed diagnosis, and prescriptions at time of discharge from the emergency department. A future study is planned to update the app to include clinical data during admission. Lastly, we could not evaluate the clinical impacts of the mobile application, such as mortality or length of ED stay, due to the short study period.

5. Conclusions

In this study, we developed and successfully implemented an mPHR service that can be used as a health information exchange tool in emergencies by integrating medication information from three different tertiary hospitals. By recognizing the significance and limitations of this service, it is necessary to study the development and implementation of mPHR services that are more suitable for emergency medical services.