The functions recommended by respondents from health organizations included functions related to access to health records for patients, such as viewing diagnostic data, laboratory and examination results, and medical history:

Respondents also mentioned the need for a function to view health facility profiles, such as the list of services and the availability of beds. Other recommended functions were paying for medical expenses, billing, and claiming health insurance:

Respondents also suggested the need for a function for patients to manage information related to medication consumption, such as viewing the history of medication that has been consumed, ordering medication, and scheduling medication consumption:

Another recommended function was a feature that patients can use to interact or communicate on the web with medical personnel in health facilities. Communication can occur through chat, messages related to health consultations, or video calls:

In addition, respondents mentioned the need for features for patients to manage appointments with medical personnel at health facilities. With this feature, patients can register themselves for treatment at health facilities, including choosing a physician:

Respondents also recommended a function for patients to access disease-related information and health tips, such as how to maintain a healthy lifestyle. Others suggested a function for patients to manage their health data to support preventive health efforts or disease prevention. In addition, this function could assist in the recovery from certain diseases that require ongoing health management activities. For example, patients could input data on vital signs and physical activities:

In addition to functional requirements, respondents mentioned the need for PHR integration. PHR functionality can be integrated with health applications or other existing data sources, such as electronic medical records in health facilities, to obtain medical summaries, such as diagnoses, laboratory and examination results, and medical history. PHRs also need to be integrated with the referral information system (sistem informasi rujukan terintegrasi) to obtain patient referral history and integration with vaccine data, especially for needs during the COVID-19 pandemic:

PHRs also need to be integrated with BPJS Kesehatan for JKN patients and integrated with web-based payments for patients who seek treatment at health facilities and do not use health insurance:

PHRs can be integrated with teleconsultation applications for communication between patients and medical personnel, as well as with pharmacies for ease of ordering medicines. In addition, for the convenience of monitoring personal health data such as physical activities, PHRs need to be integrated with wearable devices. Moreover, PHRs need to be integrated with the healthy family or Program Indonesia Sehat dengan Pendekatan Keluarga application to support healthy family programs at the Puskesmas and with the national health data repository owned by the Ministry of Health:

Respondents also mentioned security aspects that need to be applied to PHRs, such as access control, audit trails, data encryption, and data backup. Authentication and authorization are needed in the implementation of PHRs. An audit trail is required to review who is accessing and what data have been accessed in the PHR. A data backup option is required to avoid the risk of data loss. In addition, PHRs need to implement important data encryption, such as passwords:

PHRs need to implement user manuals or guidance options to help users understand the information contained in them. In addition, PHRs need to have customization options based on the availability of the internet network as several regions in Indonesia have poor internet connections:

A total of 70.06% (709/1012) of respondents had used health applications, whereas 29.94% (303/1012) had never used health applications. For each respondent who had used a health application, the questions asked were the health application used, the platform used to access the health application, the length of use of the health application, the frequency of use of the health application in the last 6 months, the features used in the health application, reasons for using health applications, challenges when using health applications, organizations that must be integrated or connected with health applications, and the most important components of a health application (Multimedia Appendix 4).

Respondents were also asked to rate how important the PHR functionalities were based on the previous review (Harahap et al [5]), which comprised health records, administrative records, medication management, communication, appointment management, education, self–health monitoring, and supporting function. The functionality codes for each PHR module are summarized in Multimedia Appendix 5. Respondents were asked to provide an assessment with the following scores: 1=Very Not Important, 2=Not Important, 3=Optional, 4=Important, and 5=Very Important. The mean was then calculated for each functionality. If the mean of the functionality was <4, then the functionality did not need to be implemented in the integrated PHR model. On the basis of the results of the questionnaire, 27 functionalities had a mean of >4. However, the functionality of sending messages or chatting with support groups and family members in the PHR application (Communication_03) and the functionality to connect wearable devices with the PHR application were considered important by fewer respondents (SelfHealthMonitoring_05), with a mean of <4. Figure 2 shows the respondents’ scores for each PHR functionality.

