Literature Review: Clinical Data Interoperability Models

1. Introduction

Medical entities exchange wide numbers of various data between different systems. The interoperability is generally guaranteed inside of the same medical entities but in fact, interoperability problems between medical entities are regularly observed. These incompatibility problems result in multiple repeat examinations for the same patient, an overload of healthcare facilities, and costs related to the examinations that had to be repeated.

On the other hand, the increase in the world population leads inexorably to a progressive saturation of healthcare capacities. It has become crucial to increase these structures’ availability and operating costs by avoiding unnecessary examinations. At the same time, the development of telemedicine means that patients no longer need to be systematically transferred to healthcare facilities. For savings and efficiency improvements to be made, improvements must be made to the interoperability of systems and data exchange standards to make them efficient.

The comparison and study of system interoperability standards and data standards is a prerequisite for understanding the sticking points and proposing solutions.

The goal is to emerge insights to build the data interoperability proposal and address issues of actual interoperability models.

Main contributions to this paper are:

• The summary of main data standards used in medical context
• The study of the different interoperability models highlights these model’s pros and cons.
• The highlight of required features of a medical interoperability reference model

The rest of the paper is organized as follows: Section 2 explains the principal data standards used to characterize medical data. Each standard is described, and its field of application is given. Afterward, Section 3 highlights standards implemented to ensure the interoperability of medical data identified in the previous section. Section 4 proposes a state-of-the-art focusing on the implementation of the standards identified in section 3. Then, it is proposed, in Section 5, a comparative study of data interoperability models in the medical context. Afterward, it is discussed and highlighted features of the ideal interoperability model and drawn limits of the work, in Section 6. Finally, the work is concluded with lessons learned from the analysis and the perspectives of our work is considered.

2. Main health system interoperability standards

This section presents the main interoperability standards: Health Level 7 (HL7) and its derived standard, Fast Healthcare Interoperability Resources (FHIR), Digital Imaging and Communications in Medicine (DICOM), and JavaScript Object Notation (JSON). Each standard is analyzed, and its main features are emphasized. HL7 is a widely used standard for healthcare information exchange, while FHIR is a more modern and flexible standard built upon HL7. DICOM is specifically designed for medical imaging data, facilitating the sharing and interoperability of images across different systems. JSON is a lightweight data-interchange format commonly used in web applications. At the end of this section, a table summarizes all these features.

2.1. Health Level Seven (HL7) Standards

HL7, founded in 1987, is a non-profit standards development organization dedicated to creating standards for hospital information systems. Over time, it has grown into a global community of health information experts who work together to develop standards that promote the exchange of health information and enable interoperability among health systems [1], HL7, which stands for Health Level Seven, is a set of international standards for the exchange, integration, sharing, and retrieval of electronic health information. These standards define a framework, messaging formats, and protocols for the interoperability of healthcare IT systems within and across organizations. The HL7 format refers specifically to HL7 Version 2 (V2). This version is widely used and has been implemented in various healthcare settings globally. It enables the electronic exchange of health data between different computer systems, such as electronic health records (EHR) systems, laboratory information systems, pharmacy systems, and other healthcare applications. The HL7 V2 standard provides a structured format for representing healthcare data and a messaging framework for transmitting that data between systems. It defines a set of message types and segments, which serve as building blocks for creating messages that carry specific types of health information. These messages can include various types of data, such as patient demographics, clinical observations, laboratory results, medication orders, and more. The standard also specifies how the messages are structured, including the use of delimiters and data types, to ensure consistency and interoperability. Additionally, HL7 V2 provides guidelines for data exchange, message sequencing, and error handling to facilitate reliable and accurate transmission of health information. By adopting the HL7 V2 standard, healthcare organizations can streamline communication between their IT systems and improve interoperability. It allows for seamless sharing of health data, such as prescriptions, test results, electronic medical records, and other clinical information, across different applications and platforms. This promotes continuity of care, enables better coordination among healthcare providers, and supports more efficient and accurate decision-making. It’s important to note that HL7 has evolved beyond Version 2, with subsequent versions such as HL7 Version 3 (V3) and the emerging HL7 Fast Healthcare Interoperability Resources (FHIR) standard. Each version addresses different needs and challenges in healthcare data exchange, but HL7 V2 remains widely used and plays a significant role in enabling electronic health information exchange.

