CDA and FHIR are health data interoperability models developed by HL7 (44); both are designed with a hierarchical structure of data types and resources. For instance, CDA includes four code data types: CS (code simple), CV (coded value), CE (code with equivalents), and CD (concept descriptor) (see Figure 4). CS is the simplest, while CD is the most complex. Complex data types are composed of simple data types. In CDA, the simplest data type may be a subset of a more complex data type, for example, a CS is a subset of a CV data type. In FHIR, resources are categorized into metadata, special-purpose, general-purpose, and primitive data types (58). In both models, the depth of objects in the XML or JSON document tree can become very large. In the case of large CDA documents, the depth of the document trees results in very voluminous transformations.

The transformation is the entire process of converting the resource, while the transformation rules are the detailed steps that specify how each attribute within the resource should be handled. Transformation rules are applied to convert the extracted data from its previous form into the required form. These rules could involve various instructions, such as extraction, conversion, or formatting. The transformation map, conversely, is not just an abstract concept but manifests itself as a tangible artifact. Every transformation map may be reused as a transformation rule in another transformation. Correct transformation rules and maps are fundamental in defining transformations, such as transforming CDA documents to the FHIR Bundle resource (59), as needed in the ENHIS. We identified the required transformation rules and maps between the data types and models of these two standards and created corresponding transformation components. We found that transformation components of simple data types, such as CD to CodeableConcept and II (instance identifier) to Identifier (see Figure 4), can be reused in more complex data types and model transformations. Such reuse simplifies the development of transformation rules and maps, improves clarity, and reduces the needed FML source code.

The data transformation from CDA to FHIR necessitates a profound comprehension of the data structures inherent in both standards. FHIR StructureDefinition (54) describes a resource structure and defines a set of data element definitions and associated usage rules. These structure definitions describe the content defined in the FHIR specification, such as resources, data types, and underlying infrastructural types, and how these structures are utilized in implementations.

In CDA, each element is comprehensively defined using standard schema definition (XSD) files. These XSD files act as architectural designs, delineating the structure and data types of CDA documents and simplifying the process of validating these documents against the prescribed schema. The CDA model is based on the HL7 Reference Information Model (RIM) and utilizes reusable data types, templates, sections, and components (50). For instance, patient demographics, medication information, and clinical observations are standardized and reused across different CDA documents. HL7 has implemented a representation of the CDA R2.0 specification using FHIR Logical Models expressed as FHIR StructureDefinition instances available under an open-source license (60).

Many models in CDA and FHIR have numerous attributes, are complex, and contain hierarchies. We need a way to reuse data type transformations and provide reusable transformation components for CDA and FHIR subtypes, such as CD to Coding and II to Identifier. This approach will enhance the efficiency and reliability of data-handling processes. For instance, the ENHIS “Outpatient Case Summary” comprises 24 sections, while the “Birth Summary” comprises 17 sections (61). Of the “Birth Summary” sections, only four are absent in the “Outpatient Case Summary”. Our techniques involve creating transformation components for a single document type and then applying these components to different types of documents. If new sections are introduced in the new document type, transformation components are only developed for these new sections and included in the reusable transformation components library. With each new document type, the number of sections requiring transformation components development will decrease and eventually reach zero. We also need a solution to validate transformation components to identify problems during development rather than production and to avoid errors during the development of transformation components.

Transformations of simple data objects are straightforward, and the associated source code in FHIR Mapping Language is relatively uncomplicated. However, with the transformation of hierarchical complex objects, the source code becomes highly intricate and may pose comprehension challenges for domain experts. Complex transformations necessitate visualization (62). We aim to establish a set of CDA and FHIR transformation components encompassing a broad spectrum, ranging from primitive data types to complex resources, and formulate appropriate techniques. We hypothesize the following: (1)

TermX as an artifact will apply to all CDA data types, sections, and documents.

This strategy would facilitate the reuse of prior transformation components, thereby augmenting the efficiency and uniformity of transformation procedures. Such an approach is designed to fortify the robustness and adaptability of the developed TermX tool, equipping it with the capacity to help domain experts develop and validate transformation components by hiding the details and complexities embedded within CDA and FHIR data models.

Based on the problem investigation above, we have established the following requirements for the visual reusable transformation components set: (1)

It must support strict data models

