Atomic Workspace: Eine agentische KI-Plattform für FHIR-native klinische App-Entwicklung in einer Digital-Twin-Umgebung

Zusammenfassung

In den meisten Gesundheitsorganisationen können diejenigen, die wissen, was gebaut werden muss, es nicht selbst bauen — und diejenigen, die es könnten, sind stets Monate entfernt. Jedes Werkzeug, das die Versorgung verbessern oder eine Workflow-Lücke schließen könnte, bleibt zwischen diesen beiden Gruppen stecken.

Atomic Workspace schließt diese Lücke. Es ist eine KI-Plattform, auf der klinische Teams Healthcare-Anwendungen entwerfen, entwickeln und bereitstellen — ohne einen traditionellen Entwicklungszyklus. Kliniker, Designer, Entwickler und KI-Agenten arbeiten alle im selben Bereich. Kliniker beschreiben, was sie benötigen, und genehmigen das Ergebnis. KI-Agenten übernehmen die Entwicklung. Und wenn etwas Kompliziertes auftaucht — eine komplexe Integration, ein Sonderfall — kann ein Entwickler einspringen, ohne den Faden zu verlieren, den das Team bereits gesponnen hat. Jedes Projekt läuft in einem Digital Twin der Produktionsumgebung, der auf einem FHIR-Server basiert, sodass Teams vom ersten Tag an gegen reale Datenstrukturen entwickeln und testen.

Erste Pilot-Ergebnisse:

• Klinische Anforderung bis zum funktionierenden Prototyp: 1–2 Tage (vs. 3–6 Monate)
• Validierter Prototyp bis zur Produktion: 2–4 Wochen (vs. 6–18 Monate)
• Klinische Teams liefern 10-mal mehr Apps pro Jahr ohne zusätzliche Entwickler

Das Problem

Die Entwicklung eines klinischen Werkzeugs erfordert zwei Arten von Wissen, die selten in derselben Person vereint sind: klinische Expertise und Software-Engineering. Diesen Graben zu überbrücken ist kostspielig.

Jede Anforderung muss erklärt, präzisiert und interpretiert werden. Jede Designentscheidung erfordert eine Feedbackschleife. Jede Iteration bedeutet eine weitere Runde der Übersetzung — von dem, was der Kliniker braucht, zu dem, was der Entwickler verstanden hat, zu dem, was tatsächlich gebaut wurde. Jeder Schritt kostet Zeit, und jeder Schritt führt zu Verzerrungen.

Wenn ein Werkzeug schließlich fertiggestellt ist, sind Monate vergangen und erhebliche Budgets verbraucht worden — nicht für die Entwicklung, sondern für die Kommunikation. Und oft passt das Gelieferte immer noch nicht ganz.

Teams helfen sich daher mit Tabellenkalkulationen, Workarounds und Papierformularen. Sie hören auf, Werkzeuge anzufordern, die sie brauchen, weil die Kosten des Nachfragens zu hoch sind. Und die Lücke zwischen dem, was klinische Teams haben, und dem, was sie tatsächlich benötigen, wird immer größer.

Was bereits versucht wurde

Allgemeine KI-Entwicklungswerkzeuge

Allgemeine KI-Coding-Plattformen — Assistenten, Agenten-Frameworks und Low-Code-Builder, die nicht für das Gesundheitswesen konzipiert sind — bieten Geschwindigkeit. In einem Healthcare-Kontext erzeugen sie jedoch neue Probleme.

Sie verfügen über kein eingebautes Healthcare-Domänenwissen. Sie generieren Code ohne Kenntnis der FHIR-Ressourcensemantik, klinischer Datenstandards oder der Einschränkungen von EHR-Umgebungen. Jedes Projekt erfordert erheblichen Anpassungsaufwand, um Ergebnisse zu erzielen, die den Anforderungen an die Interoperabilität im Gesundheitswesen gerecht werden. Die Integrationsaufgabe — die Anbindung von Apps an EHR-Systeme, die Handhabung der SMART-Autorisierung, das Mapping auf FHIR-Ressourcen — fällt dem Entwicklungsteam zu, nicht der Plattform.