2.2. HL7 Clinical Document Architecture (CDA)

This standard developed by HL7. is a markup standard based on XML and HL7 RIM (V3), it is used to represent and facilitate the exchange and sharing of electronic medical records and clinical documents as used by [2,3,4]. It allows health data to be stored in a structured format that can be read and interpreted by computer systems, as summarized in Figure 1.

2.3. Fast Healthcare Interoperability Resources Standard (FHIR)

FHIR is a standard developed by Health Level Seven International which is a non-profit organization, this standard allows the exchange of medical data in JSON format in the form of different forms and elements called resources. These can be manipulated using an API Rest, something that helps the implementation of this standard easily and network different health systems medical entities to share and exchange health data between them in real-time as used by [1,5,6,7]. Using the Rest API for example “INSOMNIA”, it can either create a new resource or a list of FHIR resources in JSON or XML format using the POST method which will subsequently generate an ID for each resource and then it can search for them from the Rest server, this time with the GET method, specifying in the search criteria in the URL the type of the "Patient" example resource, and with the same transaction it can make the observation of resources loaded into the Rest server either by ID, name, etc. It can also modify, for example, the information of a patient using the PUT transaction by including the "observation" value for the "ResourceType" element. It can specify the type of resource it is working with, such as "Patient," in the URL preceding the PUT transaction of the resource. Subsequently, it can utilize GET transactions to retrieve the complete history of the resource, including all the versions in which changes have been made.The additional advantage of using the FHIR standard is that it can adapt the list of resources that we have already loaded in the Rest API or that it will create them using the Profile resource, then it can just create a profile with the same type as the group of resources that it has already put in an FHIR server, for example "Hapi FHIR" which will generate a URL of the profile, specifying the structure that will be required for each resource, well said the elements that must exist in each as well as a set of constraints that must be supported in the form of the cardinality of each element, and to apply it to a resource, simply copy the URL that corresponds to the profile that it created, we go back to the Rest API and paste it in the URL element without forgetting to modify the value of the "resourcetype" element to "structuredefinition" as the value all using the transactions post, it will conclude by following that the resource is well adapted to the new structure that it has already specified in profile FHIR in order to unify the structure of all the resources of the same type, and of course, we can with the same Rest API visualize all the possible operations on resources using the “options” transaction, as summarized in Figure 2.

2.4. Digital Imaging and Communications in Medicine (DICOM)

DICOM is a standard developed by National Electrical Manufacturers Association (NEMA). This standard is used to store, transmit and display digital medical images, such as X-rays, MRIs, and ultrasound images. It is subdivided into two main components the file format which is used to transmit and exchange images, and the DICOM network protocol which allows digital medical images to be displayed and stored in IOD formats, such as X-rays, MRIs, and ultrasound images, these two elements work together so that the images are in a standard format and the exchange of images is also standardized, as used by [8,9,10].

Figure 3 shows that it is with the help of a DICOM server for example "MiPacs Storage Server" which is an electronic database for data related to medical and dental imaging. While using the standard DICOM v3.0 protocol, it can store and manage a large amount of data as well as provide ways to access transferred images and exchange data about patients as well as procedures. This makes DICOM NETWORK Protocol allows to program of these procedures, as well as generating reports and retrieving images for and from objects and information systems. The DICOM v3.0 standard provides a means to communicate with various DICOM v3.0 compatible devices, including scanners and workstations. MiPACS Storage Server functions primarily as a DICOM provider, but other stations are also capable of exchanging DICOM files/images with it. The communication protocol employed employs TCP/IP as the transport layer, as demonstrated in Figure 3.

2.5. JavaScript Object Notation (JSON)

JSON is used to store and transmit health data in a structured data format. It is often used for data transmission via APIs as used by [11,12]. So you can take advantage of a Rest API to manipulate health data, so you can add a resource and load it into the server using the POST transaction, put changes on the resource with the PUT transaction and delete with the DELETE transaction and even retrieve the list of resource histories or observe the list of all resources by using the POST transaction, but neither the types of resources nor their structures nor defined by the REST standard, as summarized in the Figure 4.

2.6. Data interoperability standards