This approach underscores our commitment to advancing the field of data transformation and management, ensuring that our data transformation techniques are accessible and understandable to a broad range of stakeholders.

The selected approach evaluates the usability of the TermX model designer and the TermX visual FML editor, the FML language, and the HAPI FHIR implementation of FML used by TermX (Figure 2 illustrates the TermX architecture and components). TermX enables the registration of HL7 V3 and CDA models in the TermX model designer, uses FHIR resource definitions, creates data transformation rules from CDA to FHIR in the TermX visual FML editor, and publishes the transformations on GitHub.

The transformation may be triggered by HTTP requests within scripts or through the web user interface. TermX is available as a set of Docker containers used for deployment. We use the logical models provided with the HL7 CDA R2.0 core standard (60) as a basis for ENHIS CDA input instances. These models were extended according to the ENHIS CDA standard implementation. We used FHIR Release 5 (R5) structure definitions (54) as the standard for output instances. The transformations handle one input CDA file and output one FHIR file.

Treatment validation ensures that the chosen approach contributes to achieving stakeholders’ goals when implemented. Our approach includes prototyping a set of transformation components using ENHIS version 8.2 CDA documents, the FHIR R5 specification, and the TermX tool. The FML Editor achieved Technology Readiness Level (TRL) 5 according to the European Commission’s classification (63) at the start of the validation process. The dataset, derived from three ENHIS HL7 CDA document types: the “Outpatient Case Summary”, the “Notice of Growth”, and the “Birth Summary”, was established during the research to validate the proposed transformation techniques. For each selected document type, we used a sample CDA document from the ENHIS specification that includes all available sections.

The ENHIS “Outpatient Case Summary” includes 24 data sections, the “Notice of Growth” includes seven sections with two unique sections, and the “Birth Summary” includes 17 sections with four unique sections. Initially, we developed transformation components for all sections in the “Notice of Growth” and their associated classes and data types. Additionally, we created a transformation component to convert the “Notice of Growth” document into FHIR, incorporating all the transformations in the created section. For each subsequent document, we created a new transformation component that included the transformation components of the existing sections. Then, we added new section transformation components and linked them to the particular document transformation component. With the implemented prototype, we successfully verified that: (1) TermX was applicable for all necessary CDA data types, sections, and documents; (2) all transformation components were developed using the TermX visual user interface; and (3) the developed transformation components were reused in subsequent data types, sections, and documents.

The results obtained were first validated manually by comparing CDA and FHIR messages section by section to ensure the correctness of transformations. Next, we designed a technique (Section 2.3.4) to automate the validation process. Subsequently, the results were demonstrated to the IT department of the Health and Welfare Information Systems Centre (TEHIK), which operates the ENHIS. The feedback was overwhelmingly positive, with the team expressing their approval and satisfaction. Following the internal evaluation, TEHIK chose it as their transformation tool.

Transformation validation should be deterministic, with each transformation having a dedicated test suite using predefined human-validated inputs and expected outputs. While developing these deterministic input-output pairs is time-consuming and can lengthen the development cycle, it is essential for robust production solutions and sometimes required by legislation (64, 65). We envision quicker heuristic feedback techniques for prototyping or experimentation, combining FHIR structure validation and an input-output content similarity assessment using a natural language processing (NLP) solution. However, supporting dedicated test suites in TermX and developing these heuristic validation techniques will largely be a part of future work.

Data similarity between the original HL7 CDA and the transformed HL7 FHIR documents was validated. No specialized out-of-the-box tool capable of statistically evaluating the correctness of the transformations was found. Therefore, CDA and FHIR documents were converted into collections of key-value pairs to which statistical tools were applied (66). The highest similarity percentage was achieved using the Term Frequency-Inverse Document Frequency (TF-IDF) methods (67). Further research in this direction is planned for the future.

For the ENHIS CDA StructureDefinitions, we were able to use the logical models provided with the HL7 CDA R2.0 core standard (60) as a basis, which were then modified as needed according to the ENHIS CDA standard implementation. This implementation is available as Enterprise Architect models and PDF documents on the web and is accessible within the Estonian IP address space. The modifications required for the core standard StructureDefinitions were necessary to address the extensions of the base model defined in the Estonian implementation as well as instances of misuse of the standard. For example, in the CDA Observation class, the Ratio data type for the value attribute is denoted as RTO-PQ-PQ in the core standard, which employs hyphens. However, in the ENHIS implementation, it is referred to as RTO_PQ_PQ, where underscores are used instead. An example of an extension that needed to be accounted for is the <asLicencedEntity> element added to the <assignedEntity> element to provide information about the authority licensing the healthcare worker. As the transformation target structure, we used the base FHIR R5 release, for which we utilized URIs in a test server.