Diese Werkzeuge beschleunigen Entwickler. Sie beseitigen die Abhängigkeit von Entwicklern nicht.

Healthcare-native App-Plattformen

Die dem Atomic Workspace nächste Kategorie. Einige Plattformen ermöglichen es klinischen Teams, mit KI-Unterstützung maßgeschneiderte Healthcare-Werkzeuge zu entwickeln — Formulare, Dashboards, Portale, Workflows. Sie sind schnell und wurden mit Blick auf die Healthcare-Compliance entwickelt.

Die zentrale Einschränkung ist die Interoperabilität. Diese Plattformen liegen als Frontend-Schicht über dem EHR — sie sind nicht FHIR-nativ. Jede Bereitstellung in einer neuen EHR-Umgebung erfordert individuelle Integrationsarbeit. Die erfassten Daten sind nicht nativ FHIR-strukturiert, was zu Reibungsverlusten führt, wenn sie in klinische Systeme zurückfließen müssen.

FHIR-native Entwicklerplattformen

Einige Plattformen sind genuinen FHIR-nativ — sie lösen das Problem der Standards und Interoperabilität gut. Aber sie sind für Entwickler konzipiert, nicht für klinische Teams. Ein Kliniker kann immer noch nicht einen Workflow-Bedarf beschreiben und daraus eine funktionierende App entstehen lassen. Die Abhängigkeit vom Engineering bleibt bestehen.

Der Atomic-Workspace-Ansatz

Atomic Workspace basiert auf vier Entscheidungen, die das Problem direkt adressieren.

1. FHIR als Betriebsschicht

In Atomic Workspace ist FHIR keine Integrationsschicht. Es ist das zentrale Datenmodell, auf dem die gesamte Plattform basiert. KI-Agenten arbeiten direkt mit FHIR-Ressourcen. Die Digital-Twin-Umgebung betreibt einen Live-FHIR-Server. Jede produzierte App ist eine SMART on FHIR-Anwendung, die über das SMART App Launch Framework mit jedem FHIR-konformen EHR kompatibel ist — ohne Custom-Connectoren, herstellerspezifische Middleware oder integrationsspezifischen Aufwand pro Bereitstellung.

Die Plattform geht über Basis-FHIR hinaus: Sie integriert das HL7 SDC IG für strukturierte klinische Formulare und Fragebögen, SQL on FHIR für Analytik und Reporting, FHIR-Schema-Validierung in jeder Phase sowie einen integrierten Terminology-Service (SNOMED CT, LOINC und andere), der KI-Agenten als Kommandozeilen-Tools zur Verfügung steht, sodass klinische Codes zum Zeitpunkt der Code-Generierung aufgelöst werden.

Dies bedeutet, dass jede auf Atomic Workspace entwickelte App durch ihre Konstruktion interoperabel ist — nicht durch Konfiguration.

2. Eine Digital-Twin-Entwicklungsumgebung

Jedes Projekt in Atomic Workspace läuft in einem isolierten Digital Twin der klinischen Produktionsumgebung. Der Digital Twin umfasst ein Virtual FHIR CDR (Clinical Data Repository mit EHR-Simulation), eine Workflow-Engine (Temporal) und ein Virtual Portal. KI-Agenten und klinische Teams entwickeln und testen gegen dieselben Datenstrukturen und dasselbe Serviceverhalten, auf das sie in der Produktion treffen werden.

Dies eliminiert die häufigste Ursache für Fehler nach der Bereitstellung in Healthcare-Software: die Diskrepanz zwischen dem, was die Entwicklungsumgebung angenommen hat, und der tatsächlichen Produktionsrealität. Wenn eine App im Digital Twin funktioniert, funktioniert sie im EHR.

3. Spezifikationsgetriebene Entwicklung

Atomic Workspace kehrt die traditionelle Entwicklungsübergabe um. Jede Entwicklung beginnt mit einer strukturierten Spezifikation, die der KI-Analyst aus klinischen Anforderungen generiert, die vom klinischen Team geprüft und genehmigt wird, bevor ein einzige Zeile Code geschrieben wird. Die genehmigte Spezifikation konfiguriert dann die Digital-Twin-Umgebung, definiert die Testsuite und regelt, was KI-Agenten über den gesamten Lebenszyklus hinweg entwickeln.