This section presents a comparative study of the data interoperability standards studied in the previous section in tabular format. To compare these different standards, it has based on the following criteria; the first one is the organization criteria that have developed the standard, the second one is the name of the standard or its version, then the description of the essential task that will be guaranteed by the standard, and finally the type of data supported that means the data generated after the implementation of this model.

This synthetic study can be summarized as follow: the HL7 Version 2 (V2) standard is used to exchange health data electronically between the computer systems of different organizations. It allows the transmission of data such as prescriptions, test results, and electronic medical records. While DICOM presents a format for exchanging, storing, transmitting, and displaying digital medical files and images in DICOM format, such as x-rays, MRIs, and ultrasound images. The CDA format is used to represent electronic medical records and clinical documents, allowing health data to be stored in a structured format that can be read and interpreted by computer systems. In addition to these standards, the healthcare industry also utilizes other protocols for exchanging healthcare information. Two commonly used protocols are MQTT and RESTful. Message Queuing Telemetry Transport (MQTT) is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high-latency networks. It follows a publish-subscribe model where a client can publish messages to a topic, and other clients subscribed to the same topic receive those messages. MQTT is suitable for healthcare applications that require real-time data exchange and efficient communication between devices, such as remote patient monitoring or sensor data collection. It is simplicity and low overhead makes it ideal for resource-constrained environments [13]. On the other hand, Representational State Transfer (RESTful) is an architectural style used for designing networked applications. It relies on HTTP protocols for communication and leverages the standard operations of GET, POST, PUT, and DELETE to interact with resources. RESTful APIs (Application Programming Interfaces) enable healthcare systems to expose their functionalities and allow other systems to access and manipulate the data through HTTP requests. RESTful APIs are widely used in healthcare applications for integrating different systems, sharing data securely, and enabling interoperability between healthcare providers [14]. Both MQTT and RESTful protocols play important roles in exchanging healthcare information. MQTT provides efficient and real-time communication for scenarios where responsiveness and low bandwidth usage are crucial. On the other hand, RESTful APIs offer a flexible and widely supported approach for integrating healthcare systems and accessing resources in a standard and interoperable manner. It is worth noting that while both MQTT and RESTful are widely used and provide significant benefits, the choice of protocol depends on the specific requirements and characteristics of the healthcare application or system being developed.

3. State of the Art Analysis and Comparative Study

3.1. State of the art

The implementation of the standards mentioned in the previous section within different architectures by different authors are presented.

In 2019, Mavrogiorgou et al [15], have developed a platform that initially addresses the collection of data that comes from different heterogeneous IoMTs devices to serve different application scenarios and deliver their data at different frequencies between them using the technologies 5G, in this article the authors proposed an approach divided into several stages; Data Acquisition this part is responsible for the collection of all the specifications, APIs, the network specifications in order to recover their data, Devices Information Collection, which makes it possible to identify the specifications of the connected object, step of Specifications Similarity which makes it possible to identify syntactical similarities between detected objects, Specifications Classification this part aims to classify specifications is to classify the specifications of each unknown device based on the K-Nearest Neighbors (KNN) algorithm [16], in order to group all unknown connected devices with existing known devices according to their specifications, PIs Mapping & Data Collection this part allows you to specify the device types detected and their API methods. The Slicing Management component utilizes the collected data to facilitate further analysis of the slicing management mechanism, as per the network specifications of the connected devices. The proposed mechanism is based on the 5G Network Slicing concept, which enables 5G Core (5GC) operators to allocate specific parts of their networks to support various medical scenarios. The Data Interoperability aspect of the mechanism involves constructing health ontologies from the acquired datasets and identifying the commonalities between these ontologies and those representing the HL7 FHIR resources. Subsequently, the datasets are translated into the HL7 FHIR standard. The Data Interoperability mechanism is implemented as a Chained Network Service in the 5GC, with each of the three different medical scenarios being allocated to its respective network slice. While the mechanism operates similarly for each network slice, the execution speed varies based on the computational requirements of the particular medical scenario. The Data Interoperability mechanism consists of four steps, including the ontology building system, syntactic similarity identifier, semantic similarity, and overall ontology mapper.

Verma et al in 2018 [17] described a cloud-centric IoT-based framework to monitor disease diagnosis and automatically predict potential diseases and their severity levels without the involvement of healthcare professionals. Moreover, these platforms not only offer physicians technologies that simplify the healthcare process but also provide them with tools to aid clinical decision-making. This has widely promoted the use of IoMT to improve healthcare and is now considered a pillar of new ubiquitous healthcare services [18].

