Des sources fragmentées
L’information utile peut vivre dans plusieurs formats, systèmes ou épisodes, avec des accès différents.
Architecture
S’appuyer sur l’écosystème existant (EAI) de l’établissement. Rendre chaque responsabilité visible.
Selon l’établissement, l’architecture cible peut utiliser le moteur d’interopérabilité existant (EAI) et des interfaces telles que FHIR, HL7 et des API. Ces mécanismes doivent être validés localement ; cette démo ne démontre aucune compatibilité de production.
Le problème opérationnel
L’intégration est une discipline opérationnelle
Interfaces, identité, terminologies, latence, habilitations et erreurs doivent être définies — pas une promesse de connectivité universelle.
Périmètres
Les systèmes sources restent les références ; Ariane fournit une couche de contexte dérivée.
Ce qu’Ariane ne prétend pas être
Un connecteur universel qui efface le travail local d’interface, de mapping ou d’identité.
Architecture
Quatre couches. Un statut par capacité.
Du système source au flux de travail.
Chaque capacité porte exactement un des trois statuts ci-dessous.
- Illustré dans cette démoComportement illustré ici sur données fictives — pas une preuve d’intégration réelle.
- Architecture cibleSchéma technique envisagé ; ne signifie pas une intégration opérationnelle.
- À valider avec l’établissementDépend des systèmes, interfaces, habilitations ou gouvernance locales.
Applications de l’établissement
À valider avec l’établissement
- DPIÀ valider avec l’établissement
- SILÀ valider avec l’établissement
- RIS / comptes rendusÀ valider avec l’établissement
- PharmacieÀ valider avec l’établissement
- DocumentsÀ valider avec l’établissement
Chaque système de l’établissement reste la référence pour son domaine.
Interfaces & identité
- API FHIRArchitecture cible
- HL7 v2/v3Architecture cible
- API sécuriséesArchitecture cible
- Fichiers (PDF, OCR, Word…)Architecture cible
- DICOMweb / comptes rendusArchitecture cible
- Identité patient / INSÀ valider avec l’établissement
Échange et identité patient entre les applications sources.
Couche de contexte patient
- ProvenanceIllustré dans cette démo
- RechercheIllustré dans cette démo
- AbstentionIllustré dans cette démo
- NormalisationArchitecture cible
- Index longitudinalArchitecture cible
- Événements d’auditArchitecture cible
Ariane dérive un contexte patient à partir des sources autorisées.
Flux de travail cliniques
- Vue patientIllustré dans cette démo
- RechercheIllustré dans cette démo
- Documents préparatoiresIllustré dans cette démo
- SMART-on-FHIRArchitecture cible
- Widget intégréArchitecture cible
- API du système sourceÀ valider avec l’établissement
Les flux présentés ici sont simulés.
Dans cette démonstration, aucun contenu n’est écrit dans un système source. Consultation en lecture seule par défaut. Tout export ou écriture éventuel serait distinct, explicitement déclenché, soumis aux habilitations et auditable — uniquement si l’établissement et l’application source le permettent.
Cadrage envisagé pour un déploiement
Étapes et responsabilités à valider avec un établissement.
Les interfaces, l’identité, les terminologies, la latence, les habilitations et la gestion des erreurs doivent être définies — et non masquées derrière une promesse de connectivité universelle. Ce cadrage décrit une méthode de validation avec l’établissement ; il n’est pas la preuve d’un déploiement déjà réalisé.
Côté établissement et projet
- Autoriser l’accès aux sources, l’identité et les rôles.
- Valider interfaces, mappings, usage clinique et critères d’acceptation.
- Valider hébergement, sécurité et support.
Périmètre proposé pour Ariane
- Préserver la provenance dans le contexte dérivé et les restitutions.
- Mettre en œuvre interfaces, recherche et comportement convenus.
- Documenter configuration, tests, supervision et changements retenus.
Définition du cas d’usage
Utilisateurs, flux, sources, résultat attendu et exclusions.
Périmètre et critères de succès
Validation technique
Interfaces, identité (dont INS), habilitations, provenance et responsabilités.
Architecture et matrice des responsabilités
Pilote contrôlé
Configurer, tester les défaillances, former et mesurer.
Résultats du pilote et revue des risques
Passage en production — si les critères du pilote sont satisfaits
Contrôles, supervision, support et éventuelle extension.
Dossier d’acceptation en production
Calendrier estimé seulement après validation des prérequis avec l’établissement.
Questions à résoudre avant un déploiement
Architecture et gouvernance
Ariane remplace-t-elle le DPI ou le moteur d’interopérabilité ?
Non. Ariane est une couche d’accès à l’information clinique. Les systèmes sources restent les références. Le cloisonnement exact se définit avec chaque établissement.
Un EAI ou un DPI particulier est-il requis ?
Non. Selon l’établissement, l’architecture cible peut s’appuyer sur le moteur d’interopérabilité existant (EAI) et sur les interfaces déjà disponibles. Aucun DPI, EAI ou standard unique n’est imposé ici. Le périmètre se valide localement.
Le produit fonctionne-t-il toujours en lecture seule ?
Consultation en lecture seule par défaut dans cette démo — voir le cadrage ci-dessus.
Cette démo établit-elle une compatibilité FHIR, HL7 ou DICOM ?
Non. FHIR, HL7, des API ou des fichiers sont des mécanismes possibles — chacun à valider localement. Cette démo n’établit aucune compatibilité de production.
Que se passe-t-il si une source est absente ou un mapping incomplet ?
Ariane ne remplace pas le travail local d’interface ou de mapping. Dans cette démo, l’absence d’information est rendue visible plutôt que complétée. La conduite à tenir en production se définit avec l’établissement.
Quel délai d’intégration faut-il prévoir ?
Aucun délai universel n’est annoncé. Un calendrier n’est estimé qu’après validation des prérequis — sources, interfaces, habilitations et cas d’usage — avec l’établissement.
Que doit-on définir concernant la sécurité, le RGPD et la conformité ?
Avec l’établissement : rôles RGPD, localisation, conservation, sous-traitants, périmètre des données, hébergement, contrôles d’accès, journalisation et responsabilités opérationnelles. Cette démo ne présente ni certification ni conformité RGPD déclarée.
Commencer par un workflow d’établissement et rendre la preuve visible.
Quel DPI et quels systèmes clés utilisez-vous ? Avec vos utilisateurs et votre cas d’usage, nous évaluons architecture, risques et plan de validation adaptés à votre établissement.