IntroductionBackground

Vital signs have been an important indicator in many studies [-]. In recent years, researchers have used these data in studies of predictive models for in-hospital cardiac arrest (IHCA) [,]. In a real-world medical workflow, complete data may be obtained once every 4 to 8 hours. In the machine learning research related to vital signs [], the features include heart rate, temperature, respiratory rate, systolic blood pressure, and diastolic blood pressure. In addition to IHCA risk assessment, data analysis systems [] and early warning systems [] are still indispensable applications.

Although IHCA risk indicators have facilitated breakthroughs in machine learning [,], it has been difficult to integrate them into the workflow of medical staff. In hospitals, there are dozens of systems that must exchange information with each other. Without a standard exchange interface [], the integration process is costly and time-consuming when a new application is imported. In addition, if medical researchers are allowed to access patient data directly through the health care information system database, security risks [] become a concern.

To begin initiating a human-readable and user-friendly interface for medical staff, Health Level 7 [] developed Fast Healthcare Interoperability Resources (FHIR) []. FHIR is a platform specification that defines a set of capabilities used across the health care processes, and it defines a generic health care business entity model that uses resources as the basic blocks. Each resource in FHIR has a defined relationship resource with data elements and constraints. In addition, the FHIR profile standardizes the data format and structure constraints. During data transportation, it uses the HTTP RESTful application programming interface (API) in the exchange interface and provides the flexibility to choose between JSON or XML format in the data payload.

Aim

Although FHIR have developed some of the resources, a vital signs profile [] has not yet matured. The current implementation guide provided by FHIR is insufficient to encompass the full range of medical system applications; therefore, hospitals still need to define the customized implementation guide to develop their system and workflow. The implementation guide is a collection of rules applied by FHIR resources [] that requires a clear explanation of how to solve a particular problem. In the relevant studies on FHIR [-], each paper develops and discusses a single customized resource profile on a mobile device. Although FHIR can effectively and rapidly improve health care information system interoperability, it still has not proposed an implementation guide for the machine learning application in FHIR implementation guide registry. To accelerate the development of smart health care, we propose a system architecture process based on FHIR that can integrate the machine learning models. Besides, the vital signs applications are distributed in many different systems. This study can effectively solve the complexity of the system in the medical staff workflow.

To standardize the format among medical systems, we developed a complete IHCA implementation guide based on FHIR that defines the vital signs–related data for both the early warning system and the machine learning pipeline. In addition, we also developed FHIR Extract Transform Load (ETL) and other FHIR-related applications, including data management, an early warning system, and a machine learning pipeline.

MethodsEthics Approval

This study was approved by the Institutional Review Board of the En-Chu-Kong Hospital (ECKIRB1071001). We confirm that all experiments were performed in accordance with relevant guidelines and regulations. The data retrieved from electronic health records (EHRs) were deidentified by an IT specialist and could not be linked to the patients’ identity by the research team. The need for written informed consent was waived and confirmed by the En-Chu-Kong Hospital Institutional Review Board, because this was a retrospective cohort study with deidentified data.

Overview

Our study provides a design and implementation process for IHCA-based interoperability of health care information systems, and our design steps include use cases as well as the IHCA implementation guide.

In the use cases section, we describe the integration issues faced by health care institutions. Then, in the IHCA implementation guide section, we introduce the method used to migrate data from the healthcare information system (HIS) database to the FHIR server as well as a method for mapping the data to the FHIR resources. We also develop the 3 application systems, which include data management, early warning systems, and a machine learning pipeline. If used according to our implementation guide, the applications can easily obtain patient information and vital signs data.

Use Case Survey

In health care institutions, the database is centrally managed, but the applications are developed by many different teams. In addition, medical staff usually access all of the required information about a workflow through a single system. Therefore, the interoperability of health care systems is very important.

To achieve system information interoperability [], the HTTP RESTful API was defined to exchange data with other systems. However, many medical systems are legacy systems, and in many cases, it is impossible to change the system architecture. We therefore created a table view for the HIS database to allow other systems to obtain particular data. To avoid affecting the original system architecture, we developed FHIR ETL to convert data from the HIS database to the FHIR server, and FHIR ETL was implemented according to the rules defined by the IHCA implementation guide.

