Diese Studie umfasste weder die Rekrutierung von menschlichen Probanden noch den Zugriff auf identifizierbare Patientenakten oder Tierversuche. Das Protokoll wurde ausschließlich anhand öffentlich zugänglicher und vollständig anonymisierter Datensätze zur methodischen Validierung entwickelt und evaluiert. Es erfolgte kein Zugriff auf persönliche Gesundheitsdaten. Daher war keine Genehmigung durch eine zuständige Ethikkommission (IRB oder Research Ethics Committee) erforderlich. Das Protokoll wurde unter Einhaltung geltender Datenschutzgrundsätze, einschließlich des brasilianischen Allgemeinen Datenschutzgesetzes (LGPD), erstellt, um zukünftige Anwendungen mit klinischen Daten zu unterstützen.
Auswahl und Vorverarbeitung des Datensatzes
Das vorgeschlagene Protokoll wurde anhand öffentlich verfügbarer und vollständig anonymisierter klinischer Datensätze evaluiert, die strukturierte Elektronische Patientenakten (EHRs), Daten für klinische Frage-Antwort-Systeme sowie medizinische Bilddatensätze für die methodische Validierung umfassen. Vor der Integration in die Plattform durchliefen die Datensätze standardisierte Vorverarbeitungsschritte, einschließlich Datennormalisierung, Entfernung inkonsistenter oder unvollständiger Einträge, Zuordnung zu HL7 FHIR-Ressourcen, Textbereinigung, Segmentierung in Abrufblöcke und Erzeugung von Einbettungen für die Vektorindizierung. Diese Vorverarbeitungsschritte gewährleisteten semantische Konsistenz über heterogene Datenquellen hinweg, förderten die Interoperabilität und ermöglichten die Reproduzierbarkeit des vorgeschlagenen Workflows, wobei die Einhaltung geltender Datenschutzprinzipien sichergestellt blieb.
Die Datensätze wurden aus öffentlich zugänglichen Benchmark-Repositories bezogen, die üblicherweise in der Forschung zu künstlicher Intelligenz und digitaler Gesundheit verwendet werden. Sie wurden ausgewählt, um heterogene klinische Informationen darzustellen, einschließlich strukturierter Elektronischer Gesundheitsakten (EHRs), unstrukturierter klinischer Texte, klinischer Frage-Antwort-Aufgaben sowie Metadaten zu medizinischen Bildgebungsverfahren. Anstatt eine bestimmte klinische Kohorte zu evaluieren, konzentriert sich das Protokoll auf die Demonstration eines reproduzierbaren Implementierungsworkflows, der an verschiedene Datensätze im Gesundheitswesen angepasst werden kann. Die Vielfalt dieser Benchmark-Datensätze ermöglicht die Validierung der Interoperabilitätspipeline, der Retrieval-Augmented Generation (RAG) sowie des Multi-Agenten-Reasoning-Frameworks über mehrere klinische Datenmodi hinweg.
Konfiguration der experimentellen Umgebung
Die experimentelle Umgebung wurde eingerichtet, um die interoperable Plattform unter kontrollierten und reproduzierbaren Bedingungen zu evaluieren. Die Architektur umfasst Module für die Datenaufnahme, Interoperabilitätsebenen, große Sprachmodelle (LLMs) und Evaluierungskomponenten, die zu einer einzigen Verarbeitungspipeline für die Analyse medizinischer Daten zusammengefasst sind. Abbildung 1 veranschaulicht den gesamten Workflow, von der Aufnahme klinischer Daten bis hin zur Generierung diagnostischer Ergebnisse.

