Mapping Injection Order Messages to Health Level 7 Fast Healthcare Interoperability Resources to Collate Infusion Pump Data

Abstract

Background When administering an infusion to a patient, it is necessary to verify that the infusion pump settings are in accordance with the injection orders provided by the physician. However, the infusion rate entered into the infusion pump by the health care provider cannot be automatically reconciled with the injection order information entered into the electronic medical records (EMRs). This is because of the difficulty in linking the infusion rate entered into the infusion pump by the health care provider with the injection order information entered into the EMRs.

Objectives This study investigated a data linkage method for reconciling infusion pump settings with injection orders in the EMRs.

Methods We devised and implemented a mechanism to convert injection order information into the Health Level 7 Fast Healthcare Interoperability Resources (FHIR), a new health information exchange standard, and match it with an infusion pump management system in a standard and simple manner using a REpresentational State Transfer (REST) application programming interface (API). The injection order information was extracted from Standardized Structured Medical Record Information Exchange version 2 International Organization for Standardization/technical specification 24289:2021 and was converted to the FHIR format using a commercially supplied FHIR conversion module and our own mapping definition. Data were also sent to the infusion pump management system using the REST Web API.

Results Information necessary for injection implementation in hospital wards can be transferred to FHIR and linked. The infusion pump management system application screen allowed the confirmation that the two pieces of information matched, and it displayed an error message if they did not.

Conclusion Using FHIR, the data linkage between EMRs and infusion pump management systems can be smoothly implemented. We plan to develop a new mechanism that contributes to medical safety through the actual implementation and verification of this matching system.

 

MissingLinkText

Keywords

infusion pump - data linkage - HL7 FHIR - REST - API - health information exchanges - SS-MIX - standard mapping

Background and Significance

When administering drugs to patients, it is necessary to verify that the prepared drugs are correct to prevent accidents due to human error or communication errors by medical personnel.[1] In particular, when preparing liquid oral medications, the widely accepted 5Rs (right patient, right drug, right dose, right route, and right time) should be confirmed at the time of drug preparation and immediately before administration to ensure patient safety. This concept was introduced by Sullivan in 1991.[2] In Japan, the Japan Council for Quality Health Care recommends that the 6Rs (5Rs plus right purpose) should be confirmed at the time of administration.[3]

In general, hospitals that have implemented an ordering system that uses the following method to verify that the drug to be administered is correct: affixing an injection label based on the injection order to the infusion bag and reading the printed barcode to compare it with the injection order information. However, when implementing infusion therapy using an infusion pump, the infusion rate must be set on the device independently from the preparation of the drugs and infusion bags. Therefore, incidents of overdosing or underdosing may occur because of numerical setting errors. Infusion pumps are natural medical devices that operate independently; therefore, devices that have the ability to work with an ordering system are rare. Furthermore, there are few examples, other than reports of prototype development, of the ability to match the contents of injection orders managed by an ordering system.

 

MissingLinkText

Objectives

This study investigated a data linkage method to reconcile infusion pump settings with the contents of the injection order to ensure patient safety. Specifically, Health Level 7 (HL7) version 2-based structured injection order messages stored in Standardized Structured Medical Information Exchange version 2 (SS-MIX2)[4] [5] using International Organization for Standardization (ISO)/technical specification (TS) 24289:2021 were converted to HL7 Fast Healthcare Interoperability Resources (FHIR).[6] Then, this order information was stored in the FHIR repository database. Next, using a Web application programming interface (API) created based on the concept of REpresentational State Transfer (REST), hereafter called the RESTful API, we developed and implemented a mechanism to link data with the infusion pump management system. We then verified whether the infusion pump settings could be matched with the injection order information. This was not a study of a “smart pump”[7] [8] [9] [10] [11] that automatically adjusts the drug speed and dosage; instead, we collected information from the infusion pump and used it for a injection order matching process. Although the linkage of data with smart pumps is innovative, it is not practical to obtain approval from the Japanese regulatory agency, the Pharmaceuticals and Medical Devices Agency.[12] In this study, we decided to implement the proposed method in view of the possibility of allowing more widespread application.

 

MissingLinkText

Methods