Die klinische Intention wird als verifizierbares Artefakt kodiert — sie wird nicht während der Entwicklung interpretiert und nicht nachträglich rekonstruiert. Das macht es möglich, dass Kliniker am Entwicklungsprozess teilnehmen, ohne Code schreiben zu müssen: Sie genehmigen keine technischen Ausgaben, sondern eine Spezifikation, die in für sie verständlichen Begriffen verfasst ist.

4. Kollaboration als Grundprinzip

Atomic Workspace ist von Grund auf als gemeinsame Umgebung konzipiert. Kliniker, Designer, Entwickler, Analysten und KI-Agenten arbeiten gleichzeitig im selben Workspace — mit denselben Anforderungen, demselben Build-Status und denselben Validierungsergebnissen. Entwickler können in jeder Phase eines aktiven Projekts einsteigen, um einen technischen Sonderfall zu lösen, ohne den Faden zu verlieren, den das klinische Team bereits gesponnen hat.

Human-in-the-Loop-Kontrollpunkte sind bei der Spezifikationsgenehmigung, der klinischen Validierung und der Freigabe durch die Stakeholder fest in den Workflow integriert. KI-Agenten agieren zwischen diesen Kontrollpunkten. Kein Projekt gelangt ohne klinische Freigabe und Stakeholder-Genehmigung in die Produktion.

So funktioniert es

Ein Projekt in Atomic Workspace durchläuft einen definierten Lebenszyklus, wobei KI-Agenten die Ausführung übernehmen und die klinischen Beteiligten die Entscheidungen treffen.

1. Erfassen Ein Kliniker oder ein Versorgungsteam beschreibt einen Workflow-Bedarf in seiner eigenen Sprache. Der KI-Analyst führt einen strukturierten Dialog, um Anforderungen, Sonderfälle und Rahmenbedingungen zu ermitteln. Kein technisches Wissen erforderlich.

2. Spezifizieren Der KI-Analyst wandelt die erfassten Anforderungen in eine strukturierte Spezifikation um: Datenmodell, Workflow-Logik, Validierungsregeln und Abnahmekriterien. Das klinische Team prüft und genehmigt die Spezifikation, bevor Code generiert wird.

3. Konfigurieren Die genehmigte Spezifikation konfiguriert die Digital-Twin-Umgebung des Projekts — sie instanziiert die FHIR-Ressourcen, Workflow-Definitionen und Test-Fixtures, gegen die die App entwickelt wird.

4. Entwickeln KI-Entwickleragenten generieren die Anwendung — Backend und Frontend — und zielen dabei auf die FHIR-nativen APIs des Digital Twins ab. Integrierte Skills (SDC, UI, Analytics, Terminology) fungieren als Leitplanken und beschränken die KI-Ausgaben auf FHIR-konforme, klinisch fundierte Muster.

5. Testen Automatisierte Test-Agenten validieren die Anwendung gegen den Digital Twin und prüfen FHIR-Konformität, Workflow-Korrektheit und Abnahmekriterien aus der Spezifikation.

6. Validieren Das klinische Team interagiert mit der funktionierenden Anwendung innerhalb des Digital Twins — derselben Umgebung, in der sie nach der Bereitstellung läuft. Feedback fließt zurück in den Workspace zur Iteration.

7. Bereitstellen Nach der Freigabe durch die Stakeholder wird die App als SMART on FHIR-Anwendung bereitgestellt und startet direkt innerhalb des FHIR-konformen EHR der Organisation. Keine Bereitstellungsinfrastruktur zu entwickeln, keine Integrationsarbeit zu leisten.

Eine einzelne Atomic-Workspace-Instanz verwaltet eine beliebige Anzahl gleichzeitiger Projekte — jedes in einer vollständig isolierten Umgebung. Dies bedeutet, dass mehrere klinische Teams gleichzeitig entwickeln können, ohne sich gegenseitig zu beeinflussen, und die Daten, der Code sowie der Agenten-Kontext jedes Projekts vollständig getrennt bleiben. Abbildung 1 veranschaulicht diese Multi-Projekt-Architektur.

