ICUDATAEXPERTLA DONNÉE AU SERVICE DES SOINS
100 % OPÉRATIONNEL TOUTES LES FONCTIONNALITÉS PRÉSENTÉES SONT DÉJÀ IMPLÉMENTÉES DANS ICU DATA EXPERT
SOURCES & PREUVES

Des affirmations commerciales séparées des repères scientifiques.

Cette page documente les principales références externes utilisées pour contextualiser la valeur de la documentation, du codage et de l’automatisation. Les résultats externes ne sont pas présentés comme des performances garanties d’ICU DATA EXPERT.

Essai randomisé suisse — optimisation du codage DRG

+6,5% de remboursement par journée d’hospitalisation dans le groupe précodage.

PubMed →
Temps infirmier ICU consacré au dossier électronique

317 infirmiers ; environ 17,5% du temps clinique consacré à l’EHR, principalement à la documentation.

PubMed →
Clinical Documentation Improvement

Un programme académique de chirurgie a rapporté 4,67 M$ d’augmentation estimée des charges associées aux réponses aux requêtes de documentation.

PubMed →
SSMI — certification des unités de soins intensifs

Directives officielles et processus de certification des USI suisses.

SSMI →
ISFM — établissements de formation postgraduée

Registre officiel des établissements reconnus en médecine intensive et de leur catégorie.

ISFM →

Fiches pratiques : préparer des données USI vérifiables

Trois fiches pour préparer un échange entre référents du service, équipes de codage et informatique. Elles proposent une méthode de contrôle ; elles ne remplacent ni les règlements officiels ni la validation locale.

MDSi : contrôler les données avant leur transmission

Pour les référents qualité et les responsables des données du service.

La SSMI publie les documents MDSi et leur période de validité. Pour 2026, sa page Données présente le règlement V33. Il faut distinguer ce référentiel de la façon dont un logiciel collecte et prépare les informations.

  1. Identifier le référentiel applicable à l’année des données, le service concerné et la personne qui autorise la transmission. Conserver ces informations avec le lot exporté.
  2. Vérifier sur un échantillon le rattachement au bon épisode USI, les dates d’entrée et de sortie et la cohérence des identifiants. Ne pas confondre dossier patient et passage en USI.
  3. Examiner les champs manquants et les incohérences signalées, puis documenter les vérifications. Une valeur absente ne doit pas devenir une valeur normale par défaut.
  4. Comparer le fichier préparé avec les données vérifiées, conserver sa version et contrôler le retour du système destinataire. Un fichier généré n’est pas encore un fichier accepté.

Livrable de contrôle proposé

Un lot identifié, les anomalies résolues ou expliquées, la validation du référent et le retour de transmission associé.

Sources et version à vérifier

Relier cette fiche au logiciel

Ventilation : documenter une période à vérifier

Pour les référents du service et les équipes de codage.

Dans le processus présenté par ICU DATA EXPERT, une interruption de données déclenche une vérification : elle ne démontre pas, à elle seule, l’arrêt de la ventilation. La durée reconstruite doit rester rattachée aux éléments documentés du séjour.

  1. Repérer l’épisode, le début et la fin de l’intervalle suspect ainsi que l’origine du signal : absence d’échantillons, documentation incomplète ou changement de contexte.
  2. Confronter l’intervalle aux traces disponibles du dossier : support ventilatoire, événements de pose ou d’ablation et mouvements du patient. Ne pas inventer les horaires manquants.
  3. Faire valider toute correction par le référent habilité. Conserver l’origine de la correction, sa justification et les éléments permettant de la retrouver.
  4. Contrôler après recalcul le total, le détail des périodes et leur restitution dans les documents. L’équipe de codage applique ensuite les règles valables pour le cas ; une correction n’implique pas automatiquement un remboursement supplémentaire.

Livrable de contrôle proposé

Une période confirmée, corrigée ou laissée non résolue avec son motif, accompagnée du résultat recalculé et de la validation métier.

Sources et version à vérifier

Relier cette fiche au logiciel

Intégration : préparer la validation de la chaîne de données

Pour les responsables informatiques, les administrateurs de bases et les référents métier.

La réception technique doit porter sur toute la chaîne, pas seulement sur le démarrage du moteur. Avec PostgreSQL, une réplique en hot standby est en lecture seule et peut être en retard sur la source. Le chiffrement et la vérification de l’identité du serveur sont deux contrôles distincts.

  1. Décrire la source, la réplique, les couches de transformation, le moteur et les destinations documentaires. Identifier les flux entre machines et les comptes autorisés, sans inclure de secrets dans la fiche.
  2. Préparer avec l’informatique les contrôles de droits, de chiffrement et de certificats sur chaque liaison. Pour les clients PostgreSQL libpq, verify-full vérifie aussi la correspondance du nom du serveur ; le réglage exact dépend du client utilisé.
  3. Tester hors production un retard de données, une interruption et une reprise. Vérifier ce qui est signalé au référent et distinguer disponibilité du processus et fraîcheur des données.
  4. Utiliser des cas de test synthétiques ou correctement anonymisés pour comparer données sources, calculs et documents. Consigner les résultats attendus, les écarts, la décision de mise en service et le retour arrière prévu.

Livrable de contrôle proposé

Une fiche d’architecture et une matrice de tests validées par les responsables techniques et métier. Il s’agit d’un support de préparation, pas d’un installateur ni d’une attestation de conformité.

Sources et version à vérifier

Relier cette fiche au logiciel

Périmètre : préparation et traçabilité des données. Ces fiches ne sont pas des recommandations de traitement, un manuel de codage ou une certification du logiciel.

Préparer un échange sur votre service