mibe000309
10.3205/mibe000309
urn:nbn:de:0183-mibe0003098
Research Article
Interoperable clinical data integration for distributed medical AI: The Open Medical Inference Gateway
Interoperable Integration klinischer Daten für verteilte medizinische KI: Das Open Medical Inference Gateway
Pelka
Pelka
Obioma
O
Institute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Girardetstr. 2, 45131 Essen, GermanyInstitute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Essen, GermanyData Integration Center (DIC), University Hospital Essen (UME), Essen, Germany
obioma.pelka@uk-essen.de
author
Eil
Eil
Jan
J
Institute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Essen, Germany
author
Manjunatha
Manjunatha
Kaushik
K
Institute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Essen, Germany
author
Singh
Singh
Nimesh
N
Institute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Essen, Germany
author
Omeirat
Omeirat
Jazia
J
Data Integration Center (DIC), University Hospital Essen (UME), Essen, Germany
author
Sigle
Sigle
Stefan
S
MOLIT Institute for Personalized Medicine, Heilbronn, Germany
author
Mathes
Mathes
Georg
G
MOLIT Institute for Personalized Medicine, Heilbronn, Germany
author
Schweizer
Schweizer
Simon-Tobias
ST
GECKO Institute for Medicine, Informatics and Economics, Heilbronn University of Applied Sciences (HHN), Heilbronn, Germany
author
Stump
Stump
Shura-Roman
SR
Department of Radiology, University Medical Center, Freiburg, Germany
author
Girdziunaite
Girdziunaite
Gerda
G
Medical Data Integration Center (MeDIC), Charité – Universitätsmedizin Berlin, Berlin, Germany
author
Nensa
Nensa
Felix
F
Institute for Artificial Intelligence in Medicine (IKIM), University Hospital Essen (UME), Essen, Germany
author
German Medical Science GMS Publishing House
Düsseldorf
610
medical informatics
Open Medical Inference
gateway
FHIR
DICOM
AI inference
interoperability
open source
MII
service-oriented architecture
medizinische Informatik
Open Medical Inference
Gateway
FHIR
DICOM
KI-Inferenz
Interoperabilität
Open Source
MII
serviceorientierte Architektur
ISCB GMDS 2026
20260922
engl
This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License.
Dieser Artikel ist ein Open-Access-Artikel und steht unter den Lizenzbedingungen der Creative Commons Attribution 4.0 License (Namensnennung).
1860-9171
22
GMS Medizinische Informatik, Biometrie und Epidemiologie
GMS Med Inform Biom Epidemiol
11
Bundesministerium für Forschung, Technologie und Raumfahrt (BMFTR)
Hintergrund: Die Integration von KI-Inferenzdiensten in klinische Arbeitsabläufe bleibt eine anhaltende Herausforderung, vor allem weil Inferenz-Backends und Standards für Gesundheitsdaten von grundlegend unterschiedlichen Annahmen ausgehen. Der EU AI Act fordert zudem Transparenz und Nachvollziehbarkeit für Hochrisiko-KI-Systeme im Gesundheitswesen.Methoden: Diese Arbeit stellt das Open Medical Inference (OMI) Gateway vor, eine Interoperabilitätsschicht, die zwischen FHIR- und DICOM-ba<![CDATA[s</PlainText></TextGroup>ierten klinischen Datenumgebungen und heterogenen KI-Inferenz-Backends vermittelt. Das Gateway wurde in Python mit FastAPI und asynchroner Auftragsverarbeitung über Celery und RabbitMQ implementiert. Die Architektur folgt einem serviceorientierten Plug-in-Modell, das gemeinsame Interoperabilitätsaufgaben von dienstspezifischer Transformationslogik trennt. Ein- und Ausgabedaten werden an mehreren Stellen der Pipeline gegen FHIR-Profile und DICOM-Spezifikationen validiert und erzeugen OperationOutcome-Ressourcen als maschinenles<TextGroup><PlainText>b</PlainText></TextGroup>aren Audit-Trail. </Pgraph><Pgraph><Mark1>Ergebnisse:</Mark1> Die Ende-zu-Ende-Latenz wurde über 100 aufeinanderfolgende Inferenzanfragen gemessen und ergab eine mediane Latenz von 263 ms bei einer Erfolgsrate von 100%. Das Konzept wurde anhand von Interoperabilitätsanforderungen aus Datenintegrationszentren der deutschen Medizininformatik-Initiative (MII) evaluiert. Das System ist mit einem einzigen Befehl einsatzbereit und als Open-Source-Software verfügbar.</Pgraph><Pgraph><Mark1>Diskussion:</Mark1> Die direkte Einbettung von Validierung und strukturierter Artefaktverarbeitung in den Ausführungspfad der Inferenz ergibt ein besser steuer- und auditierbares Integrationsmodell als ad-hoc entwickelte Dienstadapter.</Pgraph></Abstract>
<Abstract language="en" linked="yes"><Pgraph><Mark1>Background:</Mark1> Integrating AI inference services into clinical workflows remains a persistent challenge, primarily because inference backends and healthcare data standards operate with fundamentally different assumptions. The EU AI Act further requires transparency and traceab<TextGroup><PlainText>i</PlainText></TextGroup>lity for high-risk AI systems in healthcare. </Pgraph><Pgraph><Mark1>Methods:</Mark1> This paper presents the Open Medical Inference (OMI) Gateway, an interoperability layer that mediates between FHIR- and DICOM-based clinical data environments and heterogeneous AI inference backends. The gateway was implemented in Python using FastAPI with asynchronous job processing via Celery and RabbitMQ. The architecture follows a service-oriented plugin model that separates shared interoperability concerns from service-specific transformation logic. Input and output data are validated against FHIR profiles and DICOM specifications at multiple pipeline stages, producing OperationOutcome resources as a machine-readable audit trail. </Pgraph><Pgraph><Mark1>Results:</Mark1> End-to-end pipeline latency was measured across 100 sequential inference requests, yielding a median latency of 263 ms and a 100% success rate. The design was evaluated against interoperability requirements from German Medical Informatics Initiative (MII) Data Integration Centers. The system is deployable with a single command and available as open-source software. </Pgraph><Pgraph><Mark1>Discussion:</Mark1> The results indicate that embedding validation and structured artifact handling directly into the inference execution path yields a more governable and auditable integration model than ad-hoc service adapters.</Pgraph></Abstract>
<TextBlock name="1 Introduction" linked="yes">
<MainHeadline>1 Introduction</MainHeadline><Pgraph>Healthcare AI services are now routinely deployed as remote or containerized endpoints, but their operational integration into clinical information systems remains fragmented. Hospitals may operate FHIR servers, PACS archives, and Data Integration Centers (DICs), but connecting these to AI inference endpoints requires solving several distinct problems, including semantic alignment between healthcare standards and computation-oriented model protocols, lifecycle management for asynchronous jobs, validation of inputs and outputs, and consistent artifact storage. Without a dedicated integration layer, each new AI service introduces its own adapter logic, leading to systems that scale poorly and are difficult to govern or audit.</Pgraph><Pgraph>Several platforms address aspects of this challenge. Kaapana <TextLink reference="1"></TextLink> provides workflow orchestration for medical data analysis. The Joint Imaging Platform (JIP) <TextLink reference="2"></TextLink> enables federated analytics across the German Cancer Consortium. MONAI Deploy <TextLink reference="3"></TextLink> offers containerized inference services. Inference platforms such as Triton <TextLink reference="4"></TextLink> or KServe <TextLink reference="5"></TextLink> optimize for throughput but leave semantic transformation to the caller. The IHE profiles AIW-I and AIR <TextLink reference="6"></TextLink>, <TextLink reference="7"></TextLink> address result communication but not inference governance. None provide a complete, standards-compliant inference gateway with built-in governance mechanisms.</Pgraph><Pgraph>The Open Medical Inference (OMI) protocol <TextLink reference="8"></TextLink> defines standardized interfaces for AI service discovery, data exchange, and inference invocation based on HL7 FHIR (Release 4B, v4.3.0) <TextLink reference="9"></TextLink> and DICOMweb <TextLink reference="10"></TextLink>. The corresponding FHIR Implementation Guide is published on Simplifier <TextLink reference="11"></TextLink>. The OMI framework was designed within the German Medical Informatics Initiative <TextLink reference="12"></TextLink>, <TextLink reference="13"></TextLink>, <TextLink reference="14"></TextLink>. The OMI Gateway is the key execution boundary, providing an interoperability layer that validates, stages, and manages multimodal clinical data before and after model execution.</Pgraph><Pgraph>This work defines the architectural properties a gateway component needs to fulfill interoperability requirements in distributed medical AI, implements them in the OMI Gateway, and evaluates its operational functionality. Our contributions are threefold: </Pgraph><Pgraph><OrderedList><ListItem level="1" levelPosition="1" numString="1.">We describe the architecture of a production-capable inference gateway based on open standards. </ListItem><ListItem level="1" levelPosition="2" numString="2.">We present a plugin architecture enabling AI developers to integrate services with minimal effort. </ListItem><ListItem level="1" levelPosition="3" numString="3.">We evaluate the system’s operational performance and validate the inference pipeline, including a multi-stage FHIR-based validation mechanism producing machine-readable audit trails.</ListItem></OrderedList></Pgraph></TextBlock>
<TextBlock name="2 Background" linked="yes">
<MainHeadline>2 Background</MainHeadline><SubHeadline>2.1 Clinical data standards in AI workflows</SubHeadline><Pgraph>HL7 FHIR and DICOM occupy complementary roles in clinical AI workflows. HL7 FHIR provides structured representations of patient context, observations, and workflow parameters <TextLink reference="9"></TextLink>, while DICOM carries imaging data and modality-specific semantics <TextLink reference="10"></TextLink>. In multimodal AI settings, neither standard alone is sufficient. As Lehne et al. <TextLink reference="15"></TextLink> observe, interoperability is a prerequisite in digital medicine, not a peripheral concern.</Pgraph><Pgraph>Inference protocols such as KServe’s Open Inference Protocol <TextLink reference="5"></TextLink> assume inputs are already model-ready tensors. They do not define how FHIR resources or DICOM series should be validated or mapped. Placing this alignment inside each AI service leads to duplicated effort and inconsistent behavior.</Pgraph><SubHeadline>2.2 Data Integration Centers and the MII context</SubHeadline><Pgraph>The German Medical Informatics Initiative (MII) provides a reference for federated clinical data integration <TextLink reference="12"></TextLink>, <TextLink reference="13"></TextLink>. Data Integration Centers (DICs) consolidate institutional data and expose it through FHIR interfaces. Recent work has demonstrated scalable DICOM-to-FHIR pipelines <TextLink reference="16"></TextLink>, making AI-ready data provisioning feasible at scale. The OMI Gateway is positioned as the interface between DIC-level data structures and distributed AI services.</Pgraph></TextBlock>
<TextBlock name="3 Methods" linked="yes">
<MainHeadline>3 Methods</MainHeadline><SubHeadline>3.1 System architecture</SubHeadline><Pgraph>The Gateway follows a microservice architecture implemented via Docker Compose with six services: the API server, an asynchronous worker, PostgreSQL, RabbitMQ, SeaweedFS (S3-compatible storage), and a FHIR validation service (Figure 1 <ImgLink imgNo="1" imgType="figure" />).</Pgraph><Pgraph>The architecture rests on four design decisions: </Pgraph><Pgraph><OrderedList><ListItem level="1" levelPosition="1" numString="1."><Mark1>enforced conformance</Mark1> – validating all inputs and outputs against FHIR/DICOM profiles; </ListItem><ListItem level="1" levelPosition="2" numString="2."><Mark1>separation of concerns</Mark1> – the platform manages authentication, job lifecycles, and storage, while plugins handle service-specific logic; </ListItem><ListItem level="1" levelPosition="3" numString="3."><Mark1>asynchronous execution</Mark1> – decoupling processing from HTTP handling; </ListItem><ListItem level="1" levelPosition="4" numString="4."><Mark1>artifacts as first-class objects</Mark1> – storing inputs and outputs as addressable entities for auditability <TextLink reference="17"></TextLink>.</ListItem></OrderedList></Pgraph><Pgraph>The API server, implemented using FastAPI <TextLink reference="18"></TextLink>, creates a job record on each submission, uploads FHIR resources and DICOM files to S3-compatible storage encrypted at rest, and dispatches the task via RabbitMQ. An HTTP 202 response with the job identifier is returned immediately. The worker retrieves data from storage, executes the pipeline, and uploads results back, allowing independent scaling of servers and workers.</Pgraph><SubHeadline>3.2 Processing pipeline</SubHeadline><Pgraph>Each request passes through six phases (Figure 2 <ImgLink imgNo="2" imgType="figure" />), with the inter-component message flow shown in Figure 3 <ImgLink imgNo="3" imgType="figure" />:</Pgraph><Pgraph><OrderedList><ListItem level="1" levelPosition="1" numString="1."><Mark1>Pre-validation:</Mark1> FHIR resources are validated against the service’s input StructureDefinition using an external FHIR validator. DICOM files are validated within the worker process for required tags (e.g., Patient ID, Modality), correct VR types, and VM ranges <TextLink reference="19"></TextLink>. Both produce OperationOutcome resources.</ListItem><ListItem level="1" levelPosition="2" numString="2."><Mark1>Service-specific validation:</Mark1> The plugin performs domain-specific checks, e.g., verifying CT modality.</ListItem><ListItem level="1" levelPosition="3" numString="3."><Mark1>Preprocessing:</Mark1> Clinical inputs are transformed into model-ready representations.</ListItem><ListItem level="1" levelPosition="4" numString="4."><Mark1>Inference:</Mark1> The plugin executes locally or delegates to a remote backend.</ListItem><ListItem level="1" levelPosition="5" numString="5."><Mark1>Postprocessing:</Mark1> Predictions are translated into FHIR resources or DICOM segmentation objects.</ListItem><ListItem level="1" levelPosition="6" numString="6."><Mark1>Post-validation:</Mark1> Outputs are validated against the declared output StructureDefinition.</ListItem></OrderedList></Pgraph><Pgraph><ImgPlaceholder imgNo="2" imgType="figure"/><ImgPlaceholder imgNo="3" imgType="figure"/></Pgraph><Pgraph>Each validation stage produces OperationOutcome resources stored alongside job artifacts. If a plugin raises an unhandled exception, the worker catches the error, sets the job to <Mark2>failed</Mark2>, and generates an OperationOut<TextGroup><PlainText>c</PlainText></TextGroup>ome with severity <Mark2>fatal</Mark2>. </Pgraph><Pgraph>Three failure modes illustrate this: </Pgraph><Pgraph><OrderedList><ListItem level="1" levelPosition="1" numString="1.">a DICOM file missing the <Mark2>Modality</Mark2> tag triggers pre-validation termination; </ListItem><ListItem level="1" levelPosition="2" numString="2.">a FHIR resource with an undefined element produces a <Mark2>warning</Mark2> that may allow continuation depending on severity thresholds; </ListItem><ListItem level="1" levelPosition="3" numString="3.">missing DICOM files trigger a fatal OperationOutcome during service validation.</ListItem></OrderedList></Pgraph><SubHeadline>3.3 Plugin architecture</SubHeadline><Pgraph>AI services are integrated through Python entry points <TextLink reference="20"></TextLink>. Developers implement the abstract <Mark2>BaseService</Mark2> class (Table 1 <ImgLink imgNo="1" imgType="table" />), packaged as an independent Python package. On startup, the gateway discovers and loads all installed service packages. The gateway handles data transport, encryption at rest, validation, and job lifecycle; developers only implement the service-specific methods.</Pgraph><SubHeadline>3.4 API design and security</SubHeadline><Pgraph>The gateway exposes RESTful endpoints for service listing (<Mark2>GET /services</Mark2>), readiness and liveness checks, input validation (<Mark2>POST /services/{id}/validate</Mark2>), inference submission (<Mark2>POST /services/{id}/infer</Mark2>), and job retrieval (<TextGroup><Mark2>GET /jobs/{id}</Mark2></TextGroup>). Input data is submitted as multipart form data with HL7 FHIR conformant JSON and DICOM files. Authentication uses API keys (<Mark2>X-API-Key</Mark2> header) stored as SHA-256 hashes with role-based permissions. OperationOutcome resources at each stage, together with timestamped job status logs, provide a complete audit trail aligned with the EU AI Act <TextLink reference="21"></TextLink>, and AMIA’s AI principles <TextLink reference="17"></TextLink>. Where an integrated AI service qualifies as a medical device, the EU Medical Device Regulation (MDR) <TextLink reference="22"></TextLink> additionally applies; the gateway’s persistent, machine-readable audit trail can support the traceability and post-market surveillance obligations arising from the MDR.</Pgraph></TextBlock>
<TextBlock name="4 Results" linked="yes">
<MainHeadline>4 Results</MainHeadline><Pgraph>We now evaluate the Gateway’s operational behavior and its fulfillment of the interoperability requirements introduced above. The gateway was validated using dummy inference service implementing the complete BaseService interface. Testing confirmed the successful processing of multi-file DICOM submissions alongside FHIR metadata through programmatic access and Swagger UI. The asynchronous job pattern correctly transitions between pending, executing, and completed.</Pgraph><Pgraph>End-to-end latency was measured across 100 sequential requests using two DICOM files (CT_small.dcm, 38 KB and MR_small.dcm, 10 KB), chosen to isolate gateway overhead. Table 2 <ImgLink imgNo="2" imgType="table" /> shows all 100 requests completed successfully. The median 263 ms demonstrates low overhead; in production, inference time is additive.</Pgraph><SubHeadline>4.1 Interoperability evaluation</SubHeadline><Pgraph>The plugin interface allows routing requests to either a central remote inference service or a local compute node, such as a RACOON-connected GPU server <TextLink reference="23"></TextLink>, without changing the client-facing API. Consider a segmentation service accepting a CT study with a FHIR parameter set: the gateway validates both inputs, dispatches processing asynchronously, and reconstructs the segmentation as a DICOM object with an optional FHIR diagnostic report.</Pgraph><Pgraph>The gateway realizes the following architectural properties derived from MII-aligned interoperability requirements: FHIR profile conformance through profile-aware input/output validation producing OperationOutcome resources; DICOM handling through structural validation against specification expectations; asynchronous execution via background workers decoupled from HTTP handling; service discoverability through a versioned plugin registry with queryable FHIR profiles; multimodal data staging with separate artifact directories per modality; audit and traceability through job lifecycle records combined with OperationOutcome resources; and backend flexibility through plugin routing that transparently directs to remote services or local GPU nodes. Iterative testing revealed five integration issues across storage, validation, and deployment. The system is deployable with <Mark2>docker compose up</Mark2>. The source code will be made available upon publication.</Pgraph></TextBlock>
<TextBlock name="5 Discussion" linked="yes">
<MainHeadline>5 Discussion</MainHeadline><Pgraph>The OMI Gateway’s principal contribution lies in relocating interoperability enforcement from individual service adapters into a shared integration component. When validation is handled centrally, all AI services benefit from consistent conformance checking, and standards-conformant outputs can be consumed downstream without additional transformation. This positions the gateway as a genuine integration component rather than a thin proxy <TextLink reference="17"></TextLink>.</Pgraph><Pgraph>Compared to existing platforms (Table 3 <ImgLink imgNo="3" imgType="table" />), the gateway occupies a distinct position: Kaapana, JIP, and MONAI Deploy provide federated model training and workflow orchestration but lack a FHIR-based validation pipeline with structured audit trails. The OMI Gateway focuses on standardized inference invocation with built-in governance. The FHIR-based validation pipeline creates a complete, machine-readable audit trail supporting EU AI Act <TextLink reference="21"></TextLink> transparency requirements. Together with the OMI DICOMweb adapter <TextLink reference="24"></TextLink>, it provides the core standards-based infrastructure for clinical AI inference.</Pgraph><SubHeadline>5.1 Limitations and future work</SubHeadline><Pgraph>The current implementation uploads files synchronously, which may introduce latency for large DICOM datasets. Worker concurrency is limited to a single process; horizontal scaling is supported via additional Celery workers. Federation features including registry synchronization and heartbeat exchange are extension targets. Consent management is expected to rely on surrounding DIC components.</Pgraph><Pgraph>Future work includes integration with the OMI Service Registry <TextLink reference="25"></TextLink> through a FHIR-based heartbeat mechanism, federation with RACOON <TextLink reference="23"></TextLink>, multi-step pipeline orchestration, and governance-aligned monitoring <TextLink reference="17"></TextLink>. Validation with production AI models at clinical sites is planned.</Pgraph></TextBlock>
<TextBlock name="Notes" linked="yes">
<MainHeadline>Notes</MainHeadline><SubHeadline>Authors’ ORCIDs</SubHeadline><Pgraph><UnorderedList><ListItem level="1">Obioma Pelka: <Hyperlink href="https://orcid.org/0000-0001-5156-4429">0000-0001-5156-4429</Hyperlink></ListItem><ListItem level="1">Jan Eil: <Hyperlink href="https://orcid.org/0009-0005-9879-5722">0009-0005-9879-5722</Hyperlink></ListItem><ListItem level="1">Kaushik Manjunatha: <Hyperlink href="https://orcid.org/0009-0006-0993-6173">0009-0006-0993-6173</Hyperlink></ListItem><ListItem level="1">Stefan Sigle: <Hyperlink href="https://orcid.org/0000-0001-7475-4583">0000-0001-7475-4583</Hyperlink></ListItem><ListItem level="1">Georg Mathes: <Hyperlink href="https://orcid.org/0009-0000-2060-5558">0009-0000-2060-5558</Hyperlink></ListItem><ListItem level="1">Simon-Tobias Schweizer: <Hyperlink href="https://orcid.org/0000-0002-0888-4301">0000-0002-0888-4301</Hyperlink></ListItem><ListItem level="1">Shura-Roman Stump: <Hyperlink href="https://orcid.org/0009-0009-8542-6556">0009-0009-8542-6556</Hyperlink></ListItem><ListItem level="1">Gerda Girdziunaite: <Hyperlink href="https://orcid.org/0009-0000-5562-453X">0009-0000-5562-453X</Hyperlink></ListItem><ListItem level="1">Felix Nensa: <Hyperlink href="https://orcid.org/0000-0002-5811-7100">0000-0002-5811-7100</Hyperlink></ListItem></UnorderedList></Pgraph><SubHeadline>Author contributions</SubHeadline><Pgraph>Obioma Pelka and Jan Eil contributed equally to this work.</Pgraph><SubHeadline>Competing interests</SubHeadline><Pgraph>The authors declare that they have no competing interests.</Pgraph></TextBlock>
<References linked="yes">
<Reference refNo="1">
<RefAuthor>Akünal Ü</RefAuthor>
<RefAuthor>Bujotzek M</RefAuthor>
<RefAuthor>Denner S</RefAuthor>
<RefAuthor>Hamm B</RefAuthor>
<RefAuthor>Kades K</RefAuthor>
<RefAuthor>Schader P</RefAuthor>
<RefAuthor>Scherer J</RefAuthor>
<RefAuthor>Nolden M</RefAuthor>
<RefAuthor>Neher P</RefAuthor>
<RefAuthor>Floca R</RefAuthor>
<RefAuthor>Maier-Heine K</RefAuthor>
<RefTitle>Kaapana: a comprehensive open-source platform for integrating AI in medical imaging research environments [Preprint]</RefTitle>
<RefYear>2025</RefYear>
<RefJournal>arXiv</RefJournal>
<RefArticleNo>arXiv:2512.09644</RefArticleNo>
<RefTotal>Akünal Ü, Bujotzek M, Denner S, Hamm B, Kades K, Schader P, Scherer J, Nolden M, Neher P, Floca R, Maier-Heine K. Kaapana: a comprehensive open-source platform for integrating AI in medical imaging research environments [Preprint]. arXiv. 2025. arXiv:2512.09644. DOI: 10.48550/arXiv.2512.09644</RefTotal>
<RefLink>https://doi.org/10.48550/arXiv.2512.09644</RefLink>
</Reference>
<Reference refNo="2">
<RefAuthor>Scherer J</RefAuthor>
<RefAuthor>Nolden M</RefAuthor>
<RefAuthor>Kleesiek J</RefAuthor>
<RefAuthor>Metzger J</RefAuthor>
<RefAuthor>Kades K</RefAuthor>
<RefAuthor>Schneider V</RefAuthor>
<RefAuthor>Bach M</RefAuthor>
<RefAuthor>Sedlaczek O</RefAuthor>
<RefAuthor>Bucher AM</RefAuthor>
<RefAuthor>Vogl TJ</RefAuthor>
<RefAuthor>Grünwald F</RefAuthor>
<RefAuthor>Kühn JP</RefAuthor>
<RefAuthor>Hoffmann RT</RefAuthor>
<RefAuthor>Kotzerke J</RefAuthor>
<RefAuthor>Bethge O</RefAuthor>
<RefAuthor>Schimmöller L</RefAuthor>
<RefAuthor>Antoch G</RefAuthor>
<RefAuthor>Müller HW</RefAuthor>
<RefAuthor>Daul A</RefAuthor>
<RefAuthor>Nikolaou K</RefAuthor>
<RefAuthor>la Fougère C</RefAuthor>
<RefAuthor>Kunz WG</RefAuthor>
<RefAuthor>Ingrisch M</RefAuthor>
<RefAuthor>Schachtner B</RefAuthor>
<RefAuthor>Ricke J</RefAuthor>
<RefAuthor>Bartenstein P</RefAuthor>
<RefAuthor>Nensa F</RefAuthor>
<RefAuthor>Radbruch A</RefAuthor>
<RefAuthor>Umutlu L</RefAuthor>
<RefAuthor>Forsting M</RefAuthor>
<RefAuthor>Seifert R</RefAuthor>
<RefAuthor>Herrmann K</RefAuthor>
<RefAuthor>Mayer P</RefAuthor>
<RefAuthor>Kauczor HU</RefAuthor>
<RefAuthor>Penzkofer T</RefAuthor>
<RefAuthor>Hamm B</RefAuthor>
<RefAuthor>Brenner W</RefAuthor>
<RefAuthor>Kloeckner R</RefAuthor>
<RefAuthor>Düber C</RefAuthor>
<RefAuthor>Schreckenberger M</RefAuthor>
<RefAuthor>Braren R</RefAuthor>
<RefAuthor>Kaissis G</RefAuthor>
<RefAuthor>Makowski M</RefAuthor>
<RefAuthor>Eiber M</RefAuthor>
<RefAuthor>Gafita A</RefAuthor>
<RefAuthor>Trager R</RefAuthor>
<RefAuthor>Weber WA</RefAuthor>
<RefAuthor>Neubauer J</RefAuthor>
<RefAuthor>Reisert M</RefAuthor>
<RefAuthor>Bock M</RefAuthor>
<RefAuthor>Bamberg F</RefAuthor>
<RefAuthor>Hennig J</RefAuthor>
<RefAuthor>Meyer PT</RefAuthor>
<RefAuthor>Ruf J</RefAuthor>
<RefAuthor>Haberkorn U</RefAuthor>
<RefAuthor>Schoenberg SO</RefAuthor>
<RefAuthor>Kuder T</RefAuthor>
<RefAuthor>Neher P</RefAuthor>
<RefAuthor>Floca R</RefAuthor>
<RefAuthor>Schlemmer HP</RefAuthor>
<RefAuthor>Maier-Hein K</RefAuthor>
<RefTitle>Joint Imaging Platform for Federated Clinical Data Analytics</RefTitle>
<RefYear>2020</RefYear>
<RefJournal>JCO Clin Cancer Inform</RefJournal>
<RefPage>1027-1038</RefPage>
<RefTotal>Scherer J, Nolden M, Kleesiek J, Metzger J, Kades K, Schneider V, Bach M, Sedlaczek O, Bucher AM, Vogl TJ, Grünwald F, Kühn JP, Hoffmann RT, Kotzerke J, Bethge O, Schimmöller L, Antoch G, Müller HW, Daul A, Nikolaou K, la Fougère C, Kunz WG, Ingrisch M, Schachtner B, Ricke J, Bartenstein P, Nensa F, Radbruch A, Umutlu L, Forsting M, Seifert R, Herrmann K, Mayer P, Kauczor HU, Penzkofer T, Hamm B, Brenner W, Kloeckner R, Düber C, Schreckenberger M, Braren R, Kaissis G, Makowski M, Eiber M, Gafita A, Trager R, Weber WA, Neubauer J, Reisert M, Bock M, Bamberg F, Hennig J, Meyer PT, Ruf J, Haberkorn U, Schoenberg SO, Kuder T, Neher P, Floca R, Schlemmer HP, Maier-Hein K. Joint Imaging Platform for Federated Clinical Data Analytics. JCO Clin Cancer Inform. 2020 Nov;4:1027-1038.
DOI: 10.1200/CCI.20.00045</RefTotal>
<RefLink>https://doi.org/10.1200/CCI.20.00045</RefLink>
</Reference>
<Reference refNo="3">
<RefAuthor>Cardoso MJ</RefAuthor>
<RefAuthor>Li W</RefAuthor>
<RefAuthor>Brown R</RefAuthor>
<RefAuthor>Ma N</RefAuthor>
<RefAuthor>Kerfoot E</RefAuthor>
<RefAuthor>Wang Y</RefAuthor>
<RefAuthor>Murrey B</RefAuthor>
<RefAuthor>Myronenko A</RefAuthor>
<RefAuthor>Zhao C</RefAuthor>
<RefAuthor>Yang D</RefAuthor>
<RefAuthor></RefAuthor>
<RefTitle>MONAI: an open-source framework for deep learning in healthcare [Preprint]</RefTitle>
<RefYear>2022</RefYear>
<RefJournal>arXiv</RefJournal>
<RefArticleNo>arXiv:2211.02701</RefArticleNo>
<RefTotal>Cardoso MJ, Li W, Brown R, Ma N, Kerfoot E, Wang Y, Murrey B, Myronenko A, Zhao C, Yang D, et al. MONAI: an open-source framework for deep learning in healthcare [Preprint]. arXiv. 2022. arXiv:2211.02701. DOI: 10.48550/arXiv.2211.02701</RefTotal>
<RefLink>https://doi.org/10.48550/arXiv.2211.02701</RefLink>
</Reference>
<Reference refNo="4">
<RefAuthor>NVIDIA Corporation</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2026</RefYear>
<RefBookTitle>Triton Inference Server</RefBookTitle>
<RefPage></RefPage>
<RefTotal>NVIDIA Corporation. Triton Inference Server. Santa Clara (CA): NVIDIA; 2026 [cited 2026 Jun 23]. Available from: https://developer.nvidia.com/triton-inference-server</RefTotal>
<RefLink>https://developer.nvidia.com/triton-inference-server</RefLink>
</Reference>
<Reference refNo="5">
<RefAuthor>KServe</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2026</RefYear>
<RefBookTitle>Open Inference Protocol (V2)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>KServe. Open Inference Protocol (V2). KServe; 2026 [cited 2026 Jun 23]. Available from: https://kserve.github.io/website/docs/concepts/architecture/data-plane/v2-protocol</RefTotal>
<RefLink>https://kserve.github.io/website/docs/concepts/architecture/data-plane/v2-protocol</RefLink>
</Reference>
<Reference refNo="6">
<RefAuthor>IHE Radiology Technical Committee</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2020</RefYear>
<RefBookTitle>IHE Radiology Technical Framework Supplement: AI workflow for imaging (AIW-I)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>IHE Radiology Technical Committee. IHE Radiology Technical Framework Supplement: AI workflow for imaging (AIW-I). Rev. 1.1. Oak Brook (IL): IHE International; 2020 Aug 6 [cited 2026 Jun 23]. Available from: https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_AIW-I.pdf</RefTotal>
<RefLink>https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_AIW-I.pdf</RefLink>
</Reference>
<Reference refNo="7">
<RefAuthor>IHE Radiology Technical Committee</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2025</RefYear>
<RefBookTitle>IHE Radiology Technical Framework Supplement: AI results (AIR)</RefBookTitle>
<RefPage></RefPage>
<RefTotal>IHE Radiology Technical Committee. IHE Radiology Technical Framework Supplement: AI results (AIR). Rev. 1.3. Oak Brook (IL): IHE International; 2025 Aug 8 [cited 2026 Jun 23]. Available from: https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_AIR.pdf</RefTotal>
<RefLink>https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_AIR.pdf</RefLink>
</Reference>
<Reference refNo="8">
<RefAuthor>Pelka O</RefAuthor>
<RefAuthor>Sigle S</RefAuthor>
<RefAuthor>Werner P</RefAuthor>
<RefAuthor>Schweizer ST</RefAuthor>
<RefAuthor>Iancu A</RefAuthor>
<RefAuthor>Scherer L</RefAuthor>
<RefAuthor>Kamzol NA</RefAuthor>
<RefAuthor>Eil JH</RefAuthor>
<RefAuthor>Apfelbacher T</RefAuthor>
<RefAuthor>Seletkov D</RefAuthor>
<RefAuthor>Susetzky T</RefAuthor>
<RefAuthor>May MS</RefAuthor>
<RefAuthor>Bucher AM</RefAuthor>
<RefAuthor>Fegeler C</RefAuthor>
<RefAuthor>Boeker M</RefAuthor>
<RefAuthor>Braren R</RefAuthor>
<RefAuthor>Prokosch HU</RefAuthor>
<RefAuthor>Nensa F</RefAuthor>
<RefTitle>Demokratisierung von KI im Gesundheitswesen mit Open Medical Inference (OMI): Protokolle, Datenaustausch und KI-Integration Democratizing AI in Healthcare with Open Medical Inference (OMI): Protocols, Data Exchange, and AI Integration</RefTitle>
<RefYear>2026</RefYear>
<RefJournal>Rofo</RefJournal>
<RefPage>173-184</RefPage>
<RefTotal>Pelka O, Sigle S, Werner P, Schweizer ST, Iancu A, Scherer L, Kamzol NA, Eil JH, Apfelbacher T, Seletkov D, Susetzky T, May MS, Bucher AM, Fegeler C, Boeker M, Braren R, Prokosch HU, Nensa F. Demokratisierung von KI im Gesundheitswesen mit Open Medical Inference (OMI): Protokolle, Datenaustausch und KI-Integration Democratizing AI in Healthcare with Open Medical Inference (OMI): Protocols, Data Exchange, and AI Integration. Rofo. 2026 Feb;198(2):173-184. DOI: 10.1055/a-2651-6653</RefTotal>
<RefLink>https://doi.org/10.1055/a-2651-6653</RefLink>
</Reference>
<Reference refNo="9">
<RefAuthor>Health Level Seven International</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2022</RefYear>
<RefBookTitle>HL7 FHIR</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Health Level Seven International. HL7 FHIR. Release 4B (v4.3.0). Ann Arbor (MI): HL7; 2022 [cited 2026 Jun 23]. Available from: https://hl7.org/fhir/R4B/</RefTotal>
<RefLink>https://hl7.org/fhir/R4B/</RefLink>
</Reference>
<Reference refNo="10">
<RefAuthor>Genereaux BW</RefAuthor>
<RefAuthor>Dennison DK</RefAuthor>
<RefAuthor>Ho K</RefAuthor>
<RefAuthor>Horn R</RefAuthor>
<RefAuthor>Silver EL</RefAuthor>
<RefAuthor>O’Donnell K</RefAuthor>
<RefAuthor>Kahn CE Jr</RefAuthor>
<RefTitle>DICOMweb™: Background and Application of the Web Standard for Medical Imaging</RefTitle>
<RefYear>2018</RefYear>
<RefJournal>J Digit Imaging</RefJournal>
<RefPage>321-326</RefPage>
<RefTotal>Genereaux BW, Dennison DK, Ho K, Horn R, Silver EL, O’Donnell K, Kahn CE Jr. DICOMweb™: Background and Application of the Web Standard for Medical Imaging. J Digit Imaging. 2018 Jun;31(3):321-326. DOI: 10.1007/s10278-018-0073-z</RefTotal>
<RefLink>https://doi.org/10.1007/s10278-018-0073-z</RefLink>
</Reference>
<Reference refNo="11">
<RefAuthor>OMI Consortium</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>OMI Protocol Implementation Guide</RefBookTitle>
<RefPage></RefPage>
<RefTotal>OMI Consortium. OMI Protocol Implementation Guide. Simplifier.net; 2024 [cited 2026 Jun 23]. Available from: https://simplifier.net/guide/OMI-Protocol-IG/Open-Medical-Inference-Protocol</RefTotal>
<RefLink>https://simplifier.net/guide/OMI-Protocol-IG/Open-Medical-Inference-Protocol</RefLink>
</Reference>
<Reference refNo="12">
<RefAuthor>Medical Informatics Initiative (MII)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>Data integration centres</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Medical Informatics Initiative (MII). Data integration centres. Berlin: MII Coordination Office; 2024 [cited 2026 Jun 23]. Available from: https://www.medizininformatik-initiative.de/en/consortia/data-integration-centres</RefTotal>
<RefLink>https://www.medizininformatik-initiative.de/en/consortia/data-integration-centres</RefLink>
</Reference>
<Reference refNo="13">
<RefAuthor>Medical Informatics Initiative (MII)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>Core data set</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Medical Informatics Initiative (MII). Core data set. Berlin: MII Coordination Office; 2024 [cited 2026 Jun 23]. Available from: https://www.medizininformatik-initiative.de/en/medical-informatics-initiatives-core-data-set</RefTotal>
<RefLink>https://www.medizininformatik-initiative.de/en/medical-informatics-initiatives-core-data-set</RefLink>
</Reference>
<Reference refNo="14">
<RefAuthor>Sigle S</RefAuthor>
<RefAuthor>Werner P</RefAuthor>
<RefAuthor>Schweizer S</RefAuthor>
<RefAuthor>Caldeira L</RefAuthor>
<RefAuthor>Hosch R</RefAuthor>
<RefAuthor>Dyrba M</RefAuthor>
<RefAuthor>Fegeler C</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>Bridging the gap between (AI-) services and their application in research and clinical settings through interoperability: the OMI-protocol</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Sigle S, Werner P, Schweizer S, Caldeira L, Hosch R, Dyrba M, Fegeler C. Bridging the gap between (AI-) services and their application in research and clinical settings through interoperability: the OMI-protocol. Hannover: Technische Informationsbibliothek (TIB); 2024. DOI :10.34657/13458</RefTotal>
</Reference>
<Reference refNo="15">
<RefAuthor>Lehne M</RefAuthor>
<RefAuthor>Sass J</RefAuthor>
<RefAuthor>Essenwanger A</RefAuthor>
<RefAuthor>Schepers J</RefAuthor>
<RefAuthor>Thun S</RefAuthor>
<RefTitle>Why digital medicine depends on interoperability</RefTitle>
<RefYear>2019</RefYear>
<RefJournal>NPJ Digit Med</RefJournal>
<RefPage>79</RefPage>
<RefTotal>Lehne M, Sass J, Essenwanger A, Schepers J, Thun S. Why digital medicine depends on interoperability. NPJ Digit Med. 2019;2:79. DOI: 10.1038/s41746-019-0158-1</RefTotal>
<RefLink>https://doi.org/10.1038/s41746-019-0158-1</RefLink>
</Reference>
<Reference refNo="16">
<RefAuthor>Iancu A</RefAuthor>
<RefAuthor>Bauer J</RefAuthor>
<RefAuthor>May MS</RefAuthor>
<RefAuthor>Prokosch HU</RefAuthor>
<RefAuthor>Dörfler A</RefAuthor>
<RefAuthor>Uder M</RefAuthor>
<RefAuthor>Kapsner LA</RefAuthor>
<RefTitle>Large-Scale Integration of DICOM Metadata into HL7-FHIR for Medical Research</RefTitle>
<RefYear>2024</RefYear>
<RefJournal>Methods Inf Med</RefJournal>
<RefPage>77-84</RefPage>
<RefTotal>Iancu A, Bauer J, May MS, Prokosch HU, Dörfler A, Uder M, Kapsner LA. Large-Scale Integration of DICOM Metadata into HL7-FHIR for Medical Research. Methods Inf Med. 2024 Sep;63(3-04):77-84. DOI: 10.1055/a-2521-4250</RefTotal>
<RefLink>https://doi.org/10.1055/a-2521-4250</RefLink>
</Reference>
<Reference refNo="17">
<RefAuthor>Solomonides AE</RefAuthor>
<RefAuthor>Koski E</RefAuthor>
<RefAuthor>Atabaki SM</RefAuthor>
<RefAuthor>Weinberg S</RefAuthor>
<RefAuthor>McGreevey JD</RefAuthor>
<RefAuthor>Kannry JL</RefAuthor>
<RefAuthor>Petersen C</RefAuthor>
<RefAuthor>Lehmann CU</RefAuthor>
<RefTitle>Defining AMIA's artificial intelligence principles</RefTitle>
<RefYear>2022</RefYear>
<RefJournal>J Am Med Inform Assoc</RefJournal>
<RefPage>585-591</RefPage>
<RefTotal>Solomonides AE, Koski E, Atabaki SM, Weinberg S, McGreevey JD, Kannry JL, Petersen C, Lehmann CU. Defining AMIA's artificial intelligence principles. J Am Med Inform Assoc. 2022 Mar;29(4):585-591. DOI: 10.1093/jamia/ocac006</RefTotal>
<RefLink>https://doi.org/10.1093/jamia/ocac006</RefLink>
</Reference>
<Reference refNo="18">
<RefAuthor>Ramírez S</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2026</RefYear>
<RefBookTitle>FastAPI</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Ramírez S. FastAPI. 2026 [cited 2026 Jun 23]. Available from: https://fastapi.tiangolo.com/</RefTotal>
<RefLink>https://fastapi.tiangolo.com/</RefLink>
</Reference>
<Reference refNo="19">
<RefAuthor>Pydicom</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2026</RefYear>
<RefBookTitle>dicom-validator [software]</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Pydicom. dicom-validator [software]. Version 0.8.2. PyPI; 2026 [cited 2026 Jun 23]. Available from: https://pypi.org/project/dicom-validator/</RefTotal>
<RefLink>https://pypi.org/project/dicom-validator/</RefLink>
</Reference>
<Reference refNo="20">
<RefAuthor>Python Packaging Authority</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2026</RefYear>
<RefBookTitle>Entry points specification</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Python Packaging Authority. Entry points specification. PyPA; 2026 [cited 2026 Jun 23]. Available from: https://packaging.python.org/en/latest/specifications/entry-points/</RefTotal>
<RefLink>https://packaging.python.org/en/latest/specifications/entry-points/</RefLink>
</Reference>
<Reference refNo="21">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending certain Union legislative acts (Artificial Intelligence Act)</RefTitle>
<RefYear>2024</RefYear>
<RefJournal>Off J Eur Union</RefJournal>
<RefPage></RefPage>
<RefTotal>Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending certain Union legislative acts (Artificial Intelligence Act). Off J Eur Union. 2024 Jul 12;
L 2024/1689. Available from: http://data.europa.eu/eli/reg/2024/1689/oj</RefTotal>
<RefLink>http://data.europa.eu/eli/reg/2024/1689/oj</RefLink>
</Reference>
<Reference refNo="22">
<RefAuthor>Anonym</RefAuthor>
<RefTitle>Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC</RefTitle>
<RefYear>2017</RefYear>
<RefJournal>Off J Eur Union</RefJournal>
<RefPage>1-175</RefPage>
<RefTotal>Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC. Off J Eur Union. 2017 May 5;60(L117):1-175.</RefTotal>
</Reference>
<Reference refNo="23">
<RefAuthor>Network University Medicine (NUM)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>RACOON: Radiological Cooperative Network</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Network University Medicine (NUM). RACOON: Radiological Cooperative Network. Berlin: NUM; 2024 [cited 2026 Jun 23]. Available from: https://racoon.network/</RefTotal>
<RefLink>https://racoon.network/</RefLink>
</Reference>
<Reference refNo="24">
<RefAuthor>Pelka O</RefAuthor>
<RefAuthor>Kamzol NA</RefAuthor>
<RefAuthor>Manjunatha K</RefAuthor>
<RefAuthor>Singh N</RefAuthor>
<RefAuthor>Omeirat J</RefAuthor>
<RefAuthor>Nensa F</RefAuthor>
<RefTitle>A standards-based infrastructure for federated AI inference in medical imaging</RefTitle>
<RefYear>2026</RefYear>
<RefJournal>GMS Med Inform Biom Epidemiol</RefJournal>
<RefPage>Doc12</RefPage>
<RefTotal>Pelka O, Kamzol NA, Manjunatha K, Singh N, Omeirat J, Nensa F. A standards-based infrastructure for federated AI inference in medical imaging. GMS Med Inform Biom Epidemiol. 2026;22:Doc12. DOI: 10.3205/mibe000310</RefTotal>
<RefLink>https://doi.org/10.3205/mibe000310</RefLink>
</Reference>
<Reference refNo="25">
<RefAuthor>Open Medical Inference (OMI)</RefAuthor>
<RefTitle></RefTitle>
<RefYear>2024</RefYear>
<RefBookTitle>OMI service registry</RefBookTitle>
<RefPage></RefPage>
<RefTotal>Open Medical Inference (OMI). OMI service registry . GitLab; 2024 [cited 2026 Jun 23]. Available from: https://gitlab.com/omi-partner/wp6/omi-service-registry</RefTotal>
<RefLink>https://gitlab.com/omi-partner/wp6/omi-service-registry</RefLink>
</Reference>
</References>
<Media>
<Tables>
<Table format="png">
<MediaNo>1</MediaNo>
<MediaID>1</MediaID>
<Caption><Pgraph><Mark1>Table 1: BaseService interface methods</Mark1></Pgraph></Caption>
</Table>
<Table format="png">
<MediaNo>2</MediaNo>
<MediaID>2</MediaID>
<Caption><Pgraph><Mark1>Table 2: Pipeline durations across 100 requests (dummy service, single worker)</Mark1></Pgraph></Caption>
</Table>
<Table format="png">
<MediaNo>3</MediaNo>
<MediaID>3</MediaID>
<Caption><Pgraph><Mark1>Table 3: Comparison with related platforms</Mark1></Pgraph></Caption>
</Table>
<NoOfTables>3</NoOfTables>
</Tables>
<Figures>
<Figure width="950" height="488" format="png">
<MediaNo>1</MediaNo>
<MediaID>1</MediaID>
<Caption><Pgraph><Mark1>Figure 1: Microservice architecture of the OMI Gateway connecting clinical data environments to distributed AI inference services</Mark1></Pgraph></Caption>
</Figure>
<Figure width="958" height="397" format="png">
<MediaNo>2</MediaNo>
<MediaID>2</MediaID>
<Caption><Pgraph><Mark1>Figure 2: Six-stage pipeline. Validation stages (blue) produce OperationOutcome resources as an audit trail. Processing stages (green) handle transformation and inference.</Mark1></Pgraph></Caption>
</Figure>
<Figure width="1440" height="810" format="png">
<MediaNo>3</MediaNo>
<MediaID>3</MediaID>
<Caption><Pgraph><Mark1>Figure 3: End-to-end job execution sequence. The client receives HTTP 202 immediately; processing continues asynchronously. OperationOutcome resources are persisted at each validation stage. If validation fails, the job is marked as failed and the OperationOutcome is returned via the job endpoint.</Mark1></Pgraph></Caption>
</Figure>
<NoOfPictures>3</NoOfPictures>
</Figures>
<InlineFigures>
<NoOfPictures>0</NoOfPictures>
</InlineFigures>
<Attachments>
<NoOfAttachments>0</NoOfAttachments>
</Attachments>
</Media>
</OrigData>
</GmsArticle>]]></plaintext></textgroup></pgraph></abstract></origdata></gmsarticle>