gms | German Medical Science

Interoperability is a key factor for the success of information systems in healthcare. With the increasing number of medical devices and clinical information systems, there is also a growing demand for vendor-independent interoperability to integrate medical systems and software solutions into a comprehensive infrastructure in operating rooms, intensive care units, and hospitals in general.

Whereas there are already solutions for integrated operating rooms commercially available, they offer little flexibility, as only devices from the same proprietary ecosystem can be used, which usually significantly limits the choice of devices for a specific use case. Once a decision has been made in favour of one of these solutions, the dependency on the provider is very high. In many cases it is thus not possible to integrate the best device for a given application or to acquire the product with the best price-performance ratio. Therefore, an integrated OR based on multi-vendor interoperability not only improves the surgical workflow and increases patient safety, it may also be more economically viable [1].

Manufacturer-independent interoperability can contribute to improving healthcare delivery, whereas a lack of interoperability prevents the development of cooperative assistance systems. In the context of medical devices, interoperability is characterised by the exchange of information between independent, heterogeneous systems. Semantic interoperability furthermore enables these systems to consistently interpret and use the information being exchanged [1]. This can be achieved through consistent application of standards that define the syntactic rules and semantic interpretation of data. To meet these specific needs, communication architectures and protocols have been developed and standardised. For integrated clinical environments, the most recent innovations are captured in the standards ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) and HL7 Fast Healthcare Interoperability Resources (FHIR).

ISO/IEEE 11073 SDC focuses on cross-manufacturer device-to-device communication in high-acuity environments and provides interoperability of point-of-care medical devices (PoCD). The ISO/IEEE 11073-10207 Domain Information and Service Model defines the network representation of generic medical devices and consists of the device description and dynamic information about the current device state.

The HL7 FHIR standard supports the exchange of data between software systems in the healthcare sector. It combines the advantages of the established HL7 standard product lines Version 2, Version 3 and CDA with those of current web standards and focuses on an easy implementation.

In clinical environments, communication takes place not only within the domains of medical devices and clinical information systems, but also between them. Focusing on only one of these two domains would not lead to a holistic solution. Interoperability between devices and information systems is therefore necessary to maximise the potential for optimising healthcare delivery and streamlining clinical workflows.

An Implementation Guide (IG) is a document published by a domain, institution, or provider. It characterises how HL7 FHIR is tuned to support a particular use case or a set of use cases. In this context, the use of medical devices using the ISO/IEEE 11073 SDC communication protocol is a use case to which HL7 FHIR should be adapted. Such an IG comprises a collection of functional instructions, profiles, value ranges, and documentation describing a variety of interoperable applications. The main component in this work is the mapping. An IG that includes the mapping of medical device data from ISO/IEEE 11073-10207 to HL7 FHIR is expected to facilitate more flexible communication between medical devices and clinical information systems without loss of information.

The consistent use of communication standards should also enable the storage and referencing of medical device data in clinical repositories in the future. A typical clinical information system would filter out a lot of device data because the data model is only used to store results and findings rather than large amounts of measurement data from many medical devices. Also, today’s clinical IT infrastructure hardly includes extensive data analysis capabilities that could effectively reuse the data, e.g. to assess quality of care or to conduct clinical research. One possible solution is the introduction of clinical repositories. They are commonly described as databases that reference and store data from multiple sources to enable e.g. big data analysis, telemedicine, integrated care, etc. [2]. FHIR servers are one possible implementation approach to establish a clinical repository architecture with underlying storage and retrieval capabilities that enable the processing of larger amounts of heterogenuous clinical data than current hospital information systems. Through storing more contextual information and metadata as well as the ability to efficiently store large sets of values on FHIR servers for clinical repositories, the use of HL7 FHIR has the potential to increase interoperability between different clinical domains [3].

In this work, we present an IG that contains a mapping of medical device data from ISO/IEEE 11073-10207 to HL7 FHIR in order to improve vendor-independent interoperability.

A similar approach is described in an article by Trigo et al. [4], which deals with harmonising the use of openEHR and ISO/IEEE 11073. Hospitals and health care providers using openEHR, just like those using HL7 FHIR, need proper integration of data from external sources, such as ISO/IEEE 11073. Therefore, the classes and attributes of a representative number of ISO/IEEE 11073 specialisations for medical devices – weight, temperature, blood pressure, pulse and heart rate, oximetry and electrocardiograph – were analysed and mapped to openEHR archetypes together with the ISO/IEEE 11073-20601 core document on Personal Health Device (PHD) communication [4]. Their proposed methodology reuses the existing archetypes where possible and proposes new ones – or appropriate modifications – elsewhere.