An example of using ConceptMaps and terminology translation between CDA and FHIR is illustrated when transforming the CDA Patient class into the FHIR Patient resource. The two standards use different sets of codes to represent the administrative gender of the patient. For instance, in the ENHIS CDA implementation, the code “N” represents the female gender, whereas in FHIR R5, the code “female” is expected. A ConceptMap was constructed and used with the transformation rule to perform translation between the two terminology code systems, as shown in Figure 7. In the figure, the administrativeGenderCode attribute of the Patient CDA class is piped into the transformation rule, the result of which is assigned to a new FHIR code data type and then to the gender attribute of the Patient FHIR resource.

One of the most common transformations we encountered was between the FHIR concept and different representations of the CDA concepts. For example, FML transformation rules between the CDA CD class and the FHIR CodeableConcept resource as well as between the CDA CE class and the FHIR CodeableConcept resource provided significant value in terms of reuse. These transformation rules were very common in higher granularity level transformations. Due to the nested structure of the FHIR CodeableConcept and the three data attributes mapped between the structures, calling a reusable transformation rule with one line of code saved us from repeating the same six lines of code each time. An example of a reusable CDA CE to FHIR CodeableConcept transformation rule using the TermX visual editor can be seen in part A of Figure 8. The attributes of the CE CDA class are assigned to a new Coding FHIR resource. The Coding resource is then assigned to the target CodeableConcept coding attribute. Specifically, the CE CDA class’s code attribute corresponds to the FHIR Coding’s code attribute, the codeSystem attribute corresponds to the system attribute, and the displayName attribute corresponds to the display attribute.

Notably, FML also enabled us to handle semantically faulty XML at the data type level. In an Observation element in the “Outpatient Summary” test documents we used, we encountered a decimal value represented as text with a comma decimal separator inside an EncapsulatedData data type: <value xsi:type=“ED”>12,2</value>. To fix this issue, we were able to replace the decimal separator and cast the text into a decimal data type using FML’s evaluate rule with a FHIRPath expression and a cast rule. We accomplished all of this using only the visual editor (see Figure 8 part B). The inner text of the XML tag represented by the xmlText attribute is piped into an evaluate block, where a FHIRPath expression is used to replace the comma with a period in the text string. The evaluated string is piped into a cast block, which casts it to a decimal data type and assigns it to an output value. In our opinion, this result illustrates that a visual editor can produce fault-tolerant and robust transformation rules.

CDA class to FHIR resource transformation rules can be exemplified with Figure 9, which shows how a CDA AssignedAuthor class is mapped to a FHIR Practitioner resource using the TermX visual editor. The CDA AssignedAuthor class is split into the II data type from the id attribute, the CE data type from the code attribute, and the Person class from the assignedPerson attribute. Subsequently, the CDA II data type is transformed into the FHIR Identifier resource using the reusable transformation component CdaIiToFhirIdentifier. The CDA CE data type is transformed into the FHIR CodeableConcept resource using the reusable transformation component CdaCeToFhirCodeableConcept. The CDA PN data type is extracted from Person class and transformed into the FHIR HumanName data type using the reusable transformation component CdaPnToFhirHumanName. The transformed FHIR resources are then assigned to the target Practitioner resource’s identifier, qualification, and name attributes, accordingly. Notice how data type transformation rules are imported and then used. Referring to Figure 8, which shows the implementation of the CdaCeToFhirCodeableConcept transformation, it is clear how our approach encapsulates complexity and promotes clarity at the CDA class to FHIR resource mapping level.

