The AI Act is a landmark: the world’s first comprehensive and legally binding regulation of AI. The AI Act has already established concrete legal requirements and prohibitions for AI systems based on their potential risk, ensuring that regulatory strictness is proportional to potential harm. The 4 risk levels along with their limits are provided in Table 1.

To help organizations determine how the AI Act applies to their AI system, the Future of Life Institute has developed an EU AI Act Compliance Checker [14]. It is an interactive tool that guides stakeholders through a series of yes/no questions to identify the relevant obligations under the AI Act. Furthermore, the interactive checker also tailors output based on the user’s role (provider, deployer, distributor, etc), ensuring that each stakeholder knows their responsibilities. The compliance checker has been used to produce a decision flowchart (Figure 1), providing a decision tree for determining the level of risk under the AI Act, given the application domain.

Annex IV is the technical documentation regarding the AI Act, and it essentially serves as the evidence dossier for compliance, prescribing the Act’s minimum contents in detail. In general, the documentation must describe:

In addition, the technical file should append a copy of the EU Declaration of Conformity (Annex V) for the AI system. This is the formal statement in which the provider declares that the system conforms to the Act (and is typically signed by an authorized person). This technical documentation is a living set of documents that must be kept up to date (at least 10 years after deployment) and made available to authorities upon request. It forces providers to deeply give consideration to and record every aspect of how the conformant AI was built and how it operates safely.

MyHealth@EU is the EU’s operational infrastructure for cross-border digital health data exchange. Developed under the Connecting Europe Facility’s eHealth Digital Service Infrastructure, it currently supports protocols for the routine transfer of ePrescriptions, International Patient Summaries (IPS), and original clinical documents among member states. Regulation (EU) 2025/327 formalizes common specifications for this network and outlines expansion to additional datasets, thus providing legal certainty for member states and vendors [15]. Up to date, there are 6 main dataset services, planned to act as live clinical payloads flowing through the MyHealth@EU network, that handle real patient data in production. Parts of them are fully operational (ePrescription/eDispensation, IPS, and original clinical documents); one is in a pilot stage (laboratory results), and the others are planned (medical imaging and hospital discharge report).

OpenNCP [16] is an open-source implementation of the software components that are needed to successfully run NCPeH under the semantic and technical frameworks published as under eHealth Digital Service Infrastructure. OpenNCP was originally developed under the European Patients Smart Open Services project, with 25 participating countries and over 50 beneficiaries, running from 2008 to 2014, and since 2014, it has been hosted by the European Commission.

The cross-border eHealth exchange is governed through a model that cleanly separates policy-making, technical coordination, and national implementation. Health ministry representatives (the eHealth Network), together with the European Commission’s Directorate General for Health and Food Safety, comprise the policy-making that sets the strategic agenda. They issue EU-level decisions that add new clinical domains. The same bodies ratify the semantic assets that make data interoperable, as well as approve the common cybersecurity baseline, and define how member states must report incidents.

Operated by the European Commission, the Central Services Platform (CSP) acts as the technical service hub. Through its Service Metadata Publisher (SMP), the CSP distributes an up-to-date directory of NCPeH end points and their supported transactions. A semantic repository stores and versions all CDA guides, code lists, and FHIR profiles. The CSP also runs the conformance test service, which verifies transport security, semantic validity, and workflow scenarios. The aggregated incident report confirms that each new or upgraded NCPeH meets EU requirements.

Each member state must operate at least one NCPeH instance with OpenNCP installed as the reference software, implementing the secure message exchange, template validation, consent enforcement, and auditing for every one of the MyHealth@EU dataset services. The dataset service defines what data move and how they are structured. It is the formal, standard-based data exchange capability (eg, IPS) delivered by MyHealth@EU, intended to ensure that clinicians see accurate, structured, and trusted information across borders. The core components of the OpenNCP include a Gateway service that handles AS4 messaging and mutual Transport Layer Security handshakes, a pivot transformer that maps national data models to European Union CDA templates, a security module that validates eIDAS tokens and eXtensible Access Control Markup Language (XACML) consent assertions, and an audit repository conforming to Integrating the Healthcare Enterprise (IHE) Audit Trail and Node Authentication (ATNA) profile. The project publishes binary distributions and Docker images on a regular release cycle; each aligned with the semantic-asset versions distributed by the CSP. Member states may extend OpenNCP via plug-ins provided all extensions pass the CSP Conformance Test Service. Together, these layers enable any clinician in one member state to request and receive a patient’s records from another under a single, shared rule set.