FHIR is the most recent development of HL7: a standard that focuses on implementable artifacts, so-called Resources, for exchanging healthcare-related data. It contains neither an information model nor a reference architecture [5] but defines a uniform interface that aims to accelerate the uptake through simplicity [6]. The definitions used herein are based on HL7 FHIR version R4 4.0.0. HL7 FHIR is focused on a RESTful approach using a simple and established mechanism for data access in distributed systems.

Representational State Transfer (REST) is an abstraction of the structure and behaviour of the World Wide Web [7]. The resource paradigm and the statelessness of the Hypertext Transfer Protocol (HTTP) enable a high scalability [8]. The implementation of REST follows four basic design principles:

1.

Using HTTP methods and caching,

2.

statelessness,

3.

uncover directory-structure to resources like URI, and

4.

transmission of data formats XML, JSON and RDF as resource representations.

HL7 FHIR does not make any assumption about the existing system implementation and allows faster integration and development cycles [6], [8]. The HL7 FHIR standard also includes implementation examples, and reference implementations for multiple platforms, including live test servers over the Internet. HL7 FHIR consists of three building blocks: Resources, references, and profiles.

Resources are compact, logically delimited units of data exchange with a well-defined behaviour and unique semantics. They represent the basic information unit in a RESTful environment. Resources are the smallest unit of transmission, representing the entire spectrum of health care with ca. 150 specifications. Therefore, resources can not only be used for the communication of clinical data but also cover business processes, vocabularies, IGs, and more [5]. The expression of the specifications in resources simplifies machine processability enormously. Each resource contains structured data that covers the usual use cases, a human-readable summary of the content, and so-called extensions to support further individual use scenarios, which are not already contained in the usual use cases. Resources can use links to refer to other resources. These references create a network that can, for example, describe an entire patient record.

The parallel development processes of the data model ISO/IEEE 11073-10207 and HL7 FHIR have influenced each other. Therefore, HL7 FHIR already offers practical building blocks for the modelling of ISO/IEEE 11073 SDC devices and the representation of their attributes and measurements through the use of resources [9].

The ISO/IEEE 11073 Health informatics – Point of Care medical device communication series consists of communication standards that enable communication between medical devices, healthcare devices, and external computer systems. They provide automatic and detailed electronic data collection of information about the patient, vital data, and operating data of the devices [1]. The main components are the following three sub-standards:

1.

ISO/IEEE 11073-10101 – Nomenclature
This standard contains nomenclature codes for the unique identification and description of objects and attributes as well as parameters and measurement data. The nomenclature is divided into different partitions to define the content and function of the code.

2.

ISO/IEEE 11073-10201 – Domain Information Model (DIM)
The ISO/IEEE 11073-10201 DIM reflects the relationships of elements in an object-oriented hierarchy and provides the data structure: The medical device is represented by a Medical Device System (MDS) object that comprises one or more Virtual Medical Devices (VMD). A VMD may contain Channels that are logical groupings of Metrics, possibly multiple instances of a particular type of measurement. The metric object is the basic element of actual data transmission, which generally represents a particular type of measurement or observation and is associated with a particular code from the ISO/IEEE 11073-10101 Nomenclature as well as unit of measure. Each level of the so-called Containment Tree of the model are annotated with nomenclature terms to facilitate machine interpretability.

3.

ISO/IEEE 11073-20101 – Base Standard
The Base Standard defines the structure and transfer of objects and attributes. A distinction is made between the Communication Model and the Information Model. The communication model describes layers 5 to 7 of the OSI layer model and the information model defines the modelling, formatting and transmission coding of the respective objects [10].

Since the transport mechanisms of the original series, which focused on point-to-point communication for medical devices close to patients, cannot be implemented for multipoint-to-multipoint communication, the ISO/IEEE 11073 SDC standard series was developed. This is a communication protocol for medical devices used in high-acuity environments. The initial set of three core standards was developed in the OR.NET research project funded by the German Federal Ministry of Education and Research (BMBF) [1]. The fundamental idea for this communication is based on the Service-Oriented Architecture (SOA) paradigm, which was extended to a Service-Oriented Medical Device Architecture (SOMDA) during the OR.NET project.