Azariael al in 2016 [19] proposed a solution to tackle the problem of medical data security by utilizing smart contracts on the Ethereum blockchain. Their Smart Contract comprises three sub-contracts, including a Registrar Contract that links the user’s identity to their Summary Contract on Ethereum. The Summary Contract is utilized by patients to monitor their medical records and the Patient-Provider Relationship (PPR) Contract. The PPR Contract is responsible for managing the patient-provider relationship and defining pointers to query and retrieve patient data from the provider’s database. To share data with third parties, the patient node retrieves the PPR containing the desired data query and updates the third party’s PPR with the query and a hash code for the requested data. The third-party node then accesses the provider’s database, with the assistance of a gatekeeper that authenticates the signature of the original provider by analyzing the hash code, to recover the data.

Boutros-Saikali et al in 2018 [20], presented an implementation of the FHIR standard by proposing an IoMT platform that allows monitoring of patient biometric data by doing weekly monitoring of Body mass index (BMI) status and referral data to patients when needed or monitoring the patient activities daily by the platform to compare the statistics of the differences presented between the objectives of each patient and their real activity and send them à set of recommendations if needed, the control of the blood pressure of the patients will be monitored daily about the minimum and maximum thresholds to indicate to them the critical values if they are detected, as well as the daily follow-up of Blood glucose identified from different IoTs systems, this platform takes advantage of the artificial intelligence algorithm and the standardization of data formats. Data that comes from the IoMTs network provide practitioners with a virtual patient assistant, something that will help them identify abnormal situations by tracking data over time and then predict potential short or long-term dysfunction to ignite red light and advice them to act quickly.

The Pulmonary Vascular Research Institute, which comprises healthcare professionals and researchers focused on pulmonary hypertension (PH), is collaborating to establish an international registry/data repository for PH.

Sony et al in 2021 [21] proposed a semantic interoperability model related to medical health with the use of Healthcare Sign Description Framework (HSDF), based on the sign science "Semiotics" to ensure a good level of semantic interoperability of the data exchanged between several medical entities to avoid all problems of disambiguation of the meaning of the notes and to improve in terms of accuracy and similarity while using UMLs unified modeling language System).

Jabbar et al in 2017, [22] proposed an IoT-SIM model for achieving semantic interoperability among heterogeneous IoT devices in healthcare. The model aimed to enable physicians to remotely monitor their patients using various IoT devices, regardless of the vendor, by leveraging semantically annotated data. To this end, RDF was utilized to represent patients’ raw data in a meaningful manner. The model involved using IoT devices to diagnose diseases and semantically annotate the resulting information using RDF. A lightweight model was also proposed for semantically annotating data from heterogeneous IoT devices, which included descriptions of communication among these devices. The SWE framework was employed to enable sensors and devices to communicate with each other and provide web services. To ensure interoperability, the collected data was mapped to an RDF graph database, analyzed, and annotated for semantics. After the collected data was annotated, it was transmitted to the Intelligent Health Cloud for matching with the pharmaceutical companies’ prescribed medicines. The resulting information was then transmitted to the patient’s IoT devices, along with details about the prescribed medicine. The RDF graph database was used to represent the patients’ diseases database in triples, allowing it to be queried semantically using SPARQL.

Jaleel et al in 2020 [23] introduced MeDIC, a framework designed to enhance medical data interoperability among healthcare devices. MeDIC leverages translation resources at the network edge through its probing and translating agents, improving upon existing cloud-based IoMT approaches. MeDIC’s probing agents maintain a list of local MeDIC devices and facilitate data conversion requests between devices when a device lacks the capability for such conversion. The receiving device’s translating agent then converts the data into the required format and returns it to the requesting device. These innovative agents enable IoMT devices to share computing resources and minimize reliance on cloud access for data translations.

