Atomic Workspace : Une plateforme d'IA agentique pour le développement d'applications cliniques FHIR-natives dans un environnement de jumeau numérique

Sommaire exécutif

Dans la plupart des organisations de santé, les personnes qui savent ce qu'il faut construire ne peuvent pas le construire — et celles qui le peuvent sont toujours à plusieurs mois de distance. Chaque outil susceptible d'améliorer les soins ou de combler un manque dans les flux de travail se retrouve bloqué entre les deux.

Atomic Workspace comble cet écart. Il s'agit d'une plateforme d'IA où les équipes cliniques conçoivent, construisent et déploient des applications de santé — sans cycle de développement traditionnel. Les cliniciens, les concepteurs, les développeurs et les agents d'IA travaillent tous dans le même espace. Les cliniciens décrivent ce dont ils ont besoin et approuvent le résultat. Les agents d'IA se chargent de la construction. Et si quelque chose de complexe survient — une intégration délicate, un cas limite — un développeur peut intervenir sans perdre le fil de ce que l'équipe a déjà bâti. Chaque projet s'exécute dans un jumeau numérique de l'environnement de production, fondé sur un serveur FHIR, de sorte que les équipes construisent et testent contre de vraies structures de données dès le premier jour.

Résultats préliminaires du projet pilote :

• De l'exigence clinique au prototype fonctionnel : 1 à 2 jours (contre 3 à 6 mois)
• Du prototype validé à la production : 2 à 4 semaines (contre 6 à 18 mois)
• Les équipes cliniques déploient 10 fois plus d'applications par année sans ajouter d'ingénieurs

Le problème

Construire un outil clinique exige deux types de connaissances qui coexistent rarement chez la même personne : l'expertise clinique et le génie logiciel. Les réunir est coûteux.

Chaque exigence doit être expliquée, clarifiée et interprétée. Chaque décision de conception nécessite une boucle de rétroaction. Chaque itération signifie un nouveau cycle de traduction — de ce dont le clinicien a besoin, à ce que le développeur a compris, à ce qui a finalement été construit. Chaque étape prend du temps, et chaque étape introduit de la distorsion.

Au moment où un outil est livré, des mois se sont écoulés et un budget considérable a été engagé — non pas pour construire, mais pour communiquer. Et souvent, ce qui est livré ne convient toujours pas tout à fait.

Les équipes se débrouillent alors avec des tableurs, des solutions de contournement et des formulaires papier. Elles cessent de demander les outils dont elles ont besoin parce que le coût de la demande est trop élevé. Et l'écart entre ce que les équipes cliniques possèdent et ce dont elles ont réellement besoin ne cesse de s'élargir.

Ce qui a déjà été essayé

Outils de développement IA à vocation générale

Les plateformes de codage IA à vocation générale — assistants, cadres d'agents et constructeurs à faible code non conçus pour la santé — offrent de la rapidité. Mais ils créent de nouveaux problèmes dans un contexte de santé.

Ils ne disposent d'aucune connaissance intégrée du domaine de la santé. Ils génèrent du code sans tenir compte de la sémantique des ressources FHIR, des normes de données cliniques ni des contraintes des environnements de DSE. Chaque projet nécessite un travail d'adaptation important pour produire des résultats conformes aux exigences d'interopérabilité en santé. Le fardeau d'intégration — connexion des applications aux systèmes DSE, gestion de l'autorisation SMART, correspondance avec les ressources FHIR — repose sur l'équipe de développement, non sur la plateforme.

Ces outils accélèrent les développeurs. Ils ne suppriment pas la dépendance envers les développeurs.

Plateformes d'applications natives en santé

La catégorie la plus proche d'Atomic Workspace. Certaines plateformes permettent aux équipes cliniques de construire des outils de santé personnalisés avec l'aide de l'IA — formulaires, tableaux de bord, portails, flux de travail. Elles sont rapides et conçues en tenant compte de la conformité en matière de santé.