Figure 2 shows an example where a clinician from member state A is requesting an IPS from member state B. It illustrates the sequence of steps, where the actors involved are marked with a corresponding color. The following process is used. Step 1 (service discovery) involves OpenNCP-A initiating a query to the SMP hosted by the CSP. Through this request, it retrieves essential interoperability metadata such as the end point address of NCPeH-B, the list of supported data set services, and relevant security certificates. Once the end point is confirmed, step 2 (patient discovery) follows. Here, OpenNCP-A’s Cross-Community Patient Discovery Client sends a patient discovery request, including demographic information, to OpenNCP-B, which uses its national master index or electronic health record (EHR) system to locate the matching individual. On successful identification, step 3 (document retrieval) begins as OpenNCP-A’s XCA client sends a formal request for the IPS to OpenNCP-B’s XCA server, which responds with the patient’s structured CDA document. Then in Step 4 (CDA generation), NCPeH-B leverages its pivot transformer to convert local EHR data into the standardized IPS CDA format. This is then semantically validated using controlled terminologies, such as Systematized Nomenclature of Medicine, Logical Observation Identifiers Names and Codes, and Unified Code for Units of Measure, and checked against Schematron rules. Then in step 5 (security and consent check), the Security Module in OpenNCP-B validates the sender’s eIDAS identity token, applies XACML-based consent policies, and securely signs and encrypts the response. With the data packaged and ready, step 6 (audit logging) is executed by both NCPeHs. Each system records detailed logs, including transaction identifiers, patient IDs, document type, and timestamps, storing these in IHE ATNA-compliant audit repositories for a minimum of 10 years.

Member states are expected to incorporate AI technologies into their national health care systems, necessitating adherence to the EU AI Act without imposing modifications at the MyHealth@EU infrastructural level. Figure 3 positions an AI-based system within a hypothetical national health care system in member state A. All AI-related regulatory requirements must be addressed before interfacing the national EHR system with the OpenNCP. Specifically, high-risk AI systems under the AI Act must comply with requirements for risk management, data governance, technical documentation, audit logging, transparency and explainability, human oversight, robustness, postmarket monitoring, quality management systems, conformity assessment, and registration in an EU database.

Analysis of these requirements indicates that some can benefit from existing MyHealth@EU policies, whereas others necessitate external solutions provided by developers responsible for their reliability. Central to these requirements is the technical documentation mandated by Annex IV of the AI Act, serving as a comprehensive reference repository accessible via URL. This documentation, stored securely alongside external services, provides essential details about the AI system.

Risk management, lacking direct equivalents within MyHealth@EU, must be addressed externally by clearly outlining the risk analysis life cycle, mitigation strategies, hazard modeling, residual risk management, and continuous risk monitoring procedures. Data governance, critical for AI-driven processes, also requires external oversight to manage dataset origin, representativeness, preprocessing techniques, and bias mitigation strategies, guided by compliance rules derived from European Electronic Health Record Exchange Format standards pertinent to medical data.

Audit logs, essential for system traceability, must adhere to the IHE ATNA profile, ensuring transparent documentation of system operations. Transparency and explainability pose significant challenges within AI applications and necessitate external mechanisms thoroughly detailed in the technical documentation. Human oversight mechanisms must clearly define clinical responsibilities, supervisory roles, decision reviews, and emergency override protocols, incorporating clinical corrections into documentation.

Robustness, accuracy, and cybersecurity documentation should provide comprehensive evidence of system reliability and safety. This includes detailed performance metrics, stress testing results under edge-case clinical conditions, error handling procedures, adversarial resistance evaluations, and security-by-design mechanisms. For generative AI and multiagent systems, developers should consult security guidelines, such as those outlined by the Open Worldwide Application Security Project (OWASP) GenAI Security Project [17], which highlight critical risks such as prompt injection, model extraction, and misuse, offering mitigation strategies tailored to large language model–based architectures.

Postmarket monitoring must define clear frameworks for detecting performance drift, integrating user feedback into iterative updates, and managing incidents effectively. This also entails alignment with the MyHealth@EU incident reporting and aggregation system, ensuring timely and standardized communication of serious events across member states.

Quality management systems should be implemented in accordance with internationally recognized standards. In particular, ISO/IEC 42001 provides a dedicated framework for auditing, certifying, and governing AI management systems. As Benraouane [18] emphasizes, this standard is instrumental in embedding risk-based thinking, traceability, and accountability into AI product life cycle management, the elements that are foundational for both regulatory compliance and ethical assurance in clinical environments.

The CSP Conformance Testing Service acts as the final validation point, verifying compliance with document formats, security and transport envelopes, and audit trail integrity. Finally, the registration of high-risk AI systems in an EU database remains under regulatory consideration.

Fulfillment of these criteria allows AI-generated content, such as IPSs, ePrescription/eDispensation documents, discharge reports, laboratory results, and other future MyHealth@EU services, to enrich standardized clinical documents. These documents are typically formatted using either the HL7 CDA, a widely used XML-based format, or the future HL7 FHIR.

Tables 2 and 3 present an effort to incorporate a minimal AI Compliance subsection within the HL7 CDA and HL7 FHIR standards, correspondingly, without compromising the standard fields, including:

Given that future HL7 FHIR implementation would contain a DiagnosticReport for the summary, Observation for a discrete finding, and Provenance to record authorship and timing, the AI-related fields should be implemented as FHIR extensions to those resources with AI contributions, rationale, documentation links, AI confidence, interpretative metrics, and agent involvement as given in Table 3.

