## 2 Methods
### 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. Figure 1: Process overview for mPHR for emergency departments (PHR: personal health record, EMS: emergency medical service, mPHR: mobile PHR). 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). 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