La limitation fondamentale est l'interopérabilité. Ces plateformes se superposent au DSE comme couche frontale — elles ne sont pas FHIR-natives. Chaque déploiement dans un nouvel environnement DSE exige un travail d'intégration sur mesure. Les données qu'elles saisissent ne sont pas structurées nativement en FHIR, ce qui crée des frictions en aval lorsqu'elles doivent retourner dans les systèmes cliniques.

Plateformes de développement FHIR-natives

Certaines plateformes sont véritablement FHIR-natives — elles résolvent bien les problèmes de normes et d'interopérabilité. Mais elles sont conçues pour les développeurs, non pour les équipes cliniques. Un clinicien ne peut toujours pas décrire un besoin de flux de travail et le voir se transformer en application fonctionnelle. La dépendance envers l'ingénierie ne disparaît pas.

L'approche d'Atomic Workspace

Atomic Workspace repose sur quatre décisions qui s'attaquent directement au problème.

1. FHIR comme couche opérationnelle

Dans Atomic Workspace, FHIR n'est pas une couche d'intégration. C'est le modèle de données central sur lequel fonctionne l'ensemble de la plateforme. Les agents d'IA travaillent directement avec les ressources FHIR. L'environnement de jumeau numérique fait tourner un serveur FHIR en direct. Chaque application produite est une application SMART on FHIR, compatible avec tout DSE conforme à FHIR via le cadre SMART App Launch — sans connecteurs personnalisés, sans intergiciel spécifique à un fournisseur ni travail d'intégration par déploiement.

La plateforme va au-delà du FHIR de base : elle intègre l'HL7 SDC IG pour les formulaires cliniques structurés et les questionnaires, SQL on FHIR pour l'analytique et la production de rapports, la validation de schéma FHIR à chaque étape, ainsi qu'un service Terminology intégré (SNOMED CT, LOINC et autres) accessible aux agents d'IA en tant qu'outils en ligne de commande, de sorte que les codes cliniques sont résolus au moment de la génération du code.

Cela signifie que chaque application construite sur Atomic Workspace est interopérable par conception — et non par configuration.

2. Un environnement de développement en jumeau numérique

Chaque projet dans Atomic Workspace s'exécute dans un jumeau numérique isolé de l'environnement clinique de production. Le jumeau numérique comprend un CDR FHIR virtuel (dépôt de données cliniques avec simulation DSE), un moteur de flux de travail (Temporal) et un portail virtuel. Les agents d'IA et les équipes cliniques construisent et testent contre les mêmes structures de données et le même comportement de service qu'ils rencontreront en production.

Cela élimine la source la plus courante d'échecs après déploiement dans les logiciels de santé : l'écart entre ce que l'environnement de développement supposait et ce que la réalité de la production s'est avérée être. Quand une application fonctionne dans le jumeau numérique, elle fonctionne dans le DSE.

3. Développement piloté par les spécifications

Atomic Workspace inverse le transfert de développement traditionnel. Chaque construction commence par une spécification structurée générée par l'analyste IA à partir des exigences cliniques, examinée et approuvée par l'équipe clinique avant qu'une seule ligne de code ne soit écrite. La spécification approuvée configure ensuite l'environnement de jumeau numérique, définit la suite de tests et régit ce que les agents d'IA construisent tout au long du cycle de vie.

L'intention clinique est encodée comme un artefact vérifiable — elle n'est pas interprétée pendant le développement ni reconstituée après coup. C'est ce qui permet aux cliniciens de participer à la construction sans écrire de code : ils n'approuvent pas des sorties techniques, ils approuvent une spécification rédigée dans des termes qu'ils comprennent.

4. Collaboratif par conception

Atomic Workspace est conçu comme un environnement partagé dès le départ. Les cliniciens, les concepteurs, les développeurs, les analystes et les agents d'IA travaillent dans le même espace de travail simultanément — ils voient les mêmes exigences, le même état de construction, les mêmes résultats de validation. Les développeurs peuvent intervenir dans n'importe quel projet actif à n'importe quelle étape pour résoudre un cas limite technique sans perdre le fil de ce que l'équipe clinique a déjà construit.