A schematic of the scope of development of this study is shown in [Fig. 1]. This study was conducted in agreement with the University of Tokyo Hospital and Nipro Corporation. This study aimed to confirm that data linkage using FHIR could be achieved by converting the order information obtained from the electronic medical records (EMRs) into FHIR and by constructing the RESTful API, this could transfer the information to the infusion pump management system. In this study, we used the HN LINE infusion pump management system[13] provided by Nipro Corporation. The HN LINE can acquire the infusion pump status and settings via Wi-Fi and display them using a smartphone application.

Fig. 1 System overview. API, application programming interface; FHIR, Fast Healthcare Interoperability Resources; HL7, Health Level 7; SS-MIX2, Standardized Structured Medical Information Exchange version 2.

Target Data and Acquisition Method

This study used injection order information stored in the SS-MIX2. The SS-MIX2 is the adopted standard which was defined ISO TS compliant in 2021.[14] [15] It provides standard specifications for storing HL7 version 2 messages using a hierarchical structure comprising the patient identification number, data creation date, and other information. In Japan, it has been widely used at more than 1,000 facilities as of 2022, and it has been adopted as backup data resource in case of disasters at national university hospitals nationwide. The SS-MIX2 data output for the National University Hospital Remote Backup System at the University of Tokyo Hospital include patient management messages (admit, discharge, transfer [ADT] messages) and structured injection order messages (RDE_O11). The SS-MIX2 data are created from a replication database and comprise a duplicate of the EMRs. When constructing the system, transactional storage, which is created at the same time as standardized storage, is constantly monitored, and the corresponding messages are read whenever there is an update.

In this study, data necessary for matching were obtained from SS-MIX2; these data are output from a replication database synchronized with the main database of the EMR system rather than directly from the EMR system. The replication database contains duplicated data that are synchronized with the main database in near real time; they are used not only as a backup but also as a reference system for checking data and for secondary uses, such as the extraction of data for research studies. At our hospital, SS-MIX2 is the output data from the replication database for the remote backup system of the National University Hospital (The GEMINI Project); patient management messages (ADT_A08) and structured injection order messages (RDE_O11) are used for FHIR; O11 was used to implement the conversion to FHIR. When constructing the system, the transaction storage, which is created at the same time as the standardized storage, is constantly monitored so that whenever data are written, the corresponding message is read, and the difference data are acquired. The data actually read are two SS-MIX2 data types, ADT-00 and OMP-02, and new files are created for each data type and date. Another new file is created if the data amount exceeds 10 MB on the same day. This file creation rule should also be considered when reading the difference data.

 

MissingLinkText

Mapping to Health Level 7 Fast Healthcare Interoperability Resources

Health Level 7 Fast Healthcare Interoperability Resources and Fast Healthcare Interoperability Resources

HL7 FHIR is one of the standards for the health information exchange that was published by HL7 International, and it has been rapidly developing since the mid-2010s.[16] In the United States, the “SMART on FHIR” development platform is particularly popular, and many FHIR-compliant applications have been developed.[17]

The location of the data, called the resource, is specified by the type of data to be stored in the FHIR. Nine specific drug resources (Allergy Intolerance, Coverage, Encounter, Medication, Medication Request, Observation, Organization, Patient, and Practitioner) comprise the Clinical Medications category, and the injection orders used for this study were primarily from the Medication Request resource. However, even single orders are in a format that refers to multiple resources, such as patient resources (for patient information included in injection orders) and location resources (forward information). These nine resources are listed in [Table 1]. The structure of these resources is still being developed by HL7 International. As of April 2021, FHIR release 4, which is the latest version, includes the final drafts of only the Patient and Observation resources ([Table 1]).

Table 1 Mapping destination resources and data

Resource name	Data type
Allergy intolerance	Allergy information
Coverage	Insurance information
Encounter	Information about medical opportunities
Medication	Drug information
Medication request	Order information
Observation	Information about specimen test results
Organization	Information about the organization
Patient	Information about the patient
Practitioner	Information about health care professionals