Abbildung 1: Übergreifender Systemarbeitsablauf, der die Verarbeitungspipeline von rohen klinischen Daten bis zur Ausgabe des Krankheitsstatus veranschaulicht. Der Prozess beginnt mit der Erfassung elektronischer Gesundheitsakten (EHR), gefolgt von einer Datenfilterung und -vorverarbeitung, um krankheitssensitive Informationen zu extrahieren. In einer Phase der strukturierten Prompt-Entwicklung werden Expertenwissen, Krankheitsdefinitionen und Hyperparameter integriert, um eine effektive Interaktion mit dem großen Sprachmodell (LLM) zu ermöglichen. Das LLM führt eine Textinferenz durch, um kontextbezogene Antworten zu generieren, die anschließend mithilfe klinischer Regeln bewertet werden, um den endgültigen Krankheitsstatus zu bestimmen. Der Arbeitsablauf verdeutlicht die Integration von Datenvorverarbeitung, wissensbasiertem Prompting und KI-gestützter Inferenz zur Unterstützung klinischer Entscheidungsfindung. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.
Architektur der Gesundheitsversorgungs-Interoperabilität
Die Backend-Infrastruktur verwendet eine modulare Architektur auf Basis von RESTful-APIs, um die Kommunikation zwischen den Plattformkomponenten zu unterstützen (Abbildung 2). Diese Architektur ermöglicht die Verarbeitung heterogener klinischer Informationen, einschließlich strukturierter Elektronischer Gesundheitsakten (EHRs), Arztnotizen und Metadaten aus medizinischen Bildgebungssystemen. Da diese Daten aus mehreren Quellen und Formaten stammen, wird Interoperabilität durch standardisierte Datenmodelle erreicht, insbesondere durch den Fast-Healthcare-Interoperability-Resources-(FHIR-)Standard15,16,17. Die Verwendung von FHIR unterstützt den Austausch strukturierter Informationen und bewahrt gleichzeitig Skalierbarkeit und Flexibilität in verteilten Gesundheitsumgebungen. HL7-basierte Kommunikationsmechanismen wurden ebenfalls integriert, um die Anbindung an bestehende klinische Systeme zu erleichtern, die nach wie vor in vielen Gesundheitseinrichtungen weit verbreitet sind16,17.

Abbildung 2: Systemarchitektur der vorgeschlagenen interoperablen Plattform. Die Web-Oberfläche kommuniziert über eine Flask-API mittels HTTP-POST/GET-Anfragen mit dem Backend. Die API übernimmt das Routing, die Abfrageverarbeitung sowie die Interaktion mit strukturierten und unstrukturierten Datenquellen. Eine MySQL-Datenbank speichert die strukturierten klinischen Daten, während ein auf FAISS basierender Vektor-Speicher die Ähnlichkeitssuche für Abrufoperationen unterstützt. Die auf LLaMA basierende Pipeline verarbeitet textuelle Eingaben und erzeugt Antworten mithilfe von Vektorrepräsentationen, wodurch Generierung mit Abrufunterstützung (Retrieval-Augmented Generation, RAG) ermöglicht wird. Die Architektur verdeutlicht die Integration von Webdiensten, Datenbankverwaltung, Vektorabruf und Inferenz großer Sprachmodelle in einem einheitlichen System. Bitte klicken Sie hier, um eine vergrößerte Darstellung dieser Abbildung anzusehen.
Konfiguration eines Multi-Agenten-Workflows
Die Multi-Agenten-Architektur ist in spezialisierte funktionale Agenten unterteilt, die für unterschiedliche Phasen des Arbeitsablaufs verantwortlich sind. Ein Vorverarbeitungs-Agent führt die Daten-Normalisierung und FHIR-Zuordnung durch, gefolgt von einem Abruf-Agenten, der für die semantische Suche innerhalb der Vektordatenbank zuständig ist. Ein Schlussfolgerungs-Agent integriert den abgerufenen Kontext mit dem LLM, um Antworten zu generieren, während ein Validierungs-Agent die Konsistenz und Formatierung der Ausgabe überprüft, bevor die endgültige Antwort zurückgegeben wird. Die Koordination der Agenten folgt einer sequenziellen Orchestrierungsstrategie, bei der die Ausgabe jedes Agenten als Eingabe für die nachfolgende Phase dient, um eine reproduzierbare und modulare Implementierung sicherzustellen.
Klinische Datenintegration
Die Datenebene zur Integration aggregiert Informationen aus mehreren klinischen Quellen und bereitet sie für die nachgeschaltete Verarbeitung auf. Die Vorverarbeitung umfasst die Normalisierung der Daten, die Tokenisierung und die Entitätsabstimmung, um die semantische Konsistenz über heterogene Datensätze hinweg zu verbessern. Da klinische Informationen in Struktur und Qualität variieren, tragen diese Schritte dazu bei, Störungen zu reduzieren und die Interaktion mit KI-Modellen zu erleichtern. Zudem wurden strukturierte Zuordnungsstrategien angewandt, um unterschiedliche Datenformate zu harmonisieren und die Kompatibilität mit der Verarbeitungspipeline sicherzustellen, wie in Abbildung 315,16,17 veranschaulicht.

