RUCEL/ SYSTEMS
Projets choisis

DOCUMENTATION VOCALE / INTEROPÉRABILITÉ

Vital Mapper

Voix → données cliniques structurées → FHIR

Une plateforme de documentation infirmière assistée par la voix, qui transforme les observations parlées en structure clinique fondée et révisable, puis transmet les dossiers approuvés via une gateway d’interopérabilité versionnée.

PROTOTYPE IMPLÉMENTÉ · REVUE HUMAINE REQUISE
Comment la langue clinique non structurée peut-elle devenir des données interopérables sans perdre la supervision humaine ?

01 / Problème

Le signal clinique commence dans le langage naturel.

Les notes infirmières contiennent des observations importantes, mais la parole n’est ni automatiquement structurée, ni codée, ni prête à franchir une frontière système. L’enjeu d’ingénierie est de préserver l’énoncé, de rendre l’incertitude visible et de laisser la décision finale au soignant.

  • Constantes et apports hydriques
  • Douleur, symptômes, mobilité et observations
  • Interventions infirmières et qualificatifs de contexte

02 / Architecture

Le modèle propose ; les données approuvées franchissent un contrat contrôlé.

L’implémentation sépare le traitement local de la parole et du langage d’une extraction clinique typée, des contrôles de grounding, de la revue et d’un contrat de gateway versionné. Vital Mapper n’écrit pas directement dans HAPI FHIR ; le monitoring possède le mapping FHIR, LOINC et UCUM faisant autorité.

  1. 01
    Entrée vocaleAction microphone explicite
  2. 02
    Stockage audio chiffréPersistance protégée des enregistrements
    implémenté
  3. 03
    faster-whisperService local speech-to-text
    implémenté
  4. 04
    Extraction OllamaProposition structurée locale
    implémenté
  5. 05
    Grounding + modèle canoniqueLes faits non fondés sont rejetés
  6. 06
    Approbation humaineCorrection avant soumission
  7. 07
    Gateway interopContrat Monitoring et frontière FHIR
    implémenté
Le modèle de langage n’est pas une autorité de création FHIR. Il reste une assistance d’extraction contrainte.

03 / Flux de données

Le contrôle humain est une porte, pas une note de bas de page.

La transcription source reste visible à côté de l’information extraite et de la proposition FHIR. Un soignant peut confirmer, corriger ou rejeter chaque élément avant toute persistance.

  1. 01Transcription
  2. 02Information extraite
  3. 03Proposition FHIR
  4. 04Revue infirmière
  5. 05Confirmer / corriger / rejeter
  6. 06Persister via une API contrôlée

Cette étude modélise une assistance, pas une instance de décision clinique autonome.

04 / Modèle de données cliniques

D’un énoncé à un modèle clinique fondé.

L’extraction implémentée garde le lien à la source et les informations manquantes visibles. La structure intermédiaire permet de revoir latéralité, mobilité et unités avant la soumission du rapport approuvé et des constantes au contrat Monitoring.

ENTRÉE INFIRMIÈRE SYNTHÉTIQUE
« Le patient signale depuis ce matin une douleur au genou droit. Mobilité limitée. Température : 37,8 °C. »
Symptôme
Douleur au genou
Latéralité
Droite
Mobilité
Limitée
Température
37,8 °C
Représentation FHIR côté Monitoring · exemple synthétique

Après approbation, la gateway transmet les constantes fondées à Monitoring Pflege. Son backend mappe les types de mesures de manière déterministe vers une Observation ; le texte approuvé est enregistré comme Composition avec Encounter actif.

{
  "resourceType": "Observation",
  "status": "preliminary",
  "subject": { "reference": "Patient/synthetic-1042" },
  "encounter": { "reference": "Encounter/synthetic-enc-37" },
  "code": { "text": "Body temperature" },
  "valueQuantity": {
    "value": 37.8, "unit": "°C",
    "system": "http://unitsofmeasure.org", "code": "Cel"
  }
}