Des points de contrôle avec intervention humaine sont intégrés au flux de travail lors de l'approbation de la spécification, de la validation clinique et de l'approbation des parties prenantes. Les agents d'IA opèrent entre ces points de contrôle. Aucun projet n'atteint la production sans l'approbation clinique et celle des parties prenantes.

Comment ça fonctionne

Un projet dans Atomic Workspace suit un cycle de vie défini, avec des agents d'IA qui pilotent l'exécution et des participants cliniques qui contrôlent les décisions.

1. Saisie Un clinicien ou une équipe de soins décrit un besoin de flux de travail dans son propre langage. L'analyste IA engage un dialogue structuré pour faire émerger les exigences, les cas limites et les contraintes. Aucune connaissance technique requise.

2. Spécification L'analyste IA convertit les exigences saisies en une spécification structurée : modèle de données, logique de flux de travail, règles de validation et critères d'acceptation. L'équipe clinique examine et approuve la spécification avant que le moindre code ne soit généré.

3. Configuration La spécification approuvée configure l'environnement de jumeau numérique du projet — en instanciant les ressources FHIR, les définitions de flux de travail et les données de test contre lesquelles l'application sera construite.

4. Construction Les agents développeurs IA génèrent l'application — dorsale et frontale — en ciblant les API FHIR-natives du jumeau numérique. Les compétences intégrées (SDC, IU, analytique, Terminology) servent de garde-fous, contraignant la production de l'IA à des modèles conformes à FHIR et cliniquement valides.

5. Test Les agents de test automatisé valident l'application contre le jumeau numérique, en vérifiant la conformité FHIR, l'exactitude du flux de travail et les critères d'acceptation issus de la spécification.

6. Validation L'équipe clinique interagit avec l'application fonctionnelle à l'intérieur du jumeau numérique — le même environnement dans lequel elle s'exécutera une fois déployée. La rétroaction retourne dans l'espace de travail pour itération.

7. Déploiement Après l'approbation des parties prenantes, l'application est déployée en tant qu'application SMART on FHIR, se lançant directement dans le DSE conforme à FHIR de l'organisation. Aucune infrastructure de déploiement à construire, aucun travail d'intégration à effectuer.

Une seule instance d'Atomic Workspace gère un nombre quelconque de projets simultanés — chacun s'exécutant dans un environnement entièrement isolé. Cela signifie que plusieurs équipes cliniques peuvent construire simultanément sans interférence, et que les données, le code et le contexte des agents de chaque projet restent complètement séparés. La figure 1 illustre cette architecture multi-projets.

Chaque environnement de projet n'est pas un bac à sable générique — c'est un jumeau numérique structuré comportant trois couches distinctes qui fonctionnent ensemble. La figure 2 montre l'architecture interne d'un seul projet : à gauche, le jumeau numérique des services de production (CDR FHIR, moteur de flux de travail, portail virtuel) ; au centre, la base de code et l'environnement d'exécution de l'application ; à droite, la couche Copilote IA avec les agents de codage opérant via le protocole ACP, guidés par une couche de compétences et de connaissances intégrée qui contraint la production de l'IA à des modèles conformes à FHIR et cliniquement valides.

Fondements techniques

Infrastructure et pile technologique

Atomic Workspace est construit sur Aidbox, une plateforme de serveur FHIR. Chaque projet s'exécute dans un contenant Docker isolé, géré via Multibox — la couche multi-locataire d'Aidbox — qui gère l'approvisionnement et l'isolation des données entre les projets.

Normes HL7

Déploiement

Atomic Workspace prend en charge les déploiements en nuage, sur site et hybrides. Les organisations ayant des exigences de résidence des données ou d'isolation réseau peuvent exécuter la plateforme complète dans leur propre infrastructure. Les applications SMART on FHIR se déploient sans travail d'intégration par cible sur Epic, Cerner et d'autres systèmes DSE conformes à FHIR.

Sécurité et conformité

Isolation des données et autorisation