Abbildung 3: Detailliertes Beispiel des klinischen Multi-Agenten-Schlussfolgerungsprozesses. Die Abbildung veranschaulicht, wie eine klinische Anfrage in mehreren Stufen analysiert wird, einschließlich der Bewertung der Komplexität, der Rekrutierung von Spezialisten, der kollaborativen Diskussion und der endgültigen Entscheidungsfindung. Dieser Prozess zeigt die Fähigkeit des Systems, Schlussfolgerungsstrategien dynamisch an die Komplexität der Anfrage anzupassen, wodurch sowohl die Effizienz als auch die diagnostische Genauigkeit in Szenarien der klinischen Entscheidungsunterstützung verbessert werden. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.
Konfigurieren der Retrieval-Augmented-Generation-Pipeline
Die Abrufverstärkte Generierung (Retrieval-Augmented Generation, RAG) wird integriert, um eine kontextbewusste Analyse zu ermöglichen, indem die Informationsabrufung mit den generativen Fähigkeiten großer Sprachmodelle kombiniert wird. Benutzeranfragen werden mithilfe von Embedding-Modellen in Vektorrepräsentationen umgewandelt und mittels semantischem Ähnlichkeitssuchverfahren mit der Vektordatenbank abgeglichen, um die relevantesten kontextuellen Textpassagen abzurufen. Die abgerufenen Dokumente werden anschließend vor der Inferenz durch das große Sprachmodell (LLM) mit der ursprünglichen Anfrage kombiniert. Diese Strategie trägt dazu bei, während der Antwortgenerierung kontextuelle Informationen bereitzustellen, und wurde mit verbesserter Faktentreue sowie einer Verringerung von Halluzinationen in wissensintensiven Anwendungen, einschließlich des Gesundheitswesens18,19., in Verbindung gebracht. Abbildung 1 und Abbildung 3 veranschaulichen den gesamten Abrufarbeitsablauf und den entsprechenden Schlussfolgerungsprozess.
Für jede Benutzeranfrage wird der endgültige Prompt dynamisch erstellt, indem die ursprüngliche Anfrage mit den relevantesten kontextuellen Passagen kombiniert wird, die aus der Vektordatenbank abgerufen wurden. Die abgerufenen Informationen werden als kontextuelle Belege vor der Inferenz eingefügt, wodurch das Sprachmodell Antworten erzeugen kann, die auf dem abgerufenen medizinischen Wissen basieren, wobei die semantische Konsistenz erhalten bleibt und unbegründete Aussagen reduziert werden.
Generierung von Prompts und mehrstufige Schlussfolgerungen
Das Protokoll beinhaltet strukturierte Aufforderungsstrategien, um die kontextuelle Interpretation während der Antwortgenerierung zu verbessern. Diese Aufforderungstechniken, zusammen mit fortschrittlichen Schlussfolgerungsmechanismen, unterstützen den Schlussfolgerungsprozess in komplexen klinischen Szenarien und entsprechen jüngsten Entwicklungen, die in der Literatur berichtet wurden20.
Die Architektur umfasst ein Multi-Agenten-Framework, das aus spezialisierten Modulen besteht, welche im Verarbeitungspipeline unterschiedliche Funktionen ausführen, darunter Datenvalidierung, Kontextfilterung, Unterstützung klinischer Schlussfolgerungen und Überprüfung der Ausgabe. Die modulare Organisation ermöglicht die sequenzielle oder parallele Ausführung von Aufgaben und bietet somit Flexibilität für verschiedene Verarbeitungsanforderungen (Abbildung 4). Die Verteilung dieser Aktivitäten auf mehrere Agenten verringert die Abhängigkeit von einem einzelnen Sprachmodell und unterstützt einen robusteren Verarbeitungsablauf. Diese architektonische Strategie entspricht aktuellen Entwicklungen im Bereich der verteilten künstlichen Intelligenz und des Designs intelligenter Systeme21,22.