In this study, IRIS for Health,[18] which was provided by InterSystems Corporation, was adopted as the FHIR repository, and the conversion process was implemented using the included components for converting HL7 version 2 messages to FHIR. However, in practice, not all data are automatically converted, and the mapping process is continued while considering the location of the resources to be registered; the goal is implementation in the matching system. Additionally, to confirm whether the data necessary for actual matching with infusion information were correctly extracted and mapped, we compared the data items with those managed by HN LINE. HN LINE is an application used for managing infusion pump implementation data; it was provided by Nipro Corporation, which is also the manufacturer of the infusion pump.

 

MissingLinkText

Mapping Method

The conversion process was implemented using IRIS for Health (hereafter called IRIS) provided by the InterSystems Corporation and the components included in IRIS that convert HL7 version 2 messages to HL7 FHIR. However, in practice, not all data are automatically converted, and some messages are not mapped to the intended resource, depending on the data stored in the SS-MIX2 messages. Therefore, we continued mapping while considering the location of the resource to be registered, with the goal of implementing the matching system. If a message was captured in an unexpected resource, then the mapping definition of the IRIS component was customized and adjusted so that the message was stored in the appropriate resource.

Additionally, because the Japanese version of FHIR Profile (named “JP Core”) is currently being studied by the NeXEHRs[19] [20] (Next-Generation Electronic Healthcare Record Systems) Study Group of the Japan Society for Medical Informatics and the HL7 FHIR Japan Implementation Study Working Group, we also studied the specifications to match those currently adopted as well as the draft of the HL7 FHIR description specifications for electronic prescriptions being studied as part of the Health and Labor Sciences Special Research Project. JP Core ver.1 is created in succession to FHIR R 4.0.1. For quality testing, IRIS functions were used to validate with JP Core, but the authors visually verified the elements that were mapped independently in this study.

 

MissingLinkText

Verification of Data Required for Infusion Reconciliation

We converted as much SS-MIX2 data as possible to FHIR and determined whether the necessary data for actual infusion reconciliation could be extracted and mapped. We asked Nipro Corporation to provide us with the data items managed by HN LINE, which are used to manage the aforementioned data of the infusion pump side, to determine whether the necessary data were actually output to the resource.

 

MissingLinkText

Data Integration Using the RESTful Application Programming Interface

Injection orders mapped to FHIR are stored in the FHIR repository in IRIS, and when information is passed from IRIS to the HN LINE (the management system for infusion pumps), the RESTful API is built in accordance with FHIR specifications, and the HN LINE side uses the GET method to query the relevant data. The linkage between the FHIR repository and the HN LINE is designed to retrieve the difference data of the injection orders at regular intervals and store the necessary data in the internal system of the HN LINE side. A linkage test was conducted to maintain the data in the SS-MIX2 transaction storage and to retrieve and store the data from the HN LINE side. For the linkage test, pseudoinjection orders were issued to the test patient. Then, we prepared 10 dummy scenarios in which we used multiple drugs or changed the dosage. This study does not contain any studies involving human or animal subjects.

 

MissingLinkText

 

MissingLinkText

 

MissingLinkText

Results

Mapping Results and Issues

To perform mapping, we applied the SS-MIX2 data to the IRIS component to determine the FHIR in which each message was captured. The results of the elements that were able to clearly map the injection order message to the FHIR, and the elements that needed modification or could not be mapped were identified. [Tables 2] and [3] show the results of mapping the required data on the HN LINE side into the FHIR data. Using the constructed mapping rules, we confirmed that SS-MIX2 injection order messages could be imported into each resource, including the Medication Request resource of the FHIR, as expected. We also confirmed that among the data items managed by HN LINE, the patient identification number, date of birth, name, sex, department, ward, height, weight, and in/out category were registered as patient information. Furthermore, we confirmed that the order identification number, flow rate, drug identification code, and drug name were registered as order information. We confirmed that the minimum information required for matching the information at the time of implementation was mapped to the FHIR ([Fig. 2]). We were not able to convert all injection order messages to FHIR, but we confirmed that we had all the necessary data to match the infusion pump configuration information.

Table 2 Results of storing the required data on the HN LINE (Patient Information Database)