Chaque projet s'exécute dans un environnement de jumeau numérique isolé. Le développement et les tests utilisent par défaut des données synthétiques ou dépersonnalisées. Les déploiements en production fonctionnent sous des BAA appropriés avec les partenaires organisations de santé. Tout accès à la plateforme utilise une authentification de niveau entreprise avec des contrôles d'accès fondés sur les rôles aux niveaux de la plateforme et de l'application.

Toutes les applications produites par la plateforme utilisent le cadre d'autorisation SMART pour le contrôle d'accès, en conformité avec les règles d'interopérabilité de CMS et les exigences de certification ONC pour les applications intégrées aux DSE.

Intervention humaine intégrée par conception

Des points de contrôle de validation humaine obligatoires sont intégrés au flux de travail lors de l'approbation de la spécification, de la validation clinique et de l'approbation des parties prenantes. Les agents d'IA opèrent entre ces points de contrôle, mais ne peuvent pas faire avancer un projet en production sans autorisation clinique et des parties prenantes. Le code généré par l'IA, les spécifications et les résultats des tests sont entièrement visibles et consultables dans l'espace de travail. Les participants cliniques et techniques peuvent inspecter, modifier et ignorer les sorties de l'IA à chaque étape.

Posture réglementaire

Les applications produites par Atomic Workspace qui relèvent du champ d'application des logiciels en tant que dispositif médical (SaMD) nécessitent un examen réglementaire distinct. La plateforme fournit l'infrastructure de développement et d'intégration ; elle ne remplace pas le processus de validation clinique et d'autorisation réglementaire pour les outils qui prennent ou influencent des décisions cliniques.

L'argumentaire économique

L'économie

Atomic Workspace ne vise pas à remplacer les développeurs. Il s'agit de changer ce qui nécessite leur implication.

Aujourd'hui, chaque application clinique exige un engagement complet de l'ingénierie — des exigences à la conception, au développement, aux tests et au déploiement. L'équipe de développement est le goulot d'étranglement pour chaque projet, quelle que soit la complexité. Les organisations augmentent les effectifs pour accroître la capacité, mais le coût de chaque application supplémentaire reste élevé.

Atomic Workspace change ce ratio. Les agents d'IA gèrent l'exécution. Les développeurs interviennent là où une profondeur technique réelle est nécessaire — intégrations complexes, cas limites, optimisation des performances. Il en résulte qu'une équipe d'une taille donnée peut soutenir significativement plus de projets par année.

Modèle de coûts

Le coût de la plateforme est principalement un coût d'infrastructure fixe qui s'amortit sur l'ensemble des projets. Une fois la plateforme déployée et la bibliothèque initiale de compétences établie, le coût marginal de chaque application supplémentaire diminue. Les organisations qui constituent une bibliothèque de compétences institutionnelles — encodant leurs propres flux de travail, règles cliniques et modèles de données — constatent des réductions de coûts supplémentaires à mesure que chaque nouveau projet démarre avec une base plus riche.

Construire ou acheter

Pour les organisations de technologie de l'information en santé qui évaluent la décision de construire ou d'acheter :

Construire une plateforme de développement IA personnalisée exige une expertise approfondie en FHIR, une infrastructure d'orchestration multi-agents, des connaissances du domaine clinique intégrées dans la chaîne d'outils, et une maintenance continue à mesure que les normes évoluent. Il s'agit d'un investissement pluriannuel de plusieurs millions de dollars avec des charges opérationnelles continues importantes.

Adapter des outils à vocation générale pour la santé transfère le fardeau d'intégration et de conformité sur chaque projet individuel. Chaque application devient un exercice d'intégration sur mesure. La plateforme n'accumule pas de connaissances cliniques ni d'alignement sur les normes au fil du temps.

Atomic Workspace part d'une fondation spécifique à la santé déjà en place — FHIR-native, alignée sur les normes, prête pour le DSE. La bibliothèque de compétences s'enrichit à chaque projet, de sorte que la plateforme devient plus utile avec le temps, et non moins.

Cas d'utilisation illustratifs

Collecte des résultats rapportés par les patients (PROMs)