Jede Projektumgebung ist keine generische Sandbox — sie ist ein strukturierter Digital Twin mit drei verschiedenen Schichten, die zusammenwirken. Abbildung 2 zeigt die interne Architektur eines einzelnen Projekts: links der Digital Twin der Produktionsdienste (FHIR CDR, Workflow-Engine, Virtual Portal); in der Mitte die Anwendungscodebase und -laufzeit; rechts die KI-Copilot-Schicht mit Coding-Agenten, die über das ACP-Protokoll agieren und durch eine integrierte Skills-und-Wissens-Schicht geleitet werden, die die KI-Ausgaben auf FHIR-konforme, klinisch fundierte Muster beschränkt.

Technische Grundlage

Infrastruktur und Stack

Atomic Workspace basiert auf Aidbox, einer FHIR-Server-Plattform. Jedes Projekt läuft in einem isolierten Docker-Container, verwaltet über Multibox — Aidboxs Multi-Tenant-Schicht —, die die Bereitstellung und Datenisolierung über Projekte hinweg übernimmt.

HL7-Standards

Bereitstellung

Atomic Workspace unterstützt Cloud-, On-Premise- und Hybrid-Bereitstellung. Organisationen mit Anforderungen an die Datenresidenz oder Netzwerkisolierung können die gesamte Plattform innerhalb ihrer eigenen Infrastruktur betreiben. SMART on FHIR-Apps werden ohne zielspezifischen Integrationsaufwand für Epic, Cerner und andere FHIR-konforme EHR-Systeme bereitgestellt.

Sicherheit und Compliance

Datenisolierung und Autorisierung

Jedes Projekt läuft in einer isolierten Digital-Twin-Umgebung. Entwicklung und Tests verwenden standardmäßig synthetische oder de-identifizierte Daten. Produktionsbereitstellungen erfolgen unter entsprechenden BAAs mit Partnern aus dem Gesundheitswesen. Alle Plattformzugriffe nutzen unternehmenstaugliche Authentifizierung mit rollenbasierter Zugriffskontrolle sowohl auf Plattform- als auch auf Anwendungsebene.

Alle von der Plattform produzierten Apps verwenden das SMART-Autorisierungsframework für die Zugangskontrolle und entsprechen damit den CMS-Interoperabilitätsregeln und den ONC-Zertifizierungsanforderungen für EHR-integrierte Anwendungen.

Human-in-the-Loop durch Design

Obligatorische menschliche Validierungskontrollpunkte sind bei der Spezifikationsgenehmigung, der klinischen Validierung und der Stakeholder-Freigabe fest in den Workflow integriert. KI-Agenten agieren zwischen diesen Kontrollpunkten, können ein Projekt jedoch nicht ohne klinische und Stakeholder-Autorisierung in die Produktion überführen. KI-generierter Code, Spezifikationen und Testergebnisse sind im Workspace vollständig einsehbar und überprüfbar. Klinische und technische Beteiligte können KI-Ausgaben in jeder Phase einsehen, modifizieren und überschreiben.

Regulatorische Haltung

Apps, die von Atomic Workspace produziert werden und in den Anwendungsbereich von Software as a Medical Device (SaMD) fallen, erfordern eine separate regulatorische Überprüfung. Die Plattform stellt die Entwicklungs- und Integrationsinfrastruktur bereit; sie ersetzt nicht den Prozess der klinischen Validierung und regulatorischen Zulassung für Werkzeuge, die klinische Entscheidungen treffen oder beeinflussen.

Das wirtschaftliche Argument

Die Wirtschaftlichkeit

Atomic Workspace zielt nicht darauf ab, Entwickler zu ersetzen. Es geht darum, zu verändern, wofür Entwickler eingebunden werden müssen.