Item	SS-MIX2 data type	SS-MIX2 message (HL7 ver.2 message type)	FHIR R4 element	FHIR data type
Patient ID	character varying (16)	PID-3 (ADT^A01)	Patient.identifier.value	string
Birth date	timestamp (6)	PID-7 (ADT_A01)	Patient.birthDate	date
Patient name	character varying (255)	PID-5 (ADT_A01)	Patient.name	HumanName
Gender	character varying (1)	PID-8 (ADT_A01)	Patient.gender	code
Department ID	character varying (20)	PV1-3 (ADT_A01)	Encounter.hospitalization.extension	string
Ward ID	character varying (20)	PV1-3 (ADT_A01,RDE_O11)	Encounter.hospitalization.extension	string
Room ID	character varying (5)	PV1-3 (ADT_A01)	Encounter.hospitalization.extension	string
Height	numeric(10)	OBX-5 (ADT_A01)	Observation.valueQuantity.value	Quantity
Weight	numeric(10)	OBX-5 (ADT_A01)	Observation.valueQuantity.value	Quantity
Inpatient or outpatient	character varying (1)	PV1-1 (ADT_A01)	Encounter.class.code	code
Discharge flag	character varying (1)	(ADT_A03)	Encounter.Status	code

Abbreviations: FHIR, Fast Healthcare Interoperability Resources; HL7, Health Level 7; ID, identification; SS-MIX2, Standardized Structured Medical Information Exchange version 2.

Table 3 Results of storing the required data on the HN LINE (Infusion Order Information Database)

Item	SS-MIX2 data type	SS-MIX2 message (HL7 ver.2 message type)	FHIR R4 element	FHIR data type
Order ID	character varying (255)	PID-3 (ADT_A01)	MedicationRequest.identifier.value	string
Patient ID	character varying (255)	PID-3 (ADT_A01)	Patient.identifier.value	string
Flow rate	numeric(4)	RXE-23 (RDE_O11)	MedicationRequest.dosageInstruction	Dosage
Dose	numeric(5)	RXE-3 (RDE_O11)	MedicationRequest.dosageInstruction	Dosage
Drag code	character varying (16)	RXC-2 (RDE_O11)	Medication.ingredient.itemCodeableConcept	CodeableConcept
Drug name	character varying(255)	RXC-2 (RDE_O11)	Medication.ingredient.itemCodeableConcept	CodeableConcept
Order ID	character varying (255)	PID-3 (ADT_A01)	MedicationRequest.identifier.value	string

Abbreviations: FHIR, Fast Healthcare Interoperability Resources; HL7, Health Level 7; ID, identification; SS-MIX2, Standardized Structured Medical Information Exchange version 2.

Fig. 2 Comparison between the order and the infusion pump using HN LINE.

However, among the required elements, there were some elements that required manual mapping. For example, in the FHIR, location falls under Location resource, but there are multiple pieces of information in the message that refer to location, such as “ward,” “wing,” and “bed.” There was also a difference between the location where the injection was to be performed and the location where the injection drug was delivered, for example. In such cases we had to set rules as to which information to select and store in the elements of the FHIR.