05 / Interopérabilité

L’interopérabilité dépasse le JSON valide.

Le choix d’une ressource FHIR dépend du fait documenté, du workflow de soins, des profils locaux et du système destinataire. Le modèle propose donc d’abord un fait clinique typé ; le mapper applique ensuite les règles du contrat d’intégration convenu.

01

Observation

Mesures et certains constats, avec unités et références.

02

Condition

Peut convenir à un problème clinique maintenu, selon workflow et gouvernance.

03

ClinicalImpression

Peut porter un contexte d’évaluation lorsque cela est pertinent.

04

Composition

Peut représenter un contexte documentaire structuré selon l’implémentation.

05

Provenance

Peut consigner la création et la revue sans remplacer la note source.

FHIR / terminologyLa terminologie est une couche sémantique distincte : UCUM peut normaliser les unités ; LOINC et SNOMED CT sont des cibles d’intégration conceptuelles lorsqu’un jeu de valeurs gouverné et le contexte de licence existent. Cette étude ne prétend pas fournir un service terminologique complet.

06 / Sécurité

Privacy et frontières de confiance sont implémentées dans le chemin.

Vital Mapper utilise une session BFF OIDC côté serveur, des tokens chiffrés soutenus par Redis, des contrôles de rôles et par patient, un stockage audio chiffré et des logs d’audit. Les services locaux faster-whisper et Ollama réduisent les transferts externes de données vers des modèles dans l’architecture de développement.

01

Audio

Les enregistrements sont chiffrés au repos ; le frontend maintient l’audio hors du stockage persistant du navigateur.

02

Traitement IA

faster-whisper et Ollama sont des services locaux ou compatibles on-premises dans l’architecture Compose.

03

Accès API

Keycloak/OIDC, sessions côté serveur et RBAC protègent API et accès patient.

04

Intégration

Les données approuvées passent par la gateway ; l’accès direct à HAPI est volontairement mis en quarantaine.

Les contrôles implémentés ne constituent ni une certification ni une revendication de déploiement clinique en production.

07 / Décisions d’ingénierie

Décisions d’ingénierie clés

  1. 01

    Extraction fondée avant intégration

    Les valeurs non étayées sont rejetées au lieu d’être complétées par le modèle.

  2. 02

    Revue avant persistance

    Chaque proposition reste une documentation clinique éditable, jamais une conclusion autonome.

  3. 03

    Gateway plutôt qu’accès FHIR direct

    Vital Mapper transmet les informations approuvées par un contrat de gateway versionné ; Monitoring Pflege détient le mapping FHIR faisant autorité.

Défis d’ingénierie ouverts
  • Représenter négation, incertitude, temporalité et attribution sans aplatir l’énoncé parlé.
  • Choisir profils de ressources et liaisons terminologiques adaptés au workflow cible plutôt qu’à une démonstration générique.
  • Rendre les corrections traçables sans exposer de contenu clinique inutile dans les logs.

08 / État & suite

État actuel

PROTOTYPE IMPLÉMENTÉ

Le dépôt implémente le workflow React/FastAPI, la persistance audio chiffrée, la transcription locale faster-whisper, l’extraction Ollama, les contrôles de grounding, l’approbation manuelle, les sessions BFF Keycloak/OIDC, PostgreSQL/Redis et le chemin de soumission vers la gateway Monitoring.

DIRECTION FUTURE

Direction future

Les prochaines étapes sont une évaluation rigoureuse de l’extraction, des tests du contrat d’intégration entre déploiements, une politique opérationnelle de rétention et une validation clinique/gouvernance avant tout usage en soins réels.

09 / Ce que cela démontre

Ce que ce projet démontre

  1. 01Engineering IA avec frontière human-in-the-loop explicite
  2. 02Modélisation des données cliniques avant sérialisation
  3. 03Conception d’intégration consciente de FHIR et prudence terminologique
  4. 04Réflexion privacy-by-design aux frontières système