Transforming the CDA document header to FHIR is an example of the transformation component from a CDA section to a FHIR resource. This is shown in Figure 10. The clinical document header contains a variety of information. The confidentiality codes, as top-level attributes of the header, are transformed into FHIR’s Meta resource and assigned to the FHIR Bundle’s meta attribute. The structural information about the sections in the document is compiled to form the FHIR Composition resource and added to the FHIR Bundle as an entry. The clinical document header’s custodian attribute, a CDA Custodian class instance, is transformed into a FHIR Organization resource and added to the bundle as an entry. The author attribute of the clinical document, a CDA Author class instance, contains information about the author’s person and organization. Therefore, two transformation components are used: one for transforming the data into a FHIR Organization resource and another for transforming the data into a FHIR Practitioner resource. Both resources are added to the FHIR Bundle as entries. Finally, the recordTarget attribute of the clinical document header, a RecordTarget CDA class instance, is transformed into a FHIR Patient resource and added to the FHIR Bundle as an entry. This concludes the scope of our ClinicalDocument header transformation component. The number of transformation components is approximately equal to the number of document types and CDA classes used in them, considering the CDA class hierarchy. By encapsulating transformation components such as CdaCustodianToFhirOrganization, CdaAuthorToFhirOrganization, CdaAuthorToFhirPractitioner, and others into reusable transformation components, the CDA header transformation rule remains comprehensible, even though the amount of information to be transformed is much larger.

Finally, using CDA section transformation components, we compose a transformation component for the “Notice of Growth” CDA document (see Figure 11). We find a document section by section code, then apply a reusable component to transform this section into FHIR resources, and then combine them into a FHIR Bundle. The header section is extracted from the root level of the ClinicalDocument, while the other sections are extracted from within the <StructuredBody> element. From the <structuredBody> element, we extract two sections: the AGE section and the GROWTH section. The AGE section is transformed into an Observation FHIR resource containing the patient’s age information using a single CdaAgeSectionToObservation reusable transformation component. The transformed Observation resource is added to the FHIR Bundle as an entry. The GROWTH section is transformed into multiple observations, as this section contains CDA Observation classes in <component> elements for different measurements taken during the procedure: weight, height, head circumference, fontanel measurements, and body mass index. The following reusable transformation components are used: •

CdaGrowthSectionToFhirWeightObservation

The resulting Observation FHIR resources are added to the FHIR Bundle as entries. Referring to Figure 10 for the complexity of just the CDA document header component, we see how this approach encapsulates the complexity of a single document section and enhances clarity and high-level understanding of the clinical document’s mapping to FHIR. From the data type level up to the CDA template level, the amount of code duplication is significantly reduced, as is the number of points of failure. At the same time, the clarity and comprehension of the transformations are greatly improved.

With the development of the “Notice of Growth” CDA to FHIR transformation, the following transformation components were created: •

CdaClinicalDocumentHeaderToFhirBundle

Numerous transformation components have been created to convert CDA classes to FHIR resources and support the composition of section-level transformations. The essential components include the following: •

CdaAssignedAuthorToFhirPractitioner

The necessary data type transformation components include the following: •

CdaAdToFhirExtendedContactDetail

The ConceptMap CdaAdministrativeGenderCodeToFhirGender was also created. All these transformation components were designed to be reusable for the future development of transformation components from other CDA templates to FHIR bundles.

The concept of “Mapping Language” (or Data Transformation Language) lies in establishing a platform-independent specification that can be implemented across various programming languages (70). Model-to-model transformations are typically articulated in specialized domain-specific languages, often known as model transformation languages (MTLs) (71). MTLs encapsulate algorithms that delineate the process of converting elements from one model (or multiple models) into elements of another model (or multiple models). Declarative MTLs (DTLs) only provide logic constructs to express relations between elements in these candidate models, and the execution engine is responsible for synthesizing an execution plan that uses these relations to perform the model transformation.

Query/view/transformation: “Query/View/Transformation” (QVT) is a specification developed by the Object Management Group (OMG) to describe transformation rules between different data models in the Model-Driven Architecture (MDA) domain (72). The language was intended to support the declarative specification of model transformations, avoid imperative constructs, and support change propagation from one model to another as well as the bi- (or multi-) directional interpretation of transformations. However, its semantics have many unclear or unsatisfactory aspects that are not precisely defined in the standard (73). The QVT Core language (QVTc) uses pattern matching as the primary logic construct. Pattern matching is done over a flat set of variables by evaluating conditions over those variables against the candidate models (74).