[Table 4] lists the main definitional changes for items whose messages were captured by unexpected resources. For example, the intravenous infusion rate stored in RXE-7 (client's medication instructions) was mapped to the “MedicationStatement Resource” if the mapping definition was used as it is; however, because this information was originally related to the order, the mapping was revised so that it is now stored in the “MedicationRequest Resource.”

Table 4 Major corrective actions for mapping to Fast Healthcare Interoperability Resources

Item name	HL7 version 2 message name	Mapping response
Infusion rate	RXE-3 (RDE_O11)	Stored in “DoseAndRate.RateQuantity” element in the “MedicationStatement Resource”; changed to “DoseAndRate.RateQuantity” element in the “MedicationRequest Resource”
Ward ID	PV1-3 (ADT_A01) PV1-3 (RDE_O11)	Stored in “extension.hospitalization” element in the “Encounter Resource.” Data can be obtained from both injection orders and basic patient information (movement history). Therefore, the latest data from both messages are retrieved
Department ID	ORC-17 (RDE_O11)	Undefined; changed to “serviceType” element in the “Encounter Resource”
Ingredient amount/ingredient unit	RXC-3,4 (RDE_O11)	Undefined; changed to “ingredient.strength” element in the “Medication Resource”

Abbreviations: FHIR, Fast Healthcare Interoperability Resources; HL7, Health Level 7; ID, identification.

As shown in [Fig. 3], the barcode for injection verification at our hospital consists of a 20-digit number comprising the fixed character string indicating the injection order (2 digits), patient identification number (8 digits), order number (8 digits), and version number (2 digits). Because the string corresponding to the version number is not currently stored in the SS-MIX2 Structured Injection Order message, the version number of the order cannot be identified from the FHIR. Therefore, we will ask the EMR vendor to output a string with the version number added to the requester's order number (ORC-2), which will allow further integration in the future.

Fig. 3 String used for collation printed on the injection label. ID, identification.

 

MissingLinkText

Results of and Issues Associated with RESTful Application Programming Interface Data Integration

Using the RESTful API of the FHIR, the HN LINE was specified a uniform resource identifier including search parameters, and the data were obtained by querying the server using the HTTP GET method. Based on the mapping definitions we developed, as shown in [Tables 2] and [3], we confirmed that all items were linked to the HN LINE Patient Information Database and Infusion Information Database in all scenarios. As shown in [Fig. 2], the injection order information and the infusion pump settings could be displayed and reconciled on the HN LINE smartphone application.

Each resource registered in the FHIR repository can be retrieved successfully; however, when the amount of difference data becomes large, a timeout occurs, and the process cannot be completed. Paging is a function that allows the user to search for a particular condition ([Fig. 4]) and query a large number of resources that match the search criteria by dividing them into multiple requests instead of returning all the resources at once. It works in the same way as a search engine that displays search results on one page at a time. For example, when patient information is received in batches during the night, the hypertext transfer protocol response may time out because of the large volume of data being transmitted; therefore, the paging function may effectively avoid this.

Fig. 4 Example of paging using the RESTful application programming interface (API) of Fast Healthcare Interoperability Resources (FHIR).

 

MissingLinkText

 

MissingLinkText

Discussion

An FHIR repository was constructed by extracting the information necessary to reconcile SS-MIX2 structured injection order messages with infusion pump settings and mapping them to the FHIR. This study confirmed that the information necessary for the reconciliation of injection administration using infusion pumps, which are performed as ward operations, can be converted to FHIR and linked to the management system on the injection pump side via the RESTful API.

There are some advantages to using SS-MIX2 and the FHIR. First, the system can be implemented regardless of the EMR vendor. Second, the system can be developed using the Web standard technology used for FHIR, which allows vendors with limited experience developing medical information systems to create them within shorter time periods. In Japan, there are several practical examples of mapping SS-MIX2 to the FHIR. Tanaka and Yamamoto verified the degree of compatibility between FHIR and SS-MIX2 standardized storage mapping.[21] Strasberg et al used FHIR to support clinical decisions and improve the quality of care.[22] Stoldt and Weber demonstrated how a cardiac risk scoring application can leverage data quality probes to validate several data quality concerns.[23] Seamless information linkage through the FHIR is also expected for health examinations, patient health records, and maternal and child health handbooks, and the number of validation cases is increasing at an accelerated rate.[24] [25] This study is novel because it implemented a prototype that could be used for the collation of actual injection operations. Additionally, although the purpose of this study was to match the order information with the infusion pump information, it can also be applied to the automatic creation of accurate record data because infusion pump implementation information can be automatically recorded as a medical record in a form linked to order information.

Although this work does not describe the detailed mapping destination for each SS-MIX2 message, we are considering how to publish mapping definitions so that examples of this research can be used in the future. For example, systems such as simplifier.net[7] and SUSHI Shorthand[8] are used by the NeXEHRs Study Group of the Japan Association for Medical Informatics and the HL7 FHIR Japan Implementation Study Working Group to publish implementation guides. Therefore, we plan to investigate ways to accomplish the same in the future.

This study had some limitations. First, there was a delay between the time when an injection order was entered in the EMR system and the time when the FHIR was created because of the use of SS-MIX2. The design estimated a time difference of approximately 7 minutes because of the reflection from the EMR to the replication database (every 1 minute), output from SS-MIX2 (every 5 minutes), and conversion to FHIR (approximately 1 minute in many cases, but this is dependent on the amount of difference data to be acquired). When a delay actually occurs, the HN LINE application displays an error and that cannot be reconciled until the correct order information is received. In future experiments, the delay time will be measured to verify whether the response is affected by the day of the week, time of day, or other factors, and to consider ways to improve the response. Second, in this study, the FHIR repository sent the difference data to the HN LINE management system one time via the RESTful API, and communication with the smart device for matching was performed via the HN LINE server. This is because of the limitations of the existing specifications of the HN LINE side; however, we believe that smoother matching using the RESTful API would be possible if communication with the smart device that actually performs the matching could be performed by FHIR on a case-by-case basis. The practice of storing data in each application that manages patient information is likely to increase in the future; however, it could be a security risk. By adopting a mechanism that aggregates patient information in the FHIR repository so that only necessary data are obtained from applications on a case-by-case basis through API queries, it is possible to prevent the dispersion of personal information when using the FHIR repository. Additionally, although data present in the FHIR are currently generated through three processes, considering the delay time mentioned above, it would be practical in the future to implement a system for direct conversion from EMRs to the FHIR. Further, because each application does not need its own large database, it is expected that their development will require less time. Direct integration with smart devices has not yet been achieved; therefore, our system has not yet been verified.

 

MissingLinkText

Conclusion

By mapping SS-MIX2 structured injection order messages to the FHIR, we developed and implemented a data linkage mechanism to reconcile infusion pumps and injection orders. As a result, the study was confirmed that the information necessary for its implementation in hospital wards could be transferred to FHIR and linked. In the future, we will develop a new mechanism that contributes to medical safety through the actual implementation and verification of our system.

 

MissingLinkText

Clinical Relevance Statement

The results of this study are expected to prevent medication misadministration due to human error by health care providers. Specifically, it gives health care providers the opportunity to detect and correct instances when infusion pump settings are different from the physician's orders. This will help prevent and protect patient health hazards.

 

MissingLinkText

Multiple-Choice Questions

1. Which new health information exchange standard is based on the use of REST APIs?

   • SS-MIX2

   • HL7 FHIR

   • Systematized Nomenclature of Medicine-Clinical Terms (SNOMED-CT)

   • Health Level 7 Clinical Document Architecture (HL7 CDA)

   Correct Answer: The correct answer is option b. HL7 FHIR is based on the use of “FHIR REST APIs.”

2. Which information exchange standard uses a hierarchical structure consisting of patient identification numbers, data creation dates, and other information?

   • SS-MIX2

   • HL7 FHIR

   • SNOMED-CT

   • HL7 CDA

   Correct Answer: The correct answer is option a. SS-MIX uses a hierarchical structure that is defined in ISO/TS 24289:2021 Health informatics—Hierarchical file structure specification for secondary storage of health-related information.

3. Which incident can be prevented by matching injection orders with infusion pump settings?

   • Wrong drug ordered by the doctor

   • Mechanical failure of the infusion pump

   • Wrong settings to be entered into the injection pump

   • Drug leakage from infusion bag

   Correct Answer: The correct answer is option c. Information-only injection orders and infusion pump settings will not prevent options a, b, and d.

 

MissingLinkText

 

MissingLinkText

Conflict of Interest

Co-authors K.T. and M.A. are employees of Nipro Corporation, the manufacturer of the HN LINE application used in this study.

Protection of Human and Animal Subjects

This article does not contain any studies with human or animal subjects performed by any of the authors.

• References

• 1 Koppel R, Wetterneck T, Telles JL, Karsh BT. Workarounds to barcode medication administration systems: their occurrences, causes, and threats to patient safety. J Am Med Inform Assoc 2008; 15 (04) 408-423
• 2 Sullivan GH. Five “rights” equal 0 errors. RN 1991; 54 (06) 65-66 , 68
• 3 Japan Council for Quality Health Care. Incorrect route of drug administration [in Japanese] . 2015. Accessed November 1, 2022 at: https://www.med-safe.jp/pdf/med-safe_101.pdf
• 4 ISO. ISO/TS 24289:2021 Health informatics—Hierarchical file structure specification for secondary storage of health-related information. 2021. Accessed November 1, 2022 at: https://www.iso.org/standard/78343.html
• 5 Takenouchi K, Yuasa K, Shioya M. et al. Development of a new seamless data stream from EMR to EDC system using SS-MIX2 standards applied for observational research in diabetes mellitus. Learn Health Syst 2018; 3 (01) e10072
• 6 HL7 FHIR Release 4B. Accessed November 1, 2022 at: http://hl7.org/fhir/
• 7 Ohashi K, Dalleur O, Dykes PC, Bates DW. Benefits and risks of using smart pumps to reduce medication error rates: a systematic review. Drug Saf 2014; 37 (12) 1011-1020
• 8 Tung TH, DeLaurentis P, Yih Y. Uncovering discrepancies in IV vancomycin infusion records between pump logs and EHR documentation. Appl Clin Inform 2022; 13 (04) 891-900
• 9 Yu D, Obuseh M, DeLaurentis P. Quantifying the impact of infusion alerts and alarms on nursing workflows: a retrospective analysis. Appl Clin Inform 2021; 12 (03) 528-538
• 10 Howlett MM, Butler E, Lavelle KM, Cleary BJ, Breatnach CV. The impact of technology on prescribing errors in pediatric intensive care: a before and after study. Appl Clin Inform 2020; 11 (02) 323-335
• 11 Howlett MM, Breatnach CV, Brereton E, Cleary BJ. Direct observational study of interfaced smart-pumps in pediatric intensive care. Appl Clin Inform 2020; 11 (04) 659-670
• 12 Pharmaceuticals and Medical Devices Agency. Japan. Reviews. Accessed September 1, 2023 at: https://www.pmda.go.jp/english/review-services/reviews/0001.html
• 13 Nipro Corp. HN LINE [ in Japanese] . Accessed November 1, 2022 at: https://med.nipro.co.jp/med_eq_category_detail?id=a1U2x00000GmrXCEAZ
• 14 ISO/TS 24289 Health informatics—Hierarchical file structure specification for secondary storage of health-related information. Accessed November 1, 2022 at: https://www.iso.org/standard/78343.html
• 15 Fujistu Research Institute. Survey on HL7 FHIR final report. Accessed November 1, 2022 at: https://www.mhlw.go.jp/content/12600000/FinalReport_SurveyOnHL7FHIRwithMemo.pdf
• 16 Ayaz M, Pasha MF, Alzahrani MY, Budiarto R, Stiawan D. The fast health interoperability resources (FHIR) standard: systematic literature review of implementations, applications, challenges and opportunities. JMIR Med Inform 2021; 9 (07) e21929
• 17 Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc 2016; 23 (05) 899-908
• 18 InterSystems on FHIR. Accessed November 1, 2022 at: https://www.intersystems.com/solutions/fhir/
• 19 HL7 FHIR JP Core ImplementationGuide - Local Development build (v1.1.1). Accessed September 1, 2023 at: https://jpfhir.jp/fhir/core/1.1.1/index.html
• 20 Common Platform for Next-Generation Electronic Healthcare Record Systems (NeXEHRs). Accessed September 1, 2023 at: https://jpfhir.jp/
• 21 Tanaka K, Yamamoto R. An investigation of message definition mappings between HL7 FHIR and SS-MIX2 standardized storage [in Japanese]. J Jpn Assoc Med Inform 2020; 40: 587-588
• 22 Strasberg HR, Rhodes B, Del Fiol G, Jenders RA, Haug PJ, Kawamoto K. Contemporary clinical decision support standards using Health Level Seven International Fast Healthcare Interoperability Resources. J Am Med Inform Assoc 2021; 28 (08) 1796-1806
• 23 Stoldt JP, Weber JH. Safety improvement for SMART on FHIR Apps with data quality by contract. 2020 IEEE International Conference on Software Architecture Companion (ICSA-C), Salvador, Brazil. 2020: 192-195
• 24 Saripalle R, Runyan C, Russell M. Using HL7 FHIR to achieve interoperability in patient health record. J Biomed Inform 2019; 94: 103188
• 25 Ismail S, Alshmari M, Qamar U, Butt WH, Latif K, Ahmad HF. HL7 FHIR compliant data access model for maternal health information system. 2016 IEEE 16th International Conference on Bioinformatics and Bioengineering (BIBE), Taichung, Taiwan. 2016: 51-56

Publikationsverlauf

Eingereicht: 14. April 2023

Angenommen: 02. Oktober 2023

Artikel online veröffentlicht:
03. Januar 2024