No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Point-of-care medical devices and systems interoperability: A mapping of ICE and FHIR
Abstract
Medical devices at the point-of-care can be interconnected through standardised communication protocols to build an Integrated Clinical Environment (ICE), but in order to interoperate with clinical information systems, different data exchange standards need to be conformed to. The emerging HL7 Fast Healthcare Interoperability Resources (FHIR) framework appeals to developers and clinicians alike and is a promising candidate to modernise this domain. Novel IEEE 11073 standard proposals that specify a service-oriented architecture of networked medical devices are one example for an ICE architecture. They are based on expressing a device's capabilities and state in a machine-readable way in order to be safely accessed and manipulated by other participants in the networked device system. In this work, the domain information and service model of this ICE architecture was mapped to FHIR resources that were constrained and extended to support the modelling of this device architecture. Through the definition of a FHIR profile, the data structures were aligned, effectively allowing for the transformation of medical device observation data from ICE to FHIR representation without the need for any proprietary interface. The implementation of this transformation, e. g. as a gateway, bridges the structural interoperability gap between two contemporary communication architectures for medical devices and clinical information systems and thus lays the foundation for semantic interoperability that can be achieved through the combined use with controlled vocabularies. The consequent availability of device data enables secondary usage such as large-scale data analytics. Future sub-profiles for specific device types further simplify the transformation.
... Resource name [6,10,12,34,49] Allergy [12,14,19,22,29,33,52,55,58,60,61,72,74,77] Allergy Intolerance [13,55,70] Appointment [3,10,12,16,18,22,23,26,31,36,40,52,55,60,64,66,71,73,74,76,77,79,81] Condition [14,16,70,81] Composition [6,34,36,39,41,49,61,74,76,77,82] Care Plan [6,8,9,11,19,20,24,32,33,39,43,48,53,77] Device [24,32,53] Device Metric [25,74,77] Detected Issue [6,8,33] Document [28,44,52,60,63,74,84] Diagnostic Report [10,16,21,30,33,39,41,55,71,74,77] Encounter [21,41,77,84] Episode Of Care [22,26,27,60,61,74,77,81] Family Member History [6,22,33] Family History [22,60,74] Immunization [6,10,14,16,24,34,49,71,77] Location [3,9,16,19,27,29,31,33,39,40,48,49,70,77,81] Medication [60,70,71] Medication Administration [16,22,23,70] Medication Order [19,27,55,66,77,81] Medication Statement [3,22,31] Medication Prescription [66,71,73,74,77] Medication Request [3,[9][10][11]14,[18][19][20][21][22][23][24][25][26][28][29][30][31][32][33]36,[39][40][41]43,44,48,49,[51][52][53]55,58,60,63,64,66,[69][70][71][73][74][75][76][77]79,82,84] Observation [5,6,16,19,34,39,41,75,77,84] Organization [3,5,6,[8][9][10]12,14,[16][17][18][19][20][21][22][23][24][27][28][29][30][31][32]34,36,[39][40][41]44,[48][49][50]52,53,55,58,61,63,65,68,[70][71][72][73][74][75][76][77]84] Patient [14,46,69] Person [41,74,80] Plan Definition [9,[17][18][19]24,[27][28][29]34,41,44,48,52,53,58,61,63,71,77] Practitioner [3,40,60,66,71,72,74,77,81] Procedure [21,41,47,60,69,70,74,78,84] Questionnaire Response [17,21,41,47,64,65,70,74,84] Questionnaire [3,5,6,[10][11][12][14][15][16][17]21,23,24,28,29,[32][33][34]41,44,46,47,49,52,55,60,66,[71][72][73][74][75]77 ...
... Resource name [6,10,12,34,49] Allergy [12,14,19,22,29,33,52,55,58,60,61,72,74,77] Allergy Intolerance [13,55,70] Appointment [3,10,12,16,18,22,23,26,31,36,40,52,55,60,64,66,71,73,74,76,77,79,81] Condition [14,16,70,81] Composition [6,34,36,39,41,49,61,74,76,77,82] Care Plan [6,8,9,11,19,20,24,32,33,39,43,48,53,77] Device [24,32,53] Device Metric [25,74,77] Detected Issue [6,8,33] Document [28,44,52,60,63,74,84] Diagnostic Report [10,16,21,30,33,39,41,55,71,74,77] Encounter [21,41,77,84] Episode Of Care [22,26,27,60,61,74,77,81] Family Member History [6,22,33] Family History [22,60,74] Immunization [6,10,14,16,24,34,49,71,77] Location [3,9,16,19,27,29,31,33,39,40,48,49,70,77,81] Medication [60,70,71] Medication Administration [16,22,23,70] Medication Order [19,27,55,66,77,81] Medication Statement [3,22,31] Medication Prescription [66,71,73,74,77] Medication Request [3,[9][10][11]14,[18][19][20][21][22][23][24][25][26][28][29][30][31][32][33]36,[39][40][41]43,44,48,49,[51][52][53]55,58,60,63,64,66,[69][70][71][73][74][75][76][77]79,82,84] Observation [5,6,16,19,34,39,41,75,77,84] Organization [3,5,6,[8][9][10]12,14,[16][17][18][19][20][21][22][23][24][27][28][29][30][31][32]34,36,[39][40][41]44,[48][49][50]52,53,55,58,61,63,65,68,[70][71][72][73][74][75][76][77]84] Patient [14,46,69] Person [41,74,80] Plan Definition [9,[17][18][19]24,[27][28][29]34,41,44,48,52,53,58,61,63,71,77] Practitioner [3,40,60,66,71,72,74,77,81] Procedure [21,41,47,60,69,70,74,78,84] Questionnaire Response [17,21,41,47,64,65,70,74,84] Questionnaire [3,5,6,[10][11][12][14][15][16][17]21,23,24,28,29,[32][33][34]41,44,46,47,49,52,55,60,66,[71][72][73][74][75]77 ...
... Resource name [6,10,12,34,49] Allergy [12,14,19,22,29,33,52,55,58,60,61,72,74,77] Allergy Intolerance [13,55,70] Appointment [3,10,12,16,18,22,23,26,31,36,40,52,55,60,64,66,71,73,74,76,77,79,81] Condition [14,16,70,81] Composition [6,34,36,39,41,49,61,74,76,77,82] Care Plan [6,8,9,11,19,20,24,32,33,39,43,48,53,77] Device [24,32,53] Device Metric [25,74,77] Detected Issue [6,8,33] Document [28,44,52,60,63,74,84] Diagnostic Report [10,16,21,30,33,39,41,55,71,74,77] Encounter [21,41,77,84] Episode Of Care [22,26,27,60,61,74,77,81] Family Member History [6,22,33] Family History [22,60,74] Immunization [6,10,14,16,24,34,49,71,77] Location [3,9,16,19,27,29,31,33,39,40,48,49,70,77,81] Medication [60,70,71] Medication Administration [16,22,23,70] Medication Order [19,27,55,66,77,81] Medication Statement [3,22,31] Medication Prescription [66,71,73,74,77] Medication Request [3,[9][10][11]14,[18][19][20][21][22][23][24][25][26][28][29][30][31][32][33]36,[39][40][41]43,44,48,49,[51][52][53]55,58,60,63,64,66,[69][70][71][73][74][75][76][77]79,82,84] Observation [5,6,16,19,34,39,41,75,77,84] Organization [3,5,6,[8][9][10]12,14,[16][17][18][19][20][21][22][23][24][27][28][29][30][31][32]34,36,[39][40][41]44,[48][49][50]52,53,55,58,61,63,65,68,[70][71][72][73][74][75][76][77]84] Patient [14,46,69] Person [41,74,80] Plan Definition [9,[17][18][19]24,[27][28][29]34,41,44,48,52,53,58,61,63,71,77] Practitioner [3,40,60,66,71,72,74,77,81] Procedure [21,41,47,60,69,70,74,78,84] Questionnaire Response [17,21,41,47,64,65,70,74,84] Questionnaire [3,5,6,[10][11][12][14][15][16][17]21,23,24,28,29,[32][33][34]41,44,46,47,49,52,55,60,66,[71][72][73][74][75]77 ...
Background
Information technology has shifted paper-based documentation in the health care sector into a digital form, in which patient information is transferred electronically from one place to another. However, there remain challenges and issues to resolve in this domain owing to the lack of proper standards, the growth of new technologies (mobile devices, tablets, ubiquitous computing), and health care providers who are reluctant to share patient information. Therefore, a solid systematic literature review was performed to understand the use of this new technology in the health care sector. To the best of our knowledge, there is a lack of comprehensive systematic literature reviews that focus on Fast Health Interoperability Resources (FHIR)-based electronic health records (EHRs). In addition, FHIR is the latest standard, which is in an infancy stage of development. Therefore, this is a hot research topic with great potential for further research in this domain.
Objective
The main aim of this study was to explore and perform a systematic review of the literature related to FHIR, including the challenges, implementation, opportunities, and future FHIR applications.
Methods
In January 2020, we searched articles published from January 2012 to December 2019 via all major digital databases in the field of computer science and health care, including ACM, IEEE Explorer, Springer, Google Scholar, PubMed, and ScienceDirect. We identified 8181 scientific articles published in this field, 80 of which met our inclusion criteria for further consideration.
Results
The selected 80 scientific articles were reviewed systematically, and we identified open questions, challenges, implementation models, used resources, beneficiary applications, data migration approaches, and goals of FHIR.
Conclusions
The literature analysis performed in this systematic review highlights the important role of FHIR in the health care domain in the near future.
... Da må gjerne IT-avdelingen lage et grensesnitt for å få systemene til å utveksle data. Dette svikter ofte og man må gå tilbake til å utveksle informasjonen på papir (1,3). Det er ikke uten grunn at helsevesenet er det største gjenvaerende markedet for penner, papir og faksmaskiner (4). ...
... Man definerte strukturen på semantikken i en «Reference Information Model» (RIM). Dette ga en høy grad av informasjonsintegritet, men bidro også til å øke kompleksiteten (3,30). ...
... Med unntak av det tyske OR.NET prosjektet (47,49) så fokuserer det meste av HL7 FHIR litteraturen på utveksling mellom kliniske IKT systemer. Enten mellom stasjonaere systemer (30), mot mobile enheter (2), eller overføring fra gamle IKT-systemer til HL7 FHIR (3,50). ...
When harvesting clinical data it is important that these are standardized to achieve interoperability. This should be done to avoid fragmentation of information and loss of context. To demonstrate that it is expedient, an artifact was made to demonstrate proof-of-concept.
The artifact collected the data stream from two virtual syringe pumps loaded with medications to regulate blood pressure. The medication administered is determined by the blood pressure observed by the staff.
Healt Layer 7 Fast healthcare Interoperability Resource was used to standardize the information so that it is possible to exchange it.
The blood pressure and medication curve were made in an integrated visualization to show that you can reap, standardize and if desired exchange data to avoid fragmentation and preserve the context.
... At the same time, technology has had notable advances in the last years, particularly in the development of devices capable of collecting large volumes of valuable data of different kinds, and also in the ability to manage, store, process and transfer all this data. One of the hot topics of this technological transformation, that is rapidly growing worldwide, and known as the Internet of Things (IoT), consists of a network of physical object-linked devices that are accessible via the Internet [1]. It is enabling the transformation of several domains of our daily lives, being health one of them, through affordable home healthcare solutions capable of improving quality of care while promoting patient-centered care. ...
... This standard provides transport, structured and some semantic interoperability, as well as health information integrity, while ensuring its ease of implementation. FHIR stores and exchanges data between systems through its XML and/or JSON modular components called "resources", which represent granular clinical concepts [1]. FHIR supports architectures based on representational state transfer (REST), seamless exchange of information using messages or documents, and also service-based architectures [2]. ...
Although FHIR has been designed to be easy to implement, it requires knowledge that is still hard to find. We aim to evaluate the use of FHIR in Portuguese projects for the integration of medical devices. Two projects were selected, including easyHealth4Covid (EH4C) and Chronic Diseases Management Platform (CDMP). The evolution of each project and the FHIR resources used were analyzed. 11 different sensors of 5 companies were used in the sum of both projects. Previously, none of them used FHIR to integrate and the teams had little to no experience in doing so. The FHIR Observation resource was used for all. There is a general lack of knowledge of the FHIR standard and terminologies of most of the device companies involved in the projects.
... Since then, however, there have been many improvements to HL7 after understanding its initial shortcomings. HL7 v2 is to this day used in majority of clinical and administrative data exchange [6]. However, due to its high degree of ambiguity and the need for customizable interfaces, HL7 v3 was developed which provided a high level of information integrity but was thus complex and wasn't widely implemented. ...
... Finally, platforms consist of a network of computational resources that acts as a trusted base to enforce the correct assembly of on-demand system. Finally, the authors of [21] propose a solution that enables the effective transformation of medical device sensed information from the ICE framework to HL7 Fast Healthcare Interoperability Resources (FHIR) framework. This work demonstrates the feasibility of mapping the data model of the ICE architecture to profiled FHIR resources in order to achieve structural interoperability between the domains of medical devices and clinical IT infrastructure. ...
The disruptive vision of Medical Cyber-Physical Systems (MCPS) enables the promising next-generation of eHealth systems that are intended to interoperate efficiently, safely, and securely. Safety-critical interconnected systems that analyze patients' vital signs gathered from medical devices, infer the state of the patient's health, and start treatments issuing information to doctors and medical actuators should improve the patients' safety in a cost-efficient fashion. Despite the benefits provided by the MCPS vision, it also opens the door to critical challenges like the security and privacy, Quality of Service (QoS), and high availability of the devices composed to support the MCPS scenario. The Integrated Clinical Environment (ICE) standard is a significant step toward promoting open coordination of heterogeneous medical devices by considering the previous challenges. However, a lot of effort is still required in order to cover the whole aspects of these challenges and enable the future eHealth. In this context, we identify critical shortcomings of ICE using challenge scenarios regarding security, QoS, and high availability. According to these concerns and following the ICE standard, we propose the novel ICE++ architecture, which is oriented to the Mobile Edge Computing paradigm and combines SDN and NFV techniques to manage efficiently and automatically the MCPS elements taking into account its security, QoS, and high availability. Finally, we perform experiments that demonstrate the potential usefulness of our solution regarding the efficient and automatic management of the ICE components.
... Vice versa, the reporting of maintenance data and measurements to the CITI, implemented by a generic DOR, has been considered useful to improve device maintenance workflows and to simplify post-operative documentation. resources [34]. The proposed transformation offers a simple and robust customisation of resources using profiles and extensions, the tools and methods provided by FHIR. ...
The new medical device communication protocol known as IEEE 11073 SDC is well-suited for the integration of (surgical) point-of-care devices, so are the established Health Level Seven (HL7) V2 and Digital Imaging and Communications in Medicine (DICOM) standards for the communication of systems in the clinical IT infrastructure (CITI). An integrated operating room (OR) and other integrated clinical environments, however, need interoperability between both domains to fully unfold their potential for improving the quality of care as well as clinical workflows. This work thus presents concepts for the propagation of clinical and administrative data to medical devices, physiologic measurements and device parameters to clinical IT systems, as well as image and multimedia content in both directions. Prototypical implementations of the derived components have proven to integrate well with systems of networked medical devices and with the CITI, effectively connecting these heterogeneous domains. Our qualitative evaluation indicates that the interoperability concepts are suitable to be integrated into clinical workflows and are expected to benefit patients and clinicians alike. The upcoming HL7 Fast Healthcare Interoperability Resources (FHIR) communication standard will likely change the domain of clinical IT significantly. A straightforward mapping to its resource model thus ensures the tenability of these concepts despite a foreseeable change in demand and requirements.
Since the introduction of Bitcoin and Ethereum, blockchain introduced new ways to handle payment and dealing with financial transactions. From 2009 till now, several blockchain systems were developed. However, the main issue for each blockchain is to know where to use it and what the best use case fits with it. Transaction per second (TPS) and confirmation time (CT) give the possibility to evaluate the speed and performance of each blockchain. It demonstrates the speed of blockchain in processing any transaction and saving it to the ledger. This work reviews and presents the current status of the state-of-the-art blockchain performance.
Nowadays, the healthcare sector has stood out for offering the population a better quality of life. Under these circumstances, Information and Communication Technologies (ICT) are essential in mitigating the growing need for hospitals and care centers, providing computation and communication infrastructures to support healthcare services and applications. The introduction of new technologies in the healthcare industry, such as the Internet of Things (IoT), Artificial Intelligence (AI), and Big Data, improve service delivery vertically. However, a problem arises when introducing those new paradigms: the amount of data generated from healthcare devices and applications. Indeed, data sharing brings some challenges due to different types of healthcare standards, multiple protocols, systems diversity, and incompatibility of data. In this article, we introduce a microservices architecture for healthcare transcoding engines. Our solution show how transcoders can be encapsulated as independently functions using microservices. An application scenario that maps healthcare standards is also presented. We show that the use of microservices as transcoding engines improves scalability and flexibility features required by the healthcare sector.
Aim and Objectives: The aim of this research study is to understand the process required to “build from scratch” a FHIR© compliant Cystic Fibrosis (CF) mHealth app.
Methodology: A qualitative research approach is adopted, which will focus on a case study. The researchers observations about the process of building a FHIR© compliant mHealth app will be captured in a field diary as qualitative data. The data will be analysed using Grounded Theory with a view to building a theory about the “build from scratch” software engineering process.
Results: Analysis of the qualitative data through coding and constant comparative analysis yielded three categories. These three categories were used to develop a Grounded Theory based Conceptual Framework for the development of SMART on FHIR© apps.
Conclusions: Although, a Grounded Theory based Conceptual Framework for the development of SMART on FHIR© apps is being proposed within this study, it has been recognised that conflicting attitudes towards electronic healthcare data exchange, privacy and security are barriers to accessing patient information using mHealth apps and devices.
Objective:
In early 2010, Harvard Medical School and Boston Children's Hospital began an interoperability project with the distinctive goal of developing a platform to enable medical applications to be written once and run unmodified across different healthcare IT systems. The project was called Substitutable Medical Applications and Reusable Technologies (SMART).
Methods:
We adopted contemporary web standards for application programming interface transport, authorization, and user interface, and standard medical terminologies for coded data. In our initial design, we created our own openly licensed clinical data models to enforce consistency and simplicity. During the second half of 2013, we updated SMART to take advantage of the clinical data models and the application-programming interface described in a new, openly licensed Health Level Seven draft standard called Fast Health Interoperability Resources (FHIR). Signaling our adoption of the emerging FHIR standard, we called the new platform SMART on FHIR.
Results:
We introduced the SMART on FHIR platform with a demonstration that included several commercial healthcare IT vendors and app developers showcasing prototypes at the Health Information Management Systems Society conference in February 2014. This established the feasibility of SMART on FHIR, while highlighting the need for commonly accepted pragmatic constraints on the base FHIR specification.
Conclusion:
In this paper, we describe the creation of SMART on FHIR, relate the experience of the vendors and developers who built SMART on FHIR prototypes, and discuss some challenges in going from early industry prototyping to industry-wide production use.
The number of devices in an operation room (OR) and the complexity of the components and the overall system increases continuously. Today's vendor-dependent integrated ORs are expensive and not able to handle this complexity because they can only form isolated solutions. Thus a device communication for medical devices among each other and to medical information systems has to be based on open and vendor-independent standards. In this paper we will present new standards for networked Point-of-Care medical devices that will be part of the IEEE 11073 family of standards. A service-oriented device communication is defined by means of an architecture definition, a transport specification called Medical Devices Profile for Web Services (MDPWS), and a Domain Information & Service Model. The new system will make the complexity of a comprehensive OR integration manageable and thereby improve patient's safety. The focus of this paper is on MDPWS that enables a device communication for medical requirements and safety issues, like safe data transmission that will typically be used for safe remote control (dual channel and safety context), data streaming, and compact transmission. The suitability of the concept has been shown by a demonstrator with over 20 real world OR devices from more than 10 vendors.
This research examines the potential for new Health Level 7 (HL7) standard Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) standard to help achieve healthcare systems interoperability. HL7 messaging standards are widely implemented by the healthcare industry and have been deployed internationally for decades. HL7 Version 2 (“v2”) health information exchange standards are a popular choice of local hospital communities for the exchange of healthcare information, including electronic medical record information. In development for 15 years, HL7 Version 3 (“v3”) was designed to be the successor to Version 2, addressing Version 2's shortcomings. HL7 v3 has been heavily criticized by the industry for being internally inconsistent even in it's own documentation, too complex and expensive to implement in real world systems and has been accused of contributing towards many failed and stalled systems implementations. HL7 is now experimenting with a new approach to the development of standards with FHIR. This research provides a chronicle of the evolution of the HL7 messaging standards, an introduction to HL7 FHIR and a comparative analysis between HL7 FHIR and previous HL7 messaging standards.
Service-oriented medical device architectures make the progress from interdisciplinary research projects to international standardisation: A new set of IEEE 11073 proposals shall pave the way to industry acceptance. This expected availability of device observations in a standardised representation enables secondary usage if interoperability with clinical information systems can be achieved. The Device Observation Reporter (DOR) described in this work is a gateway that connects these realms. After a user chooses a selection of signals from different devices in the digital operating room, the DOR records these semantically described values for a specified duration. Upon completion, the signals descriptions and values are transformed to Health Level Seven version 2 messages and sent to a hospital information system/electronic health record system within the clinical IT network. The successful integration of device data for documentation and usage in clinical information systems can further leverage the novel device communication standard proposals. Complementing these, an Integrating the Healthcare Enterprise profile will aid commercial implementers in achieving interoperability. Their solutions could incorporate clinical knowledge to autonomously select signal combinations and generate reports of diagnostic and interventional procedures, thus saving time and effort for surgical documentation.
The current lack of medical device interoperability can only be overcome by the usage of structural and semantic standards. Therefore, a modern service-oriented architecture for systems of networked medical devices has been developed within the IEEE 11073 series. Its application to new domains such as surgery also demands an extension of the IEEE 11073-1010X Nomenclature, which was initially designed for only a limited set of device types. We thus propose new terms for surgical devices and component interactions, options for the (limited) post-coordination of terms, and term mapping to SNOMED CT and LOINC. In addition, we discuss the development of device specialisation standards.
New IEEE 11073 standards for interoperable, networked pointof-care Medical Devices
--, "New IEEE 11073 standards for interoperable, networked pointof-care Medical Devices," in Engineering in Medicine and Biology
Society (EMBC), 2015 37th Annual International Conference of the
IEEE, Aug 2015, pp. 1721-1724.
Standard for Domain Information & Service Model for service-oriented Point-of-Care medical device communication
IEEE P11073-10207/D6 -Draft Standard for Domain Information
& Service Model for service-oriented Point-of-Care medical device
communication, IEEE Std., 2016.