Heute erfordert jede klinische App vollständiges Engineering-Engagement — von den Anforderungen über Design, Entwicklung, Testing bis zur Bereitstellung. Das Entwicklungsteam ist für jedes Projekt der Engpass, unabhängig von der Komplexität. Organisationen erhöhen den Personalbestand, um die Kapazität zu steigern, aber die Kosten jeder zusätzlichen App bleiben hoch.

Atomic Workspace verändert dieses Verhältnis. KI-Agenten übernehmen die Ausführung. Entwickler steigen ein, wo echte technische Tiefe erforderlich ist — komplexe Integrationen, Sonderfälle, Performance-Optimierung. Das Ergebnis ist, dass ein Team einer gegebenen Größe deutlich mehr Projekte pro Jahr unterstützen kann.

Kostenmodell

Die Plattformkosten sind primär fixe Infrastrukturkosten, die sich über Projekte amortisieren. Sobald die Plattform bereitgestellt und die initiale Skills-Bibliothek etabliert ist, sinken die Grenzkosten jeder zusätzlichen App. Organisationen, die eine Bibliothek institutioneller Skills aufbauen — in der ihre eigenen Workflows, klinischen Regeln und Datenmuster kodiert sind — verzeichnen weitere Kostensenkungen, da jedes neue Projekt auf einem reichhaltigeren Fundament startet.

Entwickeln vs. Kaufen

Für Healthcare-IT-Organisationen, die zwischen Eigenentwicklung und Kauf abwägen:

Eine maßgeschneiderte KI-Entwicklungsplattform zu entwickeln erfordert tiefes FHIR-Fachwissen, Multi-Agenten-Orchestrierungsinfrastruktur, in die Toolchain integriertes klinisches Domänenwissen und laufende Wartung, wenn sich Standards weiterentwickeln. Dies ist eine mehrjährige, mehrere Millionen Dollar umfassende Investition mit erheblichem laufendem operativem Aufwand.

Allgemeine Werkzeuge für das Gesundheitswesen anzupassen verlagert die Integrations- und Compliance-Last auf jedes einzelne Projekt. Jede App wird zu einer individuellen Integrationsübung. Die Plattform akkumuliert mit der Zeit kein klinisches Wissen oder keine Standardsausrichtung.

Atomic Workspace startet mit dem bereits vorhandenen Healthcare-spezifischen Fundament — FHIR-nativ, standardskonform, EHR-bereit. Die Skills-Bibliothek wächst mit jedem Projekt, sodass die Plattform mit der Zeit nützlicher wird, nicht weniger.

Beispielhafte Anwendungsfälle

Erfassung patientenberichteter Ergebnisse (PROMs)

Das Problem Ein Versorgungsteam, das postoperative Patienten betreut, muss standardisierte Ergebnis-Scores (KOOS, HOOS, PROMIS) in definierten Intervallen erheben. Derzeit geschieht dies über Papierformulare oder manuelle Telefongespräche — die Daten landen in eingescannten PDFs oder unstrukturierten Notizen, nicht im EHR.

Die Entwicklung Ein klinischer Analyst beschreibt dem KI-Analysten die Anforderung: spezifische PROMs 2 Wochen, 6 Wochen und 3 Monate nach der Operation zu erheben, verknüpft mit dem CarePlan des Patienten im EHR. Der KI-Analyst überführt dies in eine strukturierte Spezifikation unter Verwendung von HL7 SDC IG Questionnaire-Ressourcen für jedes Ergebnisinstrument.

Der KI-Entwickler generiert eine patientenseitige SMART on FHIR-App, die Patienten zum geeigneten Zeitpunkt einen sicheren Link zusendet. Patienten füllen das Formular auf jedem Gerät aus; die Antworten werden als FHIR-QuestionnaireResponse-Ressourcen gespeichert, mit dem ursprünglichen CarePlan verknüpft und sind sofort im EHR verfügbar.

Für Patienten, die eine Sprachinteraktion bevorzugen, unterstützt derselbe Workflow einen KI-Sprachanruf: Ein KI-Agent liest die Fragebogenitems vor, erfasst Antworten per Sprache und ordnet sie den entsprechenden FHIR-QuestionnaireResponse-Feldern zu.