Le problème Une équipe de soins qui gère des patients post-chirurgicaux doit collecter des scores de résultats standardisés (KOOS, HOOS, PROMIS) à des intervalles définis. Actuellement, cela se fait via des formulaires papier ou des appels téléphoniques manuels — les données se retrouvent dans des PDF numérisés ou des notes non structurées, et non dans le DSE.

La construction Un analyste clinique décrit l'exigence à l'analyste IA : collecter des PROMs spécifiques à 2 semaines, 6 semaines et 3 mois après l'opération, liés au CarePlan du patient dans le DSE. L'analyste IA convertit cela en une spécification structurée utilisant des ressources HL7 SDC IG Questionnaire pour chaque instrument de résultats.

Le développeur IA génère une application SMART on FHIR destinée aux patients qui envoie aux patients un lien sécurisé à l'intervalle approprié. Les patients remplissent le formulaire sur n'importe quel appareil ; les réponses sont stockées sous forme de ressources FHIR QuestionnaireResponse, liées au CarePlan d'origine et immédiatement disponibles dans le DSE.

Pour les patients qui préfèrent l'interaction vocale, le même flux de travail prend en charge un appel vocal par IA : un agent d'IA lit les éléments du questionnaire, saisit les réponses par la voix et les associe aux champs FHIR QuestionnaireResponse correspondants.

Le résultat Des données de résultats structurées et codées affluent directement dans le dépôt de données FHIR — sans transcription manuelle, sans notes non structurées. L'équipe de soins obtient une vue longitudinale complète des résultats rapportés par les patients sans modifier la façon dont les patients préfèrent interagir.

Capacités de la plateforme démontrées : SDC IG Questionnaire/QuestionnaireResponse, application SMART on FHIR destinée aux patients, service Terminology, intégration vocale IA, liaison CarePlan.

Tableau de bord analytique clinique en langage naturel

Le problème Un responsable des opérations cliniques souhaite suivre les taux de réadmission, la durée des séjours et l'adhérence médicamenteuse au sein d'une cohorte de patients — mais n'a aucun soutien en ingénierie disponible et ne peut pas attendre qu'une équipe d'intelligence d'affaires priorise la demande.

La construction L'analyste ouvre un nouveau projet dans Atomic Workspace et décrit le tableau de bord en langage naturel : quelle population de patients, quelles mesures, quelles fenêtres temporelles et comment les résultats doivent être affichés. Aucune connaissance de SQL ou de requêtes FHIR requise.

L'analyste IA produit une spécification qui associe chaque mesure aux ressources FHIR pertinentes (Encounter, MedicationRequest, Observation) et définit les requêtes SQL on FHIR qui alimenteront le tableau de bord. Après que l'analyste a approuvé la spécification, les agents développeurs IA génèrent l'application de tableau de bord — une application SMART on FHIR qui interroge le serveur FHIR en utilisant SQL on FHIR et affiche les résultats dans une interface interactive.

L'analyste peut affiner le tableau de bord par conversation de suivi : « ajouter un filtre pour le diagnostic principal », « afficher les courbes de tendance des 90 derniers jours », « ventiler cela par médecin traitant ». Chaque demande est traduite en une mise à jour de spécification et mise en œuvre par les agents d'IA.

Le résultat Un tableau de bord analytique clinique entièrement fonctionnel, déployé dans le DSE, construit sans participation de l'ingénierie — de la description à l'application fonctionnelle en moins d'une journée.

Capacités de la plateforme démontrées : SQL on FHIR, compétences analytiques, génération de spécifications en langage naturel, sortie d'application SMART on FHIR, raffinement itératif piloté par l'IA.

Service de prise de décision pour les autorisations préalables

Le problème L'autorisation préalable est l'un des processus les plus laborieux en santé. Les infirmières en gestion de l'utilisation (GU) vérifient manuellement l'admissibilité, les règles de couverture et les critères de nécessité médicale pour chaque demande d'autorisation — en parcourant de grandes feuilles de calcul de codes de facturation, en naviguant sur les sites Web de CMS pour les critères LCD/NCD (Local and National Coverage Determination) et en effectuant de multiples appels aux prestataires pour recueillir la documentation clinique. Le processus prend des heures par dossier.