We intentionally avoided recommending new AI-based profiles, such as AIDiagnosticReport, to avoid adding complexity while the current draft profiles are still being finalized; this choice postpones fragmentation and makes it easier to converge on a future European AI profile.

For AI Act compliance, the key requirement is transparency, being able to flag AI involvement and link to the Annex IV technical file. These optional extensions satisfy that without imposing new mandatory constraints on trading partners. These extensions would be considered optional and valid only when AI has been included in some of the clinical reports without imposing new mandatory constraints on trading partners.

Table 4 presents a step-by-step guideline, which outlines essential actions to ensure clinicians that any AI-generated decision wrapped in the data message they receive through MyHealth@EU/OpenNCP complies fully with the AI Act. The same guidelines can also be used for AI Act–compliant national transfer of the clinical data.

Within member state A, a hospital EHR generates an IPS enriched by an AI module, which performs a summarization of discharge notes. The CDA header records the standard metadata, while the AI compliance section explicitly marks AI involvement (Textbox 1).

If the IPS were represented in FHIR, the AI metadata would be injected via extensions (Textbox 2).

The following describes how data is transmitted securely.

In member state B, the IPS is displayed in the local EHR. For clinicians using AI-aware interfaces, the “AI Compliance Information” block appears in a separate panel. For systems not supporting the extensions, the IPS remains schema-compliant and renders as a normal IPS, ensuring backward compatibility.

AI-enabled clinical systems introduce unique vulnerabilities that go beyond conventional cybersecurity threats. While the AI Act requires “robustness, accuracy, and cybersecurity” (Art 15), practical guidance is limited. To operationalize security within the compliance checklist, the OWASP GenAI Security Project risks have been aligned with concrete safeguards and their placement in the proposed phase-oriented framework as presented in Table 5.

The EU AI Act (Art 72) requires providers of high-risk AI systems to implement continuous postmarket monitoring to detect performance drift, manage incidents, conduct systematic risk assessments, and ensure that deployed models remain compliant throughout their life cycle. In parallel, MyHealth@EU mandates incident reporting and aggregation across member states, ensuring that system-wide risks are captured at the EU level. Integrating these 2 dimensions avoids fragmented monitoring, strengthens ongoing risk management, and builds clinical trust.

By mapping these dimensions side by side, developers and implementers gain a clear view of where obligations overlap, where they complement each other, and how a single workflow can satisfy both regimes. This mapping also highlights the types of artifacts (metrics, audit logs, JSON reports) that must be collected at each step to ensure traceability and trustworthiness across national borders.

Table 6 presents these monitoring dimensions, their regulatory anchors, and practical implementation measures. It demonstrates how local monitoring systems can be directly aligned with MyHealth@EU’s interoperability and incident aggregation mechanisms. Together, these measures create a unified monitoring pipeline that reduces duplication, enforces consistency, and strengthens clinical confidence in AI-enabled cross-border health data exchange.

While the tutorial proposes a harmonized pathway for embedding EU AI Act compliance within the MyHealth@EU interoperability framework, several limitations remain:

These limitations are not shortcomings of the proposed framework itself but reflect the immaturity of the ecosystem as a whole. Both the EU AI Act and the MyHealth@EU framework are in their earliest implementation stages, with several provisions and datasets still under development. Technically, national infrastructures and vendor systems are not yet fully equipped to conduct real-world validation of AI-augmented interoperability. Dependencies such as the EU AI database, expanded MyHealth@EU dataset services (eg, imaging, laboratory results), and vendor readiness must mature before end-to-end validation is feasible. Until then, the tutorial provides simulated examples that anticipate these developments and prepare the ground for future pilot deployments.

Deploying AI-enabled clinical decision support across Europe requires treating regulatory compliance (AI Act) and technical interoperability (MyHealth@EU) as inseparable design constraints. This tutorial has translated the legal language of the AI Act and the technical specifications of MyHealth@EU into a single, step-by-step blueprint for developers, architects, and policymakers.

By providing a phase-oriented checklist, lightweight CDA/FHIR extensions, and illustrative examples such as an AI-supported IPS transmission, we have shown how AI systems can be engineered to satisfy high-risk obligations while remaining interoperable with existing OpenNCP workflows. The tutorial also integrates emerging security practices from OWASP GenAI and aligns postmarket monitoring duties with MyHealth@EU’s incident aggregation framework.

For developers, the practical implications are clear:

As member states expand their National Contact Points and clinical datasets, this tutorial provides a reusable blueprint for integrating AI capabilities into cross-border health care. While real-world validation remains a next step, the presented framework offers developers an actionable guide to design, implement, and monitor AI-enabled systems that are simultaneously trustworthy, interoperable, and compliant.

This work is forward-looking, anticipating the convergence of the AI Act and MyHealth@EU frameworks. Although the concept is still in its early phases to be put into practice, it offers a worthwhile blueprint that equips developers to prepare for compliance and ensures that future AI-enabled clinical systems can meet both requirements from day 1.