The requirements of health organizations and patients were grouped into PHR modules and functionalities based on the study by Harahap et al [5], which comprised health records, administrative records, medication management, communication, appointment management, education, and self–health monitoring. In addition, there were emergency modules obtained from patients’ requirements as well as security modules and supporting functions to meet the nonfunctional requirements of PHRs. In the health record module, there were functions to view the results of medical examinations, medical history, referrals, and vaccinations. In the administrative records module, there were functions for patient profiles, health facility profiles, physician profiles, health insurance, and payments and billing. In the medication management module, there were functions for medication history, medication reminders, and medication orders. In the communication module, there was a messaging function (SMS text message or video call). In the appointment management module, there were functions for registration, appointment history, reminders or notifications, and ambulance. In the education module, there was a health article function. In the self–health monitoring module, there were health data tracking functions, health dashboards, health calculators, and early warning notifications. In the emergency module, there was an emergency contact function. In the security module, there were authentication, authorization, audit log, and backup functions. In the supporting function module, there were user manual and offline functionalities. A summary of the PHR module and functionality based on the requirements of the respondent group is provided in Multimedia Appendix 6.

This study used The Open Group Architecture Framework (TOGAF) to design the architecture of an integrated PHR system in Indonesia. On the basis of previous studies, TOGAF provides a complete process and methodology to develop architecture [31]. Moreover, TOGAF is the most suitable architectural framework for application in the health sector as it provides a complete architectural development process and can be adapted to the health sector [32,33]. The TOGAF referred to in this study is the TOGAF version 9.2. The Architecture Development Method in the TOGAF can be modified to suit specific needs [34]. In this study, the scope of architectural development was to design information system architecture. Therefore, the TOGAF components needed comprised architecture vision, business architecture, application architecture, data architecture, and technology architecture as required components in designing information system architecture [35].

According to the TOGAF 9.2, an architectural vision is a brief description of the target architecture that describes the business value and changes that will result from successful implementation. Architectural vision serves as a vision and boundary in the development of a more detailed architecture [34]. The value that is expected to be provided by the integrated PHR is a complete medical history by allowing patients to obtain medical information from different health facilities. Integrated PHRs can also minimize unnecessary health examinations as patients can share their medical history with their physicians so that physicians have information about previous examinations that have been carried out by patients. In addition, the integrated PHR facilitates communication between patients and physicians and helps patients with administrative activities such as registration, appointments, and payment of medical expenses. Integrated PHRs can also help patients manage health outside the health care environment, such as tracking food consumption and physical activity according to the patient’s needs and health conditions.

On the basis of the user requirements and literature review, we formulated architecture principles for integrated PHRs in Indonesia following the TOGAF 9.2 (Table 2). These comprise business, data, application, and technology principles [34]. The business principles comprise information management as everybody’s business, business continuity, service orientation, compliance with the law, and patient-centeredness. Data principles comprise data being an asset, shared, and accessible; common vocabulary and data definitions; and data security. Application principles comprise technological independence and ease of use as well as functionality completeness. The technology principles comprise interoperability and ease of access.

Business architecture defines the business strategy, governance, organization, and key business processes [34]. On the basis of the interviews with participants from health facilities and a review of health regulations in Indonesia, the business process for PHRs can be divided into health care business processes, self–health monitoring business processes, vaccination business processes, and home care business processes. Each of these process flows can be seen in Multimedia Appendix 7. The main parties involved in the PHR are patients, physicians, health facilities, laboratories, the Palang Merah Indonesia or Indonesian Red Cross (PMI), BPJS Kesehatan or other private health insurance companies, and pharmacies.

On the basis of the flow of the process, we added a rich picture to describe the data exchange on PHRs in the health care process (Figure 3). Patients register to make visits to health facilities or laboratories. Patients who need blood donors can also submit a blood donation request to the PMI. Patients can share their health records or personal health monitoring data with their physicians. Patients who have received health services will receive their data in the PHR. Patients can connect the PHR with wearable devices to record personal health monitoring data. Patients can connect the PHR to BPJS Kesehatan or other health insurance companies to obtain their status. Patients can communicate with their physicians or receive their prescribed medicine at pharmacies through the mHealth apps or teleconsultation applications that are connected with the PHR. Moreover, patients can receive vaccination data through the PHR, which is linked to the Ministry of Health vaccine data (satu data vaksinasi). The PHR can also connect with an integrated emergency management system (sistem penanggulangan gawat darurat terpadu) to obtain the nearest emergency service contacts.