ISO/IEEE 11073 SDC addresses cross-vendor device-to-device communication and aims for the interoperability of PoCD. ISO/IEEE 11073 SDC thus describes the first technical specification for a fully distributed architecture that implements the SOMDA. Therein, ISO/IEEE 11073 SDC does not compete with other medical communication standards such as HL7 or DICOM, but complements them for previously unsolved use cases.

The ISO/IEEE 11073 SDC standard family consists of three components. Firstly, it contains the transport technology standard ISO/IEEE 11073-20702 Medical Devices Communication Profile for Web Services, which ensures the foundational interoperability of medical devices through safe data exchange. Secondly, the family includes the ISO/IEEE 1173-10207 Standard for Domain Information and Service Model for Service-Oriented PoCD Communication. This describes the structure of the data being exchanged and is divided into the device description and the current device state of the medical device. This standard thus addresses structural interoperability. Lastly, it contains the ISO/IEEE 11073-20701 Standard for Service-Oriented Medical Device Exchange Architecture and Protocol Binding. This specifies the service-oriented medical device architecture by i.a. binding the domain information and service model to the web service implementations. The mandatory use of the ISO/IEEE 11073 Nomenclature on all levels of the containment tree enables semantic interoperability [1], [11].

In the ISO/IEEE 11073-10207:2019 standard, the device information is organised hierarchically into four levels. The uppermost level is the object-oriented abstraction of a PoCD, the MDS, followed by the VMD on the next level, which represents the abstraction of a medical subsystem. They represent structural levels of complex PoCD and cannot be found in PHD. The Channel allows for the logical grouping of Metrics for hierarchical information organisation. A Metric is an abstraction of a PoCD component that generates or stores biosignal measurements, settings, or status values ([12], p. 57–68).

The IG for ISO/IEEE 11073 SDC developed within the scope of this paper is aligned with work in other guideline documents, including the HL7 FHIR IG for PHD and the general IG for PoCD, i.e. patient-oriented diagnostics and therapy.

This IG describes how information from Personal Connected Health Alliance (PCHA)-certified PHD is represented in HL7 FHIR. PHDs are devices mainly used in home care and include PCHA-certified devices such as blood glucose meters, blood pressure cuffs, scales, thermometers, etc. In this context, the data from a PHD includes both the measurements performed by the PHD and information about the PHD itself. PHD data includes features, operating status, and functions of the instrument, such as serial number, manufacturer name, and firmware version. Typically, the PHD is located at home with the patient or on the person themselves.

The purpose of this IG is to define the mapping of PHD data to HL7 FHIR resources. For the consumers of the HL7 FHIR resources, this IG specifies the HL7 FHIR components that contain the necessary PHD information.

This guide defines the use of HL7 FHIR resources to transmit measurements and supporting data from PoCD for acute care to receiving systems for electronic patient records, to support clinical decisions, and to archive medical data e.g. for measuring the quality of care or research purposes. The guide focuses on acute care devices for professional use, mainly in healthcare facilities. The main objectives include the addition of full data provenance information for traceability as well as further details on device architecture and attributes, such as calibration history and battery condition. These are not included in a common HL7 FHIR Observation resource.

The guidelines for PoCD and ISO/IEEE 11073 SDC both use information models and nomenclatures from the ISO/IEEE 11073 Medical Device Communication Standard Series. The IGs for all types of devices are being developed in collaboration with the Devices-On-FHIR (DoF) [13] project with the goal of consistency and usability when the resources are consumed by receiving systems.

Data mapping is defined as the alignment of data elements from two different data structures. This is a method for analysing, organising, and presenting information. The presentation is based on the interests of the target group and the purpose of the information. The method is mainly used in the design and development of technical communication [14].

Data mapping is used to transform or mediate data between a data source and a destination. This requires the identification of data relationships. Essentially, a data mapping on attribute-to-attribute basis analyses how data can be transferred from one system to another. This analysis ensures that each piece of information is mapped to the most appropriate location in the target data structure. To achieve this goal, a data mapping contains a list with the attributes of the original data source and a corresponding list with attributes of the target data model. The mapping also includes translation rules that define any transformation that may have to take place when information is exchanged between the two formats, such as mapping value sets, setting default values, or combining fields.

Creating a data mapping requires identifying and resolving potential problems on a conceptual level before implementing it. In data migration and integration tasks, a variety of differences in the way data is stored can cause data to be lost or misrepresented [15].