Fischer et al in 2020 [24] suggested a medical data interoperability model based on the HL7/FHIR standard and ETL aims to ensure the research and analysis of patient medical data which is in formats heterogeneous and to interrogate them above all in this register and adapt them to a common data model called Observational Medical Outcomes Partnership (OMOP), to achieve this model a set of domain knowledge experts have defined a group of common parameters, which have been mapped to standardized terminologies such as LIONIC or SNOMEDCT, then this data was extracted in FHIR format via Extract Transform Load (ETL) and transformed using XSLT in OMOP format in a reasonable time, the additional advantage of this model is that it allows practitioners to connect several heterogeneous databases. However, in adopting this platform, a complete ETL process must be implemented for each source separately, which will generate significant processing time in the event of massive data.

Zong et al in 2020 [25] proposed to design, develop and evaluate a computational system based on the FHIR standard that enables the automation of the filling of Case Report Forms (CRFs) for cancer clinical trials using Electronic Health Records (EHRs) real to represent the CRFs and their data population, they leveraged an existing FHIR-based cancer profile to represent colorectal cancer patient EHR data, and then used FHIR Questionnaire and Questionnaire Response resources to represent CRFs and their data population as well as they used synoptic reports of 287 Mayo Clinic patients with colorectal cancer from 2013 to 2019 with standard measures of precision, recall, and F1 score to test the accuracy and overall quality of the pipeline. Hong et al in 2017 [26], have proposed an interactive platform developed using the shiny framework and R packages for the generation of statistics and analysis of patient clinical data in FHIR format.

The proposed solution by Ullah et al in 2017 [27] entitled SIMB-IoT model, is dedicated to presenting a new model of semantic interoperability to guarantee interoperability between several connected medical objects which prevents different manufacturers and which generates very important content of data related to the field of health care, to make available to patients and practitioners, a drug recommendation system for the different symptoms collected from these connected objects, which then makes it possible to avoid the side effects of drugs according to the history of each patient.

3.2. Comparative study of data Interoperability models

This section is composed of two parts. The first one identifies the different possible modes of interoperability with the data. The second one proposes a synthetic study and an analysis of data interoperability models.

3.2.1. Data Interoperability

Interoperability can be defined as the ability to store, transfer and retrieve data from different sources in a fast and efficient way. It is subdivided into several types, technical interoperability; signified the physical connectivity established between the object to exchange bits and bytes, it is possible to exchange data but also contexts and information, focusing on the understanding of information as an integration object without using it, in this interoperability level the use of Electronic Health Records (EHR) is recommended to exchange Infrastructure and governance (persons/citizens, public health/research institutions, national digital health bodies, data protection authorities, health professionals and generates and patient associations), Semantic interoperability; where the Use of international standard reference systems and ontologies European Interoperability Framework (EIF) are recommended to describe the unambiguous representation of clinical concepts and also the use of the ISO 23903 standard is highly recommended t.and could be considered a useful guide in terms of establishing semantic interoperability in the European Health Data Space (EHDS), Dynamic interoperability; information, its use, and applicability, i.e. knowledge can be exchanged, focusing on contextual changes events as integration objects. The most prominent exchange format for health data is Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) to exchange medical data resources in different formats, Syntactic interoperability; data can be exchanged in standardized formats, with the same protocols and formats supported, which is achieved when health data is kept in standardized data formats thanks to the use of XML or Rest format European Interoperability Framework (EIF); Service interoperability: exchange of services between two software, Communication interoperability; focus on data information as an integration object without context, ability to exchange data and use information as an integration object, i.e. data format and syntax and the last and the main level is the organizational level in which interoperability will be achieved when processes, user roles, and access rights are harmonized and clearly defined.

3.2.2. Comparative study between data Interoperability models

Table 2 describes the pros and cons of the main health data interoperability models by describing the type of interoperability addressed by the data type.

4. Discussion and work limitations