Abbildung 4: Entscheidungsrahmen mit mehreren Agenten für klinisches Denken. Der Prozess beginnt mit einer Nutzeranfrage, die von einem Agentenprüfer bewertet wird, der für die Einschätzung der Komplexität der Anfrage zuständig ist. Bei komplexen Fällen rekrutiert das System dynamisch ein fachübergreifendes Team (MDT) spezialisierter Agenten, das mehrere Diskussionsrunden durchführt, um das Problem zu analysieren und Wissen zu integrieren, bevor eine endgültige Entscheidung getroffen wird. Einfachere Fälle werden von einem Hausarztagenten (PCC) bearbeitet, wodurch schnellere Antwortgenerierung ermöglicht wird. Diese adaptive Architektur sorgt für ein Gleichgewicht zwischen Effizienz und analytischer Tiefe und verbessert so die Entscheidungsqualität sowie die Skalierbarkeit des Systems in medizinischen Anwendungen. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.
Leistungsbeurteilung
Die Systemleistung wurde mithilfe komplementärer Metriken bewertet, die sowohl die sprachliche Qualität als auch die semantische Konsistenz der erzeugten Ausgaben erfassen. BLEU wurde angewandt, um die syntaktische Ähnlichkeit basierend auf dem Überlappungsgrad von n-Grammen zu messen23, während ROUGE Rückrufrate und Inhaltsabdeckung bewertete, insbesondere bei Aufgaben wie Textzusammenfassung und Informationsgewinnung24. Die semantische Ähnlichkeit wurde mit BERTScore analysiert, der kontextuelle Embeddings aus transformerbasierten Modellen nutzt, um erzeugte und Referenztexte zu vergleichen25. Zusätzliche Analysen umfassten die Perplexität und die Kosinus-Ähnlichkeit, um jeweils das Modellvertrauen und die semantische Kohärenz zu untersuchen26,27.
Die ausgewählten Evaluierungsmetriken bieten komplementäre Perspektiven auf die Systemleistung, indem sie lexikalische und semantische Analysen kombinieren. Diese Kombination ist besonders relevant für Anwendungen im Gesundheitswesen, bei denen die kontextuelle Interpretation ebenso wichtig ist wie die lexikalische Ähnlichkeit. Die Plattform wurde in einer kontrollierten rechnergestützten Umgebung evaluiert, die sowohl cloudbasierte als auch lokale Bereitstellung unterstützt. Die lokale Ausführung von LLMs wurde als Option einbezogen, um die Anforderungen an den Datenschutz zu erfüllen und die Abhängigkeit von externen Diensten bei der Verarbeitung sensibler klinischer Informationen zu verringern. Diese Bereitstellungsstrategie ist mit Datenschutzrahmenwerken kompatibel und kann an verschiedene betriebliche Umgebungen angepasst werden4.