The first task is to identify HL7 FHIR resources equivalent to concepts from ISO/IEEE 11073-10207. For example, the MdsDescriptor represents the same concept as the HL7 FHIR Device resource. Afterwards, equivalent data items that meet the requirements must be connected. For example, the MdsDescriptor/MetaData/ManufactureDate corresponds to the Device.manufatureDate. If there is no matching element, a new element has to be extended. This includes limiting the cardinality of existing elements, making them mandatory, or removing them entirely. For example, the information about the approved jurisdictions of a device is present in ISO/IEEE 11073-10207, but it is not modeled in HL7 FHIR. In opposite, if there is an equivalent element, data types are checked and adjusted if necessary. If there is no loss of data, then the concept is accurately mapped. The results are then reviewed systematically by experts who participate in the standardisation of ISO/IEEE 11073 SDC and HL7 FHIR.

Profiles define how individual systems may use and combine HL7 FHIR resources. They detail which resources and extensions a system can communicate. The profiles can be specified and published by HL7, by regional user groups adopting national laws, or even locally to support individual use cases [5].

A profile contains restrictions for an HL7 FHIR base resource or another HL7 FHIR profile. The term profiling refers to the application of restrictions to resources. The process of creating a profile is a process of restricting different aspects of a basic resource or data type, so-called constraint. These may include limitations on allowed value sets, limiting or eliminating cardinality, and adding elements (extensions). The first step in creating a profile involves selecting a base resource or data type (e.g. a patient). The next step is to name the profile and provide a unique canonical Uniform Resource Locator (URL). After creating a profile, it is possible to start restricting the elements. For instance, fixed values can be used to specify a value that should be set exactly as the value for this element. An example of how to specify a value is to create a profile specifically for the weight of a newborn. This is done by creating an observation profile that is assigned a fixed value for Observation.code using a Logical Observation Identifiers Names and Codes (LOINC) code, a system, and a display name to specify what information is specified. The various constraints make profiled resources more suitable for the specific needs, but also raise the bar in terms of what criteria need to be fulfilled in order for a resource to meet the specified requirements [16]. To create a guide that meets the needs of the ISO/IEEE 11073 SDC standard, changes (restrictions) had to be made to several existing resources. If elements are not supported by the base resource yet, they can be added by using extensions. First the HL7 FHIR documentation [17] must be checked whether such an extension already exists. If no extension can be found, a new extension can be created. In the properties, context information, a canonical URL, the name and other relevant information can be specified. The context information contains a type that specifies whether the extension extends a resource, a data type, a mapping, or another extension. Then the specific resource or data type that should be extended is selected. A new extension begins with an element that contains a value that can be specified from all available data types. Figure 1 [Fig. 1] shows an example of a profiled and extended resource.

This work, in extension of both ISO/IEEE 11073 SDC and HL7 FHIR, enables the data exchange between medical devices and clinical information systems. The purpose of this IG and the relationships to other IGs have already been comprehensively presented in the Introduction and Material & Methods of this paper. This IG [18], which contains the mapping, new profiles, value sets, and code systems, is intended for medical device manufacturers, system integrators, HL7 FHIR architects, patients, and clinical users of patient-related device information.

Aligning the two data structures was necessary to achieve interoperability between both communication standards. Therefore, ten different base resources were selected and two of them were profiled (five profiles) (Figure 2 [Fig. 2]). Wherever possible, a mapping for the elements and attributes of the ISO/IEEE 11073-10207 DIM was defined (213 mappings), and 33 extensions were added where there was no suitable corresponding element available. The results have been reviewed systematically by experts who participate in the standardisation of ISO/IEEE 11073 SDC and HL7 FHIR.

With the help of profiling mechanisms, HL7 FHIR profiles were defined that enable the representation of ISO/IEEE 11073 SDC devices for communication while minimising the loss of information. The containment tree of the ISO/IEEE 11073-10207 DIM is modelled using the base resources Device and DeviceMetric (Figure 3 [Fig. 3]). The SDCDeviceMetric represents a single parameter of a PoCD, e.g. a measurement or a setting. DeviceMetric, the basic resource of SDCDeviceMetric, is already designed to describe classic ISO/IEEE 11073-10201 DIM metrics. It was therefore only necessary to build an extension adding support for the ISO/IEEE 11073-10207 DIM MetricDescriptor. This includes, for example, the relation. A relation enables the modeling of relationships between a metric and other containment tree elements, representing e.g. the effect that a setting has on other parameters.