The TOGAF 9.2 defines application architecture as a blueprint for the applications to be developed, their interactions, and their relationship to the organization’s core business processes [34]. On the basis of the results of interviews and questionnaires, parties that need to be integrated into PHRs are primary health facilities (Puskesmas and clinics), referral health facilities (government and private hospitals), health laboratories, pharmacies, satu data vaksinasi, mHealth app or teleconsultation application providers, BPJS Kesehatan, private health insurance companies, and the Ministry of Health. In addition, PHRs need to have the option to connect with wearable devices for tracking health data and family members. On the basis of the results of the business architecture design, other parties that need to be integrated with PHRs are PMI and the integrated emergency management system (sistem penanggulangan gawat darurat terpadu). Health facilities are the parties that are most integrated with the information in the PHR. The PHR is integrated with hospital information systems (sistem informasi manajemen rumah sakit) in referral health facilities and primary health care information systems (sistem informasi puskesmas) in primary health facilities to access health records. In addition to hospital information systems (sistem informasi manajemen rumah sakit) and primary health care information systems (sistem informasi puskesmas), the PHR is integrated with an integrated referral information system (sistem informasi rujukan terintegrasi), which is used by health facilities in Indonesia to access patient referrals. Especially for Puskesmas, the PHR can be integrated with the Program Indonesia Sehat dengan Pendekatan Keluarga information system. Figure 4 summarizes the integration of the PHR with health information systems or health care providers in Indonesia.

The modules in the PHR comprise health records, administrative records, medication management, communication, appointment management, education, self–health monitoring, security, supporting functions, and emergency. In the health record module, the functionalities comprise a medical summary (results of physical examinations and medical support as well as disease and medication history), referrals, and vaccinations. This module also adds the functions of family planning, home care, and blood donors based on the identification of activities in the business architecture. In the administrative record module, the functionalities comprise patient profiles, health facility profiles, health personnel profiles, health insurance, and payments and billing. In the medication management module, the functionalities comprise medication history, medication reminders, and medication orders. In the communication module, the functionalities comprise messaging. In the appointment management module, the functionalities comprise registration, appointment history, reminders, notifications for appointments, and ambulance services. In the education module, the functionalities comprise health articles containing information on disease problems and health tips. In the self–health monitoring module, the functionalities comprise health data tracking, health dashboards, health calculators, and alert notifications. In the emergency module, the functionalities comprise emergency contacts.

We also designed the modules and functionalities to meet the nonfunctional requirements of PHRs. The modules comprise security and supporting functions. In the security module, the functionalities comprise authentication, authorization, audit logs, and data backup. In the supporting function module, the functionalities comprise user manual and offline functionality. The functionalities that need to be prioritized for implementation in PHRs are functions related to health management (health care, health prevention, and health promotion) and functions to support information security, whereas other functionalities such as functions related to administration and supporting functions are optional. To access the PHR, the platform used is a smartphone as, based on the results of the questionnaire, it is the most widely used platform by the public to access health applications. Figure 5 summarizes the integrated PHR system model in Indonesia.

The TOGAF 9.2 defines data architecture as the logical and physical structure of the organization’s data assets and data management resources [34]. We grouped data in PHRs into 3 data categories comprising master, transaction, and reference data [38,39]. Transaction data relate to data that are recorded every time a transaction occurs, such as medical records, vaccinations, and health referrals. Master data are data that do not change and do not need to be recorded in every transaction, such as patient and health facility data. Reference data are a collection of values or classifications that can be referenced by master and transaction data.

The technology architecture for PHRs is described in the form of a high-level architecture to illustrate the technology required for PHR implementation and integration with other systems (Figure 6). Patients or individuals access the PHR through a mobile app. PHR development uses the React Native cross-platform app development that can be implemented on the Android or iOS platforms. The PHR application is accessed by users via the internet, and a firewall is used for security. The PHR server comprises an application server and a database server. The application server provides access to data for the user, whereas the database server provides the data requested by the application server [40].

An application programming interface (API) is used as an intermediary for interaction between the PHR and other information systems. The type of API used is Fast Healthcare Interoperability Resources (FHIR). FHIR is an international standard recommended by the Ministry of Health to solve the problem of data exchange in health information systems in Indonesia [17]. FHIR is flexible and can be adapted to stakeholder needs, clinical specifications, and health policies. FHIR can be used to manage a single data entity (eg, heart rate), groups of data entities (eg, vital signs, medications, and allergies), or electronic recording systems such as PHRs. Therefore, FHIR is suitable for exchanging data on PHRs as PHRs aim to collect and exchange individual health data [41].