In 2019, Mavrogiorgou et al [15] proposed a solution for FHIR data acquisition and transformation via 5G network slicing. The platform they proposed can effectively manage healthcare data, leveraging the latest data acquisition, 5G network slicing, and data interoperability techniques. this platform solves the problem of heterogeneity of medical data by transforming data via 5G from medical objects into FHIR resources, but this solution remains limited to meeting research and high processing requirements on the FHIR data. Verma et al in 2018 [17] proposed a three-phase conceptual framework for an IoT-based m-Health Monitoring system. In the first phase, users’ health data is collected from medical devices and sensors and sent to a cloud subsystem using a gateway or Local Processing Unit (LPU). In phase 2, the medical measurements are used by a medical diagnosis system to make a cognitive decision regarding the individual’s health. In phase 3, alerts are generated for caregivers or parents regarding the person’s health status. In case of an emergency, alerts are also sent to nearby hospitals to handle the medical emergency. However, their solution did not address the interoperability of medical data and did not implement any standard, such as the FHIR standard, for data interoperability. While Azaria et al in 2016 [19], proposed a solution that will be used by patients to track their medical records and the Patient by analyzing the hash code originally generated by the originating Provider and Provide Relationship (PPR) Contract, which ensures semantic interoperability and security of medical data but the problem with this solution is that it does not present a centralized data architecture that patients can use for storing and retrieving their medical data in the desired format. Boutros-Saikali et al in 2018 [20], proposed an IoMT platform as well as a virtual doctor and monitoring application which aims to provide a solution to ensure the interoperability of monitoring applications and their security as a proof of concept, to the use of the interoperability standard of FHIR medical data, and the REST API, but this solution has the same limitations related to demanding research and high processing requests on medical data with the FHIR standard as the platform proposed by Verma et al in 2018 [17]. Sony et al in 2021 [21] described a centralized semantic interoperability model which ensures the interoperability of data using UMLS ontology [29] and HDFS presents an improved model in terms of accuracy and similarity of healthcare signs, vital signs, medication signs, or symptom signs, while these data must be exchanged between several medical entities in a unified format hence the need for a standard to ensure organizational interoperability to ensure the storage and retrieval of these signs which are on different forms with a standardized form. Jaleel et al in 2020 [23], This article presents the MeDIC platform, a framework for the interoperability of medical data through the collaboration of health devices. MeDIC which integrates both polling agents orchestrates translation requests according to the capacity of each of the Medic devices and by the translation resources which then allow the data to be converted into the required format to another which allows users of IoMs to minimize access to the cloud. While Fischer et al in 2020 [24] have proposed a model based on ETL to extract, transform, and load medical data from different databases in FHIR form but the implementation of this solution is heavy and does not respond to a complicated request for medical data, the same limit is for the model proposed by Zong et al in 2020 [25]. The performance of the framework Shiny FHIR proposed by Hong et al in 2017 [26] does not ensure research in a larger mass of medical data which limits access to the records and does not provide a framework for the generation of data in a specific format equivalent or not to the data format of the source as well as other technical issues related to interoperability with new versions of the FHIR standard. While Ullah et al in 2017 [27] proposed a SIMB-IOT model as a semantic interoperability model for heterogeneous IoMT devices by the use of an RDF database constricted based on two different databases, the first one is a database of diseases including drugs details and the second database contain medicines with an overview of their side effects presented in a graphical form, that can be easy views and supervised by patients and doctors simultaneously by the use of SPARQLsedu on, but this model does not cover the transformation of medical data formats into the format desired by patients and practitioners but sends them recommendations. Finally, it must be mentioned the limitations of this work. Only the main interoperability standards have been considered, the inventory is not exhaustive. State-of-the-art was not achieved following a systematic review methodology. The comparison of standards has been achieved based on the literature but not on the concrete implementation of them.

The potential use of the FHIR standard which can be used to develop patient monitoring and diagnostic applications and help practitioners and medical entities achieve a high level of data interoperability has been argued. The following table indicates the parameters and their compatibility within the discussed models:

Table 3. Key Interoperability models discussed and their compatibility with certain parameters.

Model	Data Interoperability	Standard (FHIR)	Centralized Architecture	Real-time Monitoring	Ease of Implementation
Mavrogiorgou et al [15]	Yes (limited to research)	FHIR	No	Yes	Moderate
Verma et al [17]	No	N/A	Yes	Yes	Moderate
Azaria et al [19]	Yes	N/A	No	No	Moderate
Boutros-Saikali et al [20]	No	FHIR	No	Yes	Moderate
Sony et al [21]	Yes	UMLS ontology	Yes	Yes	Moderate
Jaleel et al [23]	Yes	N/A	No	Yes	Moderate
Fischer et al [24]	No	N/A	No	No	Complex
Zong et al [25]	No	N/A	No	No	Complex
Hong et al [26]	No	N/A	No	No	Complex
Ullah et al [27]	No	N/A	No	No	Moderate

Table 3. Key Interoperability models discussed and their compatibility with certain parameters.

Model	Data Interoperability	Standard (FHIR)	Centralized Architecture	Real-time Monitoring	Ease of Implementation
Mavrogiorgou et al [15]	Yes (limited to research)	FHIR	No	Yes	Moderate
Verma et al [17]	No	N/A	Yes	Yes	Moderate
Azaria et al [19]	Yes	N/A	No	No	Moderate
Boutros-Saikali et al [20]	No	FHIR	No	Yes	Moderate
Sony et al [21]	Yes	UMLS ontology	Yes	Yes	Moderate
Jaleel et al [23]	Yes	N/A	No	Yes	Moderate
Fischer et al [24]	No	N/A	No	No	Complex
Zong et al [25]	No	N/A	No	No	Complex
Hong et al [26]	No	N/A	No	No	Complex
Ullah et al [27]	No	N/A	No	No	Moderate

Note: "N/A" indicates that the specific model did not address or implement the parameter in question.

Based on the discussion above, the necessary characteristics of a reference model for medical interoperability can be inferred as follows:

Data Transformation: The reference model should facilitate the transformation of medical data into a standardized format, such as FHIR, to ensure compatibility and interoperability across different systems and applications. Interoperability Standards: The model should support the use of interoperability standards like FHIR, which enable seamless exchange and integration of healthcare information. Semantic Interoperability: The reference model should address the semantic interoperability of medical data, ensuring that the meaning and context of data are preserved and understood consistently across different entities and systems. Centralized Data Architecture: An ideal reference model should provide a centralized data architecture that allows patients to store and retrieve their medical data in the desired format, promoting accessibility and efficient data management. Security and Privacy: The model should incorporate mechanisms to ensure the security and privacy of medical data during its exchange and storage, complying with relevant regulations and standards. Modularity and Extensibility: The reference model should be modular and extensible, allowing for the incorporation of new components, technologies, and standards to accommodate evolving healthcare requirements and advancements. Performance and Scalability: The model should be designed to handle large volumes of medical data efficiently and scale to support interoperability across diverse healthcare entities and systems. Integration with IoT Devices: As highlighted in the discussion, the reference model should consider the integration of IoT devices and health devices to enable seamless data exchange and collaboration between different health devices and systems. Governance and Maintenance: The reference model should have a well-defined governance structure and ongoing maintenance processes to ensure its long-term sustainability, relevancy, and continuous improvement. Practical Implementation: The model should address the practical implementation challenges associated with interoperability, including data extraction, transformation, and loading processes while considering the complexity of medical data and the specific requirements of healthcare organizations.

These characteristics reflect the specific context and considerations mentioned in the discussion and highlight the key aspects that a reference model for medical interoperability should encompass to facilitate effective data exchange and integration in the healthcare domain.

5. Conclusions and perspectives

This paper focused on the main standards used to describe and characterize data in the medical field. It is continued by the identification of standards allowing data compatibility and ensuring their interoperability. Afterward, a state-of-the-art allowed us to analyze concrete implementation on real use cases and highlight the pros and the cons of all these approaches. This analysis enabled us to identify and discuss ideal features of the data interoperability model for the medical field.

The analysis of the literature has shown that each of the models that have been studied in the state of the art presents different limits on the technical side or the standardization side of medical data, To alleviate these limitations, the features of the ideal reference model have been identified. This model is characterized by the capacity to identify medical data of any type by a medical entity and store them in a centralized database in a unified format and extract it from this database by another entity in the desired format while drawing advantage of the technologies used in the previously proposed models that it has studied as an example UMLS as the model presented by Sony et al, which presents the best reference interoperability model to exchange medical data, and that can help us to ensure the study of similarities with ontological medical data identified from different medical databases, the cloud that can be used for medical data storage, and the ETL that can help us for the extraction, transformation, and construction of a structured database.

In future works, based on the state-of-the-art analysis and the conclusion of this paper, will develop a new reference model of interoperability systems and then build an adapted interoperability architecture. This paper has shown that the HL7 FHIR standard is particularly well adapted for exchanging and storing health data. While DICOM, CDA. JSON can be converted in HL7 FHIR or HL7 FHIR to these formats for interoperability purposes. This approach covers almost all use cases. These features will be implemented in the future architecture which will be published in the next paper.