In SDC the current value of a Metric can be obtained from the instances of MetricState. Representing an actual (clinical) data element, the profile SDCObservation, derived from the observation resource, is the equivalent HL7 FHIR structure. All of the metadata contained herein generally refers to the actual value itself, such as timing, subject, body site, performer, etc., as opposed to the device’s capability to obtain the value, which is described in the DeviceMetric. The validity of a single measurement is an example of a metadata element that had to be added to the profile.

The MdsDescriptor, VmdDescriptor, and ChannelDescriptor containment tree levels are mapped to profiled Device resources (Figure 3 [Fig. 3]). An SDCDeviceChannel as a grouping of metrics dealing with semantically related information, e.g. a blood pressure channel within a patient monitor VMD to group together all metrics that deal with blood pressure, can be independent of the physical structure of the device. Elements at this level include a parent reference and a set of attributes shared with the component descriptors at higher levels, including for example OperatingMode and ApprovedJurisdictions. The OperatingCycles and OperatingHours can be defined for the Channel itself, thus they were added as extensions to the profile. An SDCDeviceVMD is a subsystem of an SDCDeviceMDS, such as the gas delivery and ventilation functions of an anaesthesia machine, or a software component that integrates multiple measurements from other VMDs into a risk assessment for clinical decision support. As with the SDCDeviceChannel, the OperatingCycles and OperatingHours have been extended, as well as the ApprovedJurisdictions.

The SDCDeviceMDS contains information about the medical device as a whole, such as manufacturer, model number, and other identifying features. Information about the ApprovedJurisdictions, operational information, and a reference to the operator of the device were added to the resource as extensions (Figure 1 [Fig. 1]).

Furthermore, the device description includes a safety classification of the data contained in this descriptor. The safety classification allows manufacturers of medical devices to limit their responsibility for the objects provided [12]. ISO/IEEE 11073-10207 provides a value set for this, but HL7 FHIR does not. In order to make the value set available for the mapping, a code system was created with the existing codes and then linked to a new binding value set (Figure 1 [Fig. 1]).

The PatientContext, LocationContext, and OperatorContext elements were mapped to the resources Patient, Location, Organisation, and Practitioner. These are not visualised in Figure 3 [Fig. 3] because the resources did not need to be profiled.

This section discusses structural difficulties as well as resource-specific problems that have occurred during the creation of the IG.

ISO/IEEE 11073-10207 and HL7 FHIR have significant overlap in content, but differ in structure. Most prominently, information about a medical device in the ISO/IEEE 11073-10207 standard is divided into the device description and the device state. HL7 FHIR, on the other hand, does not differentiate between description and state but collates this data in units with a unique semantic, the resources. It is thus not possible, nor necessary, to map identifiers such as the Handle occurring in every element of the domain information and service model. This unique identifier is used i.a. for reference from the device state to the descriptor.

Another structural difference can be seen in the opposing directionality of references in the two standards. To record the information about a location in HL7 FHIR, references must be used in ascending order starting with the lowest hierarchical instance. In ISO/IEEE 11073-10207 this data is not hierarchically ordered. This difference leads to difficulties in presenting the mapping and made it necessary to add explanatory notes on implementing location references in the IG. Besides, for a location in HL7 FHIR, it is not always clearly defined whether the location is part of another location or part of a managing organisation.

The representation of the hierarchy of the device information as part of the mapping is not easily possible as the references of HL7 FHIR and ISO/IEEE 11073 SDC are inverted. In HL7 FHIR, the physical or logical composition of a device is represented by the device pointing upwards using the Device.parent element. In ISO/IEEE 11073 SDC, however, a containment tree element has a list of child nodes but carries no reference to its parent (Figure 4 [Fig. 4]).

Apart from the structural differences, there were also problems concerning specific ISO/IEEE 11073 or HL7 FHIR contents. These include data that either could not be mapped or could only be mapped with loss of information.

The AlertSystem has not yet been mapped as it only relates to alert communication management, which has low relevance to clinical IT system for purposes other than logging and was thus out of the scope of this work [3]. There are, however, current efforts to define a DeviceAlert resource for HL7 FHIR as well as work on a corresponding IHE profile for alert dissemination using HL7 FHIR that could be used e.g. to distribute alerts to the pagers of clinical staff. Upon maturity of these definitions, the IG will be extended accordingly.