We interviewed 10 experts regarding health care system integration and information exchange. As shown in , FHIR, which has a good medical standard interface, is very suitable for solving the interoperability problems faced by medical information systems. In addition, it supports a variety of systems that can be used to develop extended applications.

Therefore, we have 2 use cases. The first use case is related to data migration for the FHIR server, as shown in (Part A). The second use case is related to FHIR applications, as shown in (Part B).

Table 1. Requirement list from health care specialists in health care institutions.Issue (requirement)How to do it?The new system integration process shall not affect the health care information system or the vital signs system.Build the FHIRa server as a new middleware or gateway so that researchers can access data.Converting the EHRsb with vital signs into FHIR resources.Develop the FHIR ETLc.To reduce the time cost and compatibility, we need to use a health care information interoperability standard.Use FHIR resources and the RESTful APId.The field needs an early warning system that can continuously monitor the patient’s vital signs.Use FHIR to develop the early warning system.How can an organization integrate the prediction model into the medical workflow?Use FHIR to develop the machine learning pipeline.The field needs a complete implementation procedure and use case.Define an FHIR implementation guide.

aFHIR: Fast Healthcare Interoperability Resources.

bEHRs: electronic health records.

cETL: Extract Transform Load.

dAPI: application programming interface.

‎Figure 1. Use cases for IHCA research and application. (A) Extract the data and transfer them to the FHIR server. (B) Data management for data processing, early warning system for notification and model trigger, and machine learning pipeline for model prediction and model training. API: application programming interface; ETL: Extract Transform Load; FHIR: Fast Healthcare Interoperability Resources; HAPI: Health Level 7 application programming interface; HIS: healthcare information system; IHCA: in-hospital cardiac arrest. View this figureIHCA Implementation Guide

In this phase, we need to consider the data format so that raw data can be transferred into FHIR resources as well as how the HTTP RESTful API can be used to easily obtain data. Therefore, we designed a system architecture (). We divided the system steps into the following: (1) the FHIR ETL performs data conversion and comparisons between the HIS database and the FHIR server, and (2) the application system accesses data directly through the FHIR API interface at the HTTP layer.

Data Mapping—FHIR ETL

We proposed the data mapping table to develop the FHIR ETL, as shown in . We defined the data mapping and resource relations. Based on the FHIR vital signs profile, we used the observation resource to store systolic blood pressure, diastolic blood pressure, heart rate, respiratory rate, and body temperature. According to , FHIR ETL can extract the data from the HIS database and transfer them to resource content.

Table 2. The data mapping table of the FHIRa ETLb in this study.Data model of HISc databaseFHIR resource nameFHIR resource attributeDescriptionPatient_IDPatientidentifierAn identifier for the patient in the hospitalPatient_namePatientnamePatient’s name that is human-readableGenderPatientgenderPatient’s genderBirthDatePatientbirthDatePatient’s birth datePractitioner_IDPractitioneridentifierAn identifier for the physician in the hospitalPractitioner_namePractitionernamePhysician’s name that is human-readableOrganization_IDOrganizationidentifierAn identifier for the department in the hospitalOrganization_nameOrganizationnameDepartment’s name that is human-readableLocation_IDLocationidentifierAn identifier for the location in the hospitalLocation_nameLocationnameLocation’s name that is human-readableHeart rateObservationvalueQuantity.valueHeart rateTemperatureObservationvalueQuantity.valueTemperatureRespiratory rateObservationvalueQuantity.valueRespiratory rateSystolic blood pressureObservationvalueQuantity.valueSystolic blood pressureDiastolic blood pressureObservationvalueQuantity.valueDiastolic blood pressureTimestampObservationeffectiveDateTimeThe created time of the value

aFHIR: Fast Healthcare Interoperability Resources.

bETL: Extract Transform Load.

cHIS: healthcare information system.

In , in terms of data acquisition, if an FHIR client wants to obtain a patient’s location, it needs to first obtain the patient’s ID and join the encounter subject. Then, it can use the encounter location to find the location resource. Finally, the FHIR client can obtain the patient location.