Das Ergebnis Strukturierte, kodierte Ergebnisdaten fließen direkt in den FHIR-Datenspeicher — keine manuelle Übertragung, keine unstrukturierten Notizen. Das Versorgungsteam erhält einen vollständigen longitudinalen Überblick über patientenberichtete Ergebnisse, ohne die bevorzugte Interaktionsweise der Patienten zu verändern.

Demonstrierte Plattformfähigkeiten: SDC IG Questionnaire/QuestionnaireResponse, patientenseitige SMART on FHIR-App, Terminology-Service, KI-Sprachintegration, CarePlan-Verknüpfung.

Klinisches Analytics-Dashboard via natürlicher Sprache

Das Problem Eine klinische Betriebsleiterin möchte Wiederaufnahmeraten, Verweildauer und Medikamenten-Adhärenz für eine Patientenkohorte nachverfolgen — hat jedoch keine Engineering-Unterstützung und kann nicht warten, bis ein BI-Team die Anfrage priorisiert.

Die Entwicklung Die Analystin öffnet ein neues Projekt in Atomic Workspace und beschreibt das Dashboard in natürlicher Sprache: welche Patientenpopulation, welche Metriken, welche Zeitfenster und wie die Ergebnisse dargestellt werden sollen. Kein SQL- oder FHIR-Abfragewissen erforderlich.

Der KI-Analyst erstellt eine Spezifikation, die jede Metrik den relevanten FHIR-Ressourcen (Encounter, MedicationRequest, Observation) zuordnet und die SQL on FHIR-Abfragen definiert, die das Dashboard antreiben werden. Nach der Genehmigung der Spezifikation durch die Analystin generieren KI-Entwickleragenten die Dashboard-Anwendung — eine SMART on FHIR-App, die den FHIR-Server mit SQL on FHIR abfragt und Ergebnisse in einer interaktiven Oberfläche darstellt.

Die Analystin kann das Dashboard durch Folge-Chat verfeinern: „Filter für Primärdiagnose hinzufügen", „Trendlinien für die letzten 90 Tage anzeigen", „nach behandelndem Arzt aufschlüsseln". Jede Anfrage wird in eine Spezifikationsaktualisierung übersetzt und von KI-Agenten umgesetzt.

Das Ergebnis Ein voll funktionsfähiges klinisches Analytics-Dashboard, im EHR bereitgestellt, ohne Engineering-Beteiligung entwickelt — von der Beschreibung zur funktionierenden App in weniger als einem Tag.

Demonstrierte Plattformfähigkeiten: SQL on FHIR, Analytics-Skills, natürlichsprachige Spezifikationsgenerierung, SMART on FHIR-App-Ausgabe, iterative KI-gesteuerte Verfeinerung.

Entscheidungsservice für Vorautorisierungen

Das Problem Die Vorautorisierung ist einer der arbeitsintensivsten Prozesse im Gesundheitswesen. Pflegekräfte im Utilization Management (UM) prüfen manuell Anspruchsberechtigung, Deckungsregeln und medizinische Notwendigkeitskriterien für jeden Autorisierungsantrag — sie arbeiten sich durch umfangreiche Tabellen mit Abrechnungscodes, navigieren auf CMS-Websites zu LCD/NCD-Kriterien (Local and National Coverage Determination) und führen mehrere Gespräche mit Leistungserbringern, um klinische Dokumentation zu sammeln. Der Prozess dauert Stunden pro Fall.

Das Kernproblem ist, dass Deckungsregeln als unstrukturierter Text auf CMS-Websites und in internen Tabellen existieren — nicht als maschinenlesbare Logik. Jeder Kostenträger hat leicht unterschiedliche Regeln. Es gibt keinen Standardweg, diese zu kodieren, zu pflegen oder automatisch auszuführen.