Le problème fondamental est que les règles de couverture existent sous forme de texte non structuré sur les sites Web de CMS et dans des tableurs internes — et non sous forme de logique lisible par machine. Chaque payeur a des règles légèrement différentes. Il n'existe aucune façon normalisée de les encoder, de les maintenir ou de les exécuter automatiquement.

La construction Sur Atomic Workspace, une spécialiste en gestion de l'utilisation (GU) — un membre du personnel formé cliniquement responsable des décisions de couverture, généralement sans formation technique — travaille avec l'analyste IA pour définir les règles de couverture pour une ligne d'affaires spécifique — en commençant, par exemple, par l'oxygène à domicile (Medicare LCD L33797). La plateforme comprend une base de connaissances intégrée alimentée par des documents Medicare LCD/NCD : extraits de CMS, structurés et indexés, et mis à la disposition des agents d'IA via des outils de recherche et de similarité.

L'agent IA utilise cette base de connaissances pour extraire les critères de nécessité médicale pertinents, générer une ressource FHIR Questionnaire qui saisit les preuves cliniques requises, et encoder la logique de couverture sous forme de règle de décision structurée. La spécialiste en GU examine et affine le résultat — aucune programmation requise.

Le résultat est un Service de prise de décision : un composant fondé sur des normes qui accepte une demande CDS Hooks provenant du DSE lorsqu'une procédure soumise à autorisation préalable est prescrite, évalue les règles de couverture applicables par rapport au dossier FHIR du patient et répond par une décision — approuvée automatiquement (pour les prestataires « gold-card » ou les cas clairement admissibles), ou un lien vers la ressource FHIR Questionnaire générée pour que le clinicien la remplisse.

L'ensemble du service est construit comme un projet modèle dans Atomic Workspace, déployable auprès de plusieurs organisations de payeurs avec des ensembles de règles propres à chaque organisation, rédigés sur le cadre partagé.

Le résultat Les décisions d'autorisation préalable courantes sont traitées automatiquement au moment de la prescription — sans l'intervention des infirmières en GU. Les cas complexes ou exceptionnels sont acheminés vers un examen humain avec les preuves cliniques pertinentes déjà rassemblées. Les règles de couverture sont maintenues directement par les spécialistes en GU, sans intervention des développeurs, et mises à jour au fur et à mesure que les critères LCD/NCD évoluent.

Pour les payeurs, cela remplace un processus manuel et sujet aux erreurs par une automatisation auditable et fondée sur des normes, construite en quelques semaines — et non en plusieurs mois au coût de six chiffres des outils traditionnels de gestion des politiques.

Capacités de la plateforme démontrées : intégration CDS Hooks, génération de FHIR Questionnaire, base de connaissances Medicare LCD/NCD, rédaction de règles de couverture assistée par l'IA par du personnel non technique, déploiement multi-locataire basé sur des modèles.

Premières données probantes

Atomic Workspace est actuellement dans un projet pilote actif avec une équipe clinique. L'environnement de jumeau numérique est en service et opérationnel ; le développement réel de projets et la validation clinique sont en cours.

Les données de référence suivantes sont éclairées par les observations préliminaires du projet pilote et seront formellement validées dans le cadre du projet pilote en cours :

Pour commencer

Atomic Workspace est disponible pour un déploiement pilote auprès des organisations de technologie de l'information en santé et de leurs partenaires cliniques.

La plateforme prend en charge les déploiements en nuage, sur site et hybrides. Les engagements pilotes commencent par un cas d'utilisation clinique défini et se terminent par une application fonctionnelle déployée dans le DSE.

Pour discuter d'un projet pilote ou d'une évaluation technique : Contact : mary@health-samurai.io

Ressources de la plateforme :

• Environnement bac à sable disponible pour l'évaluation technique
• Documentation d'architecture et guides d'intégration disponibles sur demande

---

Atomic Workspace est développé par Health Samurai, l'équipe derrière la plateforme FHIR Aidbox.