In , the FHIR client can perform the following: (1) when an FHIR client needs to access a particular patient using metadata, it can use the HTTP GET method to obtain the Bundle resource response; (2) when an FHIR client wants to update the location name for the hospital, it can use the HTTP PUT method to update the Location resource; and (3) after the FHIR client obtains sufficient vital signs data from the Observation resource, it can use the HTTP DELETE method to delete the resource that is missing vital signs values.

‎Figure 2. Data mapping and resource relationships in the IHCA implementation guide. ETL: Extract Transform Load; FHIR: Fast Healthcare Interoperability Resources; HIS: healthcare information system; IHCA: in-hospital cardiac arrest. View this figure‎Figure 3. FHIR (Fast Healthcare Interoperability Resources) application, which uses the HTTP RESTful API (application programming interface) to control the data on the FHIR server. View this figureWorkflow Design

In this section, we describe the complete workflow of FHIR implementation. Workflow 1 develops the data mappings for the FHIR resources. First, the FHIR ETL uses the database connection library to access the table view of the HIS database. Then, it verifies that the patient’s information exists. To maintain data consistency, when converting to the Observation resource, the system must add the universally unique identifier of Patient resource as a reference link. If the patient’s basic data already exists, the vital signs will be converted into an Observation resource based on the FHIR vital signs profile.

Workflow 2 develops the data acquisition process for FHIR applications. First, the FHIR application can use URL (/Patient) with the HTTP GET method to access the Bundle resource. In the Bundle resource, the FHIR application can find all of the patient’s data. If the FHIR application needs to obtain patient information such as location and practitioner information, it can use the Patient ID to join the Encounter subject. Then, it can obtain the Encounter participant and Encounter location. Finally, it can also use the Patient ID to join the URL (/Observation?subject=) with the HTTP GET method to obtain the Observation resource ().

‎Figure 4. Workflow of the Fast Healthcare Interoperability Resources (FHIR) Extract Transform Load (ETL) and the FHIR client application. HIS: healthcare information system; UUID: universally unique identifier. View this figure
ResultsFHIR Resources

The FHIR ETL is an automation service that extracts vital signs. When the vital signs system stores the data in the HIS database, the FHIR ETL can access the vital signs data immediately, and as shown in , it adds the vital signs to the Observation resource. shows examples of an FHIR resource that refers to an FHIR vital signs profile and other resources.

Software Development

We describe the software development, which is shown in . The HIS database was developed using the SQL server database and the Oracle database server. The FHIR server was installed on the Health Level 7 API FHIR R4 server (version 6.1.0) [] with a docker container based on the Java environment. This open-source system is widely used. We developed the back-end service of the FHIR ETL using Python software (version 3; Python Software Foundation), and the machine learning pipeline was implemented using Flask. The front-end website was constructed using Vue.js and is used for IHCA web management.

‎Figure 5. System architecture used in this study. API: application programming interface; ETL: Extract Transform Load; FHIR: Fast Healthcare Interoperability Resources; HAPI: Health Level 7 application programming interface; HIS: healthcare information system; IHCA: in-hospital cardiac arrest; MLP: machine learning pipeline. View this figureSystem Implementation

The study data set [] included the EHRs of adult inpatients who visited the En-Chu-Kong hospital. Medical staff regularly measured these vital signs at least 2 to 3 times per day during the day, night, and early morning. The total number of patients was 16,865, and the number of patients with IHCA was 118.

We converted the 5 vital signs into FHIR observations in JSON format using FHIR ETL. These vital signs include systolic blood pressure, diastolic blood pressure, heart rate, respiratory rate, and body temperature. For demonstration, we used pseudonymization [] to protect the patient’s privacy. Furthermore, we divided the proposed system into the following 3 components: data management, an early warning system, and a machine learning pipeline. In terms of data management, as shown in , we developed a data static dashboard so that it can be accessed by medical staff using a browser. The dashboard uses the HTTP GET method to obtain both the Patient and Observation resources. Then, the patient’s vital signs over the previous 48 hours are displayed. In the early warning system, medical staff can set the vital signs alert threshold to decide whether to show the alert in the notification list as shown in . Then, the machine learning pipeline exports the vital signs data from the Observation resource to the FHIR server. We integrated a long short-term memory network–based model [] using vital signs data to predict IHCA. It used the time series early warning score, which used heart rate, systolic blood pressure, and respiratory data. When the training process of the prediction model is initiated, the status “in progress” will appear in MongoDB. After model training, the status will be updated to “final,” and the dashboard will show the latest accuracy of the model. The proposed dashboard is shown in . However, the system can be used on mobile devices as well as desktop computers. We followed the Responsive Web Design [] to design a user-friendly mobile interface ().