Die Entwicklung Auf Atomic Workspace arbeitet eine Utilization-Management-Spezialistin (UM) — eine klinisch ausgebildete Mitarbeiterin, die für Deckungsentscheidungen zuständig ist und typischerweise keinen technischen Hintergrund hat — mit dem KI-Analysten zusammen, um Deckungsregeln für eine bestimmte Geschäftslinie zu definieren — beginnend beispielsweise mit Häuslichem Sauerstoff (Medicare LCD L33797). Die Plattform enthält eine integrierte Wissensdatenbank, die aus Medicare LCD/NCD-Dokumenten gespeist wird: von CMS-Websites gescraped, strukturiert und indexiert sowie KI-Agenten über Such- und Ähnlichkeitsabfragen zur Verfügung gestellt.

Der KI-Agent nutzt diese Wissensdatenbank, um die relevanten medizinischen Notwendigkeitskriterien zu extrahieren, eine FHIR-Questionnaire-Ressource zu generieren, die die erforderlichen klinischen Nachweise erfasst, und die Deckungslogik als strukturierte Entscheidungsregel zu kodieren. Die UM-Spezialistin prüft und verfeinert die Ausgabe — ohne Programmierkenntnisse.

Das Ergebnis ist ein Entscheidungsservice: eine standardsbasierte Komponente, die eine CDS-Hooks-Anfrage vom EHR entgegennimmt, wenn ein vorautorisierungspflichtiger Eingriff angeordnet wird, die geltenden Deckungsregeln gegen den FHIR-Datensatz des Patienten auswertet und mit einer Entscheidung antwortet — automatisch genehmigt (für Gold-Card-Anbieter oder klar anspruchsberechtigte Fälle) oder mit einem Link zum generierten FHIR-Questionnaire für den Kliniker zur Vervollständigung.

Der gesamte Service wird als Template-Projekt in Atomic Workspace entwickelt und ist mit organisationsspezifischen Regelsets, die auf dem gemeinsamen Framework aufbauen, für mehrere Kostenträgerorganisationen bereitstellbar.

Das Ergebnis Routinemäßige Vorautorisierungsentscheidungen werden automatisch am Punkt der Anordnung verarbeitet — ohne Einbeziehung von UM-Pflegekräften. Komplexe oder Ausnahmefälle werden zur menschlichen Überprüfung weitergeleitet, wobei die relevanten klinischen Nachweise bereits zusammengestellt sind. Deckungsregeln werden direkt von UM-Spezialistinnen und -Spezialisten gepflegt, ohne Entwicklerbeteiligung, und bei Änderungen der LCD/NCD-Kriterien aktualisiert.

Für Kostenträger ersetzt dies einen manuellen, fehleranfälligen Prozess durch eine prüfbare, standardsbasierte Automatisierung, die in Wochen statt den Monaten und sechsstelligen Kosten traditioneller Policy-Management-Tools entwickelt wird.

Demonstrierte Plattformfähigkeiten: CDS-Hooks-Integration, FHIR-Questionnaire-Generierung, Medicare LCD/NCD-Wissensdatenbank, KI-gestützte Deckungsregelentwicklung durch nicht-technisches Personal, templatebasierte Multi-Tenant-Bereitstellung.

Erste Erkenntnisse

Atomic Workspace befindet sich derzeit in einem aktiven Pilotbetrieb mit einem klinischen Team. Die Digital-Twin-Umgebung ist live und in Betrieb; reale Projektentwicklung und klinische Validierung sind im Gange.

Die folgenden Benchmarks basieren auf frühen Pilot-Beobachtungen und werden im Rahmen des laufenden Piloten formal validiert:

Erste Schritte

Atomic Workspace ist für den Pilotbetrieb mit Healthcare-IT-Organisationen und ihren klinischen Partnern verfügbar.

Die Plattform unterstützt Cloud-, On-Premise- und Hybrid-Bereitstellung. Pilotengagements beginnen mit einem definierten klinischen Anwendungsfall und enden mit einer im EHR bereitgestellten funktionierenden App.

Für die Besprechung eines Piloten oder einer technischen Evaluierung: Kontakt: mary@health-samurai.io

Plattformressourcen:

• Sandbox-Umgebung für technische Evaluierung verfügbar
• Architekturdokumentation und Integrationsleitfäden auf Anfrage verfügbar

---

Atomic Workspace wird von Health Samurai entwickelt, dem Team hinter der Aidbox FHIR-Plattform.