Furthermore, the sex and gender of a patient (or a newborn) cannot be mapped from ISO/IEEE 11073-10207 to HL7 FHIR. The domain information and service model only contains an attribute for sex as defined by biological and physiological characteristics. HL7 FHIR, on the other hand, only provides a field for gender as defined by the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate. The biological sex, however, does not necessarily match a person’s administrative gender. Mapping from one to the other would therefore introduce errors. If necessary, an implementer can convey the biological sex as a coded observation type.

In comparison to the IG for PHD, the information about the operator of a medical device is modelled differently. In this IG, the reference to the operator of a medical device only allows for a practitioner, who is a healthcare professional. For PHD, however, a patient could also be the operator.

Another problem arises when mapping the value sets of the ISO/IEEE 11073-10207 DIM to the value sets of HL7 FHIR. In some cases, these value sets do not match exactly. If the HL7 FHIR value set is not extensible, it can happen that several codes from the ISO/IEEE 11073-10207 DIM have to be mapped to one code in HL7 FHIR. This is the case, for example, when the codes of the activation state of the MdsState are mapped to the codes of the value set statusReason for the device availability. Three values from ISO/IEEE 11073-10207 are mapped to “not-ready”, whereby the more precise semantics are lost. After transformation, it is therefore no longer possible to trace which state the device originally reported.

A total of approximately 25 conflicts occurred. These include, for example, the loss of semantics when mapping the value sets in several cases. However, this is not considered critical, since in all cases the granularity of the value sets in ISO/IEEE 11073-10207 is higher than in HL7 FHIR (e.g. the distinction of metric categories) and this information is not considered to be highly relevant for our applications of HL7 FHIR. Nevertheless, this restricts the bidirectionality of our mapping. In four cases, either no solution could be found or it was not necessary to do so. One of the cases where it is not necessary to build an extension, is that ISO/IEEE 11073-10207 differentiates between a neonate and a patient. HL7 FHIR does not differentiate between patients. Another case where no extension was created is the conflict with the sex and gender of a patient, as described above. The information of a battery, e.g. the capacity or voltage of a battery, is not represented in our mapping, because up to now this information does not need to be transferred to a hospital information system for our application. The fact that this data also does not appear in the mappings of the related IGs contributed to this decision. For alarms, for example, a solution is under investigation. In all other cases, a solution could be worked out.

In this work, an IG for the mapping of medical device data from ISO/IEEE 11073-10207 to HL7 FHIR has been created. This mapping helps to bridge the structural interoperability gap between two communication architectures for medical devices and clinical information systems. Thereby, we create the basis for semantic interoperability that can be achieved through the consistent use of terminologies. By retaining contextual information and metadata and the ability to efficiently store large sets of values on FHIR servers in a clinical repository, the application of this IG not only increases interoperability between different clinical domains, but also enables safe and reliable automated interpretation of the transformed data. It furthermore enables effective reuse of device data for secondary purposes, such as clinical research or quality of care assessment.

A total of 213 data elements were mapped. Five profiles were created, as well as three value sets with the corresponding code systems. In cases where conflicts occurred, a solution could almost always be found, or the conflicts were not considered to be critical.

The objective of improving the interoperability of medical devices will continue to be pursued after the completion of this work. On the one hand, the DoF initiative pursues the interest of being able to represent the information of events and alerts of PoCD using a new HL7 FHIR resource [13]. On the other hand, work has begun to consolidate the general IG for PoCD and the IG presented in this paper. For the most part, the respective mappings remain unchanged. The profiles, however, have to be merged to the ultimate goal of being able to represent all kinds of PoCD, irrespective of whether they provide an ISO/IEEE 11073 SDC interface, classic ISO/IEEE 11073, IHE PCD-01 messages proprietary interconnection, or solely rely on HL7 FHIR.

In addition, further development of the ISO/IEEE 11073 SDC series of standards is taking place. The research project Modular Specialisations for Point-of-Care Medical Devices (PoCSpec, 2019-2020) develops particular standards for specific device types from the domains of endoscopy and high-frequency surgical equipment. The goal is to precisely define the scope, structure, and semantics of the data and services offered on the network as well as the behaviour of these specific devices at runtime [19]. Using the IG described in this work, it will be possible to automatically transform their network representations to HL7 FHIR and unlock the potential of their operating data for secondary use.

The authors declare that they have no competing interests.

The corresponding author was supported by a scholarship of the Friedrich-Wingert-Stiftung.