‎Figure 6. Screenshot of the data management overview in the dashboard. View this figure‎Figure 7. Screenshot of the early warning system’s notification overview. View this figure‎Figure 8. Screenshot of the machine learning pipeline including prediction and training. DEP: department; IHCA: in-hospital cardiac arrest. View this figure‎Figure 9. User interface developed using Responsive Web Design for mobile devices. IHCA: in-hospital cardiac arrest. View this figure
DiscussionPrincipal Findings

In this paper, we piloted the use of an implementation guide that combines IHCA with vital signs, which have been widely adopted in IHCA assessment [,] and play an important role in inpatient deterioration detection. Many health care institutions have developed early warning score systems to identify hospitalized patients that are at risk of deterioration, and in recent years, they have begun to incorporate machine learning–based models into this process. To promote system interoperability, we used the FHIR standard to achieve consistent information exchange. We also combined 5 resources (Organization, Location, Practitioner, Patient, and Encounter) to represent the EHR. Then, based on the FHIR vital signs profile, we exported vital signs data to HIS database and defined the IHCA implementation. In addition, we developed the 3 FHIR applications of data management using a dashboard, a real-time early warning system, and a machine learning–based pipeline. According to the IHCA implementation guide, our proposed system makes it easy to integrate vital signs–related applications.

Limitations

The implementation guide was only developed for vital signs–related studies. However, some case studies still need to include treatment history [], blood urea nitrogen [], and creatinine []. These further improvements can be made to the EHR.

Comparison With Prior Work

Despite the result that indicated that FHIR can improve the interoperability of health care information systems [-], existing studies have only developed the resource and profiles. Seong et al [] demonstrated how quality information regarding clinical next-generation sequencing genomic testing can be exchanged in a standardized format by profiling an FHIR genomic resource and developing an FHIR-based web application that exchanges quality information. Based on the human-centered design methodology, Park et al [] developed a worker-centered personal health record (PHR) app for occupational health. The PHRs were managed through a cloud server using Azure API for FHIR, and the PHR FHIR resources included Patient, Organization, DiagnosticReport, Observation, Practitioner, Condition, Procedure, MedicationStatement, Medication, and Encounter. In addition, Chukwu et al [] profiled FHIR resources for maternal and child health referral use cases. Our study is distinguished from these previous works because we provided the IHCA implementation guidance regarding the use of FHIR resources as a conduit for the data required by the early monitoring system and machine learning. We also proposed a minimum requirements data model and combined it with the FHIR standard. To integrate the early monitoring system and machine learning, we based them on the FHIR vital sign profile and many FHIR resources to extend the data model. Besides, the related studies focus on new application development. In this study, we focus on legacy system integration, so we transfer and synchronize data through FHIR ETL.

Conclusions

We successfully demonstrated a process that standardizes health care information for inpatient deterioration detection using vital signs. Based on the FHIR definition, we provided an implementation guide that includes data mapping, an integration process, and IHCA assessment using vital signs. We also provided a clarified system architecture that can be used to develop clinical decision support systems. Based on FHIR, we integrated the 3 different systems into 1 dashboard system, which can effectively solve the complexity of the system in the medical staff workflow.

This paper was partly supported by the Ministry of Science and Technology, Taiwan (grant 10X-62634-F-002-015). The authors acknowledge the support.

None declared.

Edited by M Focsa; submitted 04.09.22; peer-reviewed by A Nassirian, R Saripalle, T Zhang; comments to author 20.09.22; revised version received 22.09.22; accepted 03.10.22; published 13.10.22

©Tzu-Wei Tseng, Chang-Fu Su, Feipei Lai. Originally published in JMIR Medical Informatics (https://medinform.jmir.org), 13.10.2022.

This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on https://medinform.jmir.org/, as well as this copyright and license information must be included.