eXtensible stylesheet language transformations: XSLT is a language used to transform XML documents into other document formats or other versions of XML.² XSLT is a powerful tool and a widely adopted language for transforming XML documents, including healthcare-related XML standards such as CDA. However, it is unsuitable for directly programming transformations of semantically complex models due to its low-level syntax (75). XSLT is also not a specialized language for medical data (76). One of its disadvantages is the mandatory use of XML language, which imposes limitations on use. It is also poorly readable, making it difficult to learn and debug (77).

Whistle: The Whistle Data Transformation Language provides a means to express mappings between schemes, enabling users to convert complex, nested data models into other equally complex and nested data formats (78). Whistle does not require a description of logical models for the data to be converted. The conversion requires only source data in JSON format and a map that describes the conversion rules. The result of the transformation is output data in JSON format.

Liquid templates: Liquid (79) is a templating language developed by Shopify that uses a combination of objects, tags, and filters inside template files to convert any JSON or XML format into another JSON format. A transformation engine is required to convert input data into output data based on a .liquid template. Microsoft FHIR Converter (80) is one such engine, processing Liquid templates to convert input data into validated FHIR format. It includes extended methods for FHIR data and is part of Microsoft’s FHIR server implementation, available in the Microsoft Azure Health Data Services product (81). Users can upload custom templates to the Azure registry, which Azure Health Data Services can then use via an API endpoint for data transformation.

FHIR Mapping Language: The FHIR Mapping Language (FML) (40) is a relatively new QVT-based transformation language specifically designed to transform HL7 FHIR resources to/from alternative representations, including different logical data models, FHIR resources, C-CDA documents (42), etc. (82). FML is a part of the FHIR specification. Conceptually, FML is similar to XSLT: (1)

It consists of declarative rules that are automatically matched to input data

The source input of FML supports any object models and rendering syntaxes that conform with OMG’s Meta Object Facility (MOF)³ language. MOF is a general formalism for representing object models as directed acyclic graphs (DAGs). MOF-compliant models can use various syntactic constructs to represent the classes, attributes, and attribute values of such graphs. The applications of this language encompass several scenarios: •

Mapping FHIR resources across different versions of FHIR

The technical specification of FML (40) has been published as an integral component of the FHIR specification (83). FML serves as a tool for transforming structured models from one form to another. Within the HL7 FHIR context, FML is utilized to map FHIR resources across different versions of FHIR. FML transformation requires the following (Figure 12): •

One input model (marked on the picture with the number “1”)

NextGen connect: NextGen Connect (previously known as Mirth Connect) (84) is a robust, open-source healthcare integration engine widely used for its versatility and cost-effectiveness (85). One of its major strengths is its ability to support numerous data formats and protocols, such as HL7, XML, and JSON, making it highly adaptable to various healthcare systems (86). Its user-friendly interface and comprehensive documentation facilitate easier configuration and deployment, and the active community provides valuable support and resources. However, Mirth Connect has several drawbacks. Despite its user-friendly interface, it is primarily geared towards technical experts, making it challenging for domain experts without technical backgrounds to use it effectively (87). In our opinion, the learning curve is steep for new users unfamiliar with healthcare data standards and integration concepts. Performance can also be an issue with large-scale implementations, requiring careful optimization and resource management. Additionally, the clarity of implemented transformations can sometimes be lacking, making it difficult to understand and troubleshoot complex data flows (88). Furthermore, while the open-source version is feature-rich, some advanced features and enterprise-level support are only available in the paid version, which might limit its appeal to smaller organizations.

Other health data integration tools: Health data integration tools are essential for managing and transforming healthcare data, supporting interoperability within healthcare systems, and automating processes to realize cost savings. In addition to NextGen Connect, other well-known tools in this domain include Cloverleaf Integration Suite (89), Interfaceware Iguana (90), Corepoint Integration Engine (91), and Redox (92). Each tool offers numerous benefits, including connectivity and interface management, data transformation and workflow management, and support for various healthcare standards, protocols, and interfaces. They provide data mapping and support multiple data formats, leading to cost savings through reduced manual effort. However, there are challenges to consider when implementing these tools (93): •

Complex implementation: The process can be intricate, requiring IT professionals with expertise in healthcare data standards, protocols, and the specific tool’s configuration.

FML implementations: The FHIR Mapping Language specification is implemented by code libraries such as the HAPI FHIR StructureMap implementation in Java (57) and its direct port to .Net (94), both of which offer transformation engines and open-source libraries. HAPI FHIR, a comprehensive Java library for FHIR, supports creating, parsing, and validating FHIR resources, providing robust tools for healthcare applications. The .Net FML implementation leverages these capabilities, bringing the same powerful functionality to the .Net ecosystem. Both libraries facilitate the transformation of healthcare data, ensuring interoperability and compliance with FHIR standards, which are crucial for modern healthcare systems.

Matchbox: Matchbox is an open-source initiative to support the testing and implementation of FHIR-based solutions (95). Matchbox utilizes the HAPI FHIR implementation, inheriting all its advantages while introducing additional flexibility for FML processing. Matchbox allows the preloading of FHIR implementation guides for conformance resources (StructureMap, Questionnaire, CodeSystem, ValueSet, ConceptMap, NamingSystem, StructureDefinition) and validates FHIR resources. Matchbox allows the defining of mapping in an FML text representation and its transformation into FHIR StructureMap resources. Matchbox applies the mapping to data to create FHIR-compatible data sets. Matchbox validates and executes FML transformations through the FHIR API, checking that the mapping conforms with the included validation stack.

Austrian ELGA: The ELGA (Elektronische Gesundheitsakte) project launched in Austria is a nationwide EHR system designed to facilitate the exchange of medical documents across healthcare providers. ELGA uses CDA to manage medical data in a document-centric format. The project supports various document types, including Physician’s Discharge Summaries, Nursing Discharge Summaries, Laboratory Reports, and Diagnostic Imaging Reports, with the addition of e-Medication reports covering prescription and medication summaries. To enhance interoperability and accessibility, recent efforts focus on mapping ELGA CDA documents to the FHIR standard using JSON mapping (96). Every element and section in JSON mapping has a “cda-path” that prescribes a rule for extracting data from a CDA document. This approach aims to generate International Patient Summaries (IPS) in FHIR format, enabling more granular access to health data and supporting cross-border healthcare data exchange within the European Union (26).

Italian patient summary: The Italian decree mandates that regional EHR systems support two types of documents: the Patient Summary and the Laboratory Report (27). The Patient Summary focuses on collecting the patient’s most significant clinical information and uses the CDA format. During the eHealthNet project, a prototype was implemented for transforming the Patient Summary from CDA to FHIR. The proposed solution included the Mapping, Extractor, and Binding components. The Mapping component contains schemas defining correspondence between an element in FHIR and another in CDA. XPath was used for data extraction from CDA and binding to FHIR with a series of functions written in XSLT (27).

Swiss medications: The Swiss healthcare system has adopted the CDA standard, incorporating specific requirements unique to Switzerland (97). This has led to the creation of the CDA-CH standards (98). Switzerland transitioned to FHIR and developed equivalent FHIR-CH specifications for medication. To verify the equivalences, mappings have been defined with the FHIR mapping language, and Matchbox has been used for transformation from CDA to FHIR and back (99). To aid this transformation process, a consolidated library of CDA templates was employed (60). The use of FML in this context facilitates the automated transformation and validation of data, ensuring compliance with FHIR profiles and enhancing the utility of Swiss health data across various healthcare scenarios.

Estonian Andmevaatur: The Andmevaatur (Data Viewer) is a tool summarizing and visualizing patient data in the ENHIS (28). The ENHIS is built upon HL7 V3 and CDA standards (100). Due to the ever-increasing volume of documents, the task of gathering observations, procedures, vaccinations, and other clinical information from documents has become increasingly time-consuming for doctors (101). Andmevaatur uses xQuery to request CDA documents from the ENHIS database, transforms them into FHIR resources using a custom-developed mapping language, and forwards the resources to the user interface application for presentation. The custom-developed mapping language includes pairs of XPath and FHIRPath and a Java adapter for their execution. XPath is used for data extraction from CDA and FHIRPath is used for inserting data into the appropriate place in the FHIR resource. The development of an independent mapping language has been discontinued, and migration to FML is planned. Using Andmevaatur, doctors can save at least three minutes per visit, which is approximately 15 percent of the time typically spent interacting with a patient (101).

Ensuring federated interoperability (23, 24) is essential in the EHDS as it reduces administrative, operational, and international coordination costs. Federated systems store data in appropriate locations and formats, avoiding the complexity of large central repositories (102). This respects data sovereignty and privacy rules while allowing interoperability and independent innovation (103).

Centralized systems require significant infrastructure investment and management, which can be inefficient. Federated systems distribute these responsibilities, leveraging existing infrastructure and expertise and reducing compliance burdens with diverse regulatory frameworks. Federated semantic interoperability facilitates real-time data sharing, which is crucial for informed healthcare decision-making. By enabling seamless health data exchange, federated systems support innovative healthcare solutions, such as integrated care platforms and personalized medicine networks, enhancing care quality and patient outcomes.

Federated interoperability also supports EHDS initiative evaluations by providing a robust data integration and analysis framework, essential for assessing health interventions and informing policy decisions. Leveraging diverse data sources without extensive migration accelerates innovation and evaluation in healthcare. However, an effective system for semantic data transformation is required, as subsystems use different standards and models. The EHDS will inevitably need semantic data transformation, necessitating the evolution of user-friendly tools such as TermX.

Achieving semantic interoperability is challenging due to the complexity of data transformation processes, which traditionally require significant technical expertise. The proposed techniques and TermX tool enable domain experts with minimal technical skills to participate effectively. The visual editor allows them to create and manage data transformation rules through an intuitive interface, democratizing the process and reducing reliance on technical specialists. This expedites development and deployment, improving the efficiency and scalability of interoperability initiatives.

The TermX tool explained in this paper allows domain experts to develop and validate data transformation rules, accommodating the evolving landscape of health standards and technologies (104). Direct involvement of domain experts ensures accuracy and relevance, as they bring a deep understanding of specific data and context. This collaboration fosters a more comprehensive approach to data transformation, enhancing the quality and reliability of interoperable data. The tool’s validation features enable domain experts to test and refine transformation components, ensuring that transformed data meets expected standards and requirements and contributes to effective and trustworthy interoperability solutions.

Achieving federated semantic health data interoperability is crucial for supporting innovation within the EHDS (17). The healthcare data landscape constantly evolves, driven by innovations and new requirements. Semantic interoperability requires continuous adaptation. The proposed techniques and TermX tool support a flexible, modular approach to data transformation, adapting to new standards and technologies as they emerge. This ensures long-term interoperability and prevents obsolescence.

For instance, the transition from CDA to FHIR represents a significant shift in data structuring and exchange. As new versions of these standards are released, the tool must incorporate these changes, facilitating seamless data transformation. This capability allows healthcare organizations to leverage the latest advancements without significant disruptions or reengineering.

The evolving standards highlight the need for a collaborative approach to interoperability. The tool leverages collective expertise to stay updated with the latest developments by fostering a community-driven repository of transformation components and best practices. This promotes continuous improvement and innovation in health data interoperability.

The FAIR (Findable, Accessible, Interoperable, Reusable) data principles are key enablers of secondary data use for societal benefit (105). Opening FAIR access to routine clinical data can drive advancements in medical research, clinical trials, public health, and policy-making (2–4, 106). Achieving FAIR access while maintaining privacy and security is challenging and requires robust technical solutions (18). Federated semantic interoperability offers a solution by keeping data in its original location, ensuring privacy, and enabling the integration and analysis of anonymized or pseudonymized data.

The proposed techniques and TermX tool support FAIR principles by providing a framework for transforming and integrating clinical data in a standardized manner. This ensures that data is findable and accessible, consistently represented, and understood. By facilitating data reuse through interoperable transformation rules, the tool enhances the utility of clinical data for secondary purposes. Leveraging routine clinical data for secondary use has profound societal implications, providing researchers with data for studies, enabling public health officials to monitor and respond to health threats, and guiding policymakers with evidence-based insight (107).

Health data is interconnected with data from sectors such as education, social services, the environment, and the economy (108, 109). Integrating health data with these sectors is essential for a holistic understanding of health determinants and outcomes, as the World Health Organization (WHO) recommends (110).

Although TermX was designed with FHIR support for health data interoperability, it is versatile enough to integrate and facilitate interoperability with other data sets beyond healthcare. This adaptability allows TermX to connect health data with various sectors, such as education, social services, the environment, and the economy. TermX supports a more comprehensive analysis of factors influencing health outcomes by enabling seamless data exchange across these domains. This flexibility ensures that TermX can serve as a powerful tool for creating holistic data ecosystems where health data is enriched by insights from other sectors, ultimately contributing to more informed decision-making and improved public health strategies.

Klementi et al. (18) identified three health data dilemmas: accessibility, comprehensiveness, and ownership. The accessibility dilemma involves balancing health data access for improved outcomes with protecting sensitive information. Ensuring FAIR (Findable, Accessible, Interoperable, and Reusable) access often conflicts with data protection requirements (111–113). The comprehensiveness dilemma concerns creating a complete health record from fragmented data stored across various systems. Issues such as semantic interoperability and legal barriers impede the consolidation of data into a comprehensive personal health record (PHR) (114). The ownership dilemma addresses the conflict between individuals’ rights to control their health data and the practical difficulties of exercising these rights (115, 116).

An EHDS architecture where individuals own and control their health data could use decentralized content-addressable storage networks (18). The proposed techniques and TermX tool create conditions that enable individuals to share their health data with healthcare professionals and ensure FAIR access to routine clinical data for secondary use (117, 118). This empowers more stakeholders to participate in the data transformation process, keeping health data interoperability at the forefront of healthcare innovation.

The technical implementation of the solution encompasses both the design and transformation phases. This paper focuses on the design phase, wherein data models and transformations are developed. The resulting artifacts can be stored either in GitHub or on a FHIR server. The TermX Editor is utilized for the design and testing of these transformations, but it is not required for their execution. For execution purposes, libraries such as HAPI FHIR, .Net, or their equivalents can be employed to compile and run the transformations. To enhance throughput, the application should support the caching of the utilized models (StructureDefinition instances) and compiled transformations (StructureMap instances). This application can function as a standalone service or as a module integrated into the FHIR server.

When integrating two systems, two data models (source and target) and one set of transformations are required for one-way transformations or two sets for bidirectional transformations. If we consider that each medical system in the EHDS integrates with every other system and each has a unique data model, there will be N data models, resulting in an integration network with a complexity of O(2ⁿ) (Figure 13A). By creating a central model, we would have N+1 models and N (for one-way) or N*2 (for bidirectional) sets of transformations (Figure 13B). However, a single central model for all European countries is not realistic (9). It would be beneficial to reduce the number of models by creating smaller Data Spaces, where institutions within a country or region share a single model. Instead of a single central model, domain-specific Data Spaces could be established, connecting all EU laboratories (119), immunization records (120, 121), or radiology services into unified networks (Figure 13C). Such grouping would reduce the number of transformations and administrative burdens.

The current study was conducted and validated for a specific use case, namely the transformation of ENHIS documents. When comparing documents from Estonia with those from other countries, we find that documents of the same type, such as outpatient summaries, differ in the number of sections, section labeling, and terminology used. Additionally, country-specific extensions may be used. This implies that for each specific implementation, the representation at the business domain knowledge level may differ, and the set of transformations developed in this research study may require adaptation.

The foundational resources from the CDA and FHIR frameworks are highly compatible and could be suitable for use in any country. The ISO 23903 Interoperability and Integration Reference Architecture addresses the challenges associated with integrating such models and frameworks. Examples include mappings of HL7 V2 and HL7 V3 models and specifications, and the re-engineering and mapping of the higher-level specifications ISO 12967 Health Informatics Service Architecture and ISO 13940:2015 System of concepts to support continuity of care (122).

Although the detailing of base types in mapping may vary depending on the use case, for ENHIS, mapping of the CDA II to FHIR Identifier data types requires only the transformation of key attributes “root” to “system” and “extension” to “value” (Figure 4). However, in another information system, additional attributes such as “display” and “use” might be required, which we have not mapped, as this mapping is specific to the given use case. Nevertheless, it is easily generalizable if we extend the use case.

Actors from different scientific domains and disciplines, different communities, and different policy domains represent and understand related concepts differently (123). This decision on correct mapping is only possible at the business domain knowledge level, represented through domain ontologies and related terminologies. •

Validation by analyst. Business analysts, as domain experts, possess comprehensive knowledge of the domain’s ontology and terminology. They are responsible for planning and ensuring the accuracy of transformations. TermX is a robust tool specifically designed for analysts. Consequently, business analysts are well-equipped to make transformation decisions and verify the accuracy of transformations by manually performing a reasonable number of tests.

Technical validation of transformations will make up future work.