Pour les hôpitaux
Évaluer EDFlow pour votre urgence : le modèle de projet pilote, les options de DME (Epic, Oracle Health, MEDITECH ou manuel), ce que fournissent les TI, les critères de mise en service et les indicateurs de réussite.
Cette page s'adresse aux gestionnaires de l'urgence, à l'informatique clinique et aux équipes de la vie privée et des TI qui décident de mener ou non un projet pilote EDFlow. Elle explique à quoi ressemble un projet pilote, ce que vos équipes fournissent, comment la mise en service est décidée et comment la réussite est mesurée.
Le déroulement d'un projet pilote
Mesure de référence (de 4 à 6 semaines avant la mise en service)
Mesurez les indicateurs de réussite ci-dessous sans EDFlow : les réponses au sondage sur l'expérience des patients, les délais de la porte au médecin et des résultats à la décision, les appels des familles au bureau, le taux de départs sans avoir été vu. Les mêmes définitions sont utilisées après la mise en service.
Intégration et fonctionnement en parallèle
Votre équipe d'intégration branche le flux du DME dans l'environnement de test du client, exécute les jeux d'essai de conformité, puis mène un fonctionnement en parallèle de 14 jours pendant lequel EDFlow détermine les étapes sans les montrer aux patients.
Configuration, contenu et formation
Les gestionnaires configurent les zones, les types de demandes, les codes, les examens et les renseignements sur l'hôpital. Un approbateur clinique approuve l'éducation des patients et les modèles de résumé de départ. Le personnel des zones pilotes suit la formation en mode formation.
Mise en service et revue hebdomadaire
L'impression des cartes de visite commence après le triage. Une revue hebdomadaire examine l'adoption, les demandes, les délais de réponse et tout signalement de danger. Consultez le pilot playbook (en anglais).
Options de DME
| Votre DME | Comment il se branche | Notes |
|---|---|---|
| Epic | HL7 v2 ADT et ORM/ORU par votre moteur d'intégration, ou notifications FHIR R4 | Consultez HL7 v2 et FHIR R4 (en anglais) |
| Oracle Health Millennium | HL7 v2 par le moteur, ou FHIR R4 | Mêmes adaptateurs, avec des notes propres au fournisseur |
| MEDITECH et autres | HL7 v2 par le moteur d'intégration | La matrice de prise en charge par fournisseur est sur la page HL7 v2 |
| Pas encore de flux | La console du personnel gère chaque état manuellement | Un mode à part entière, pas une démo : consultez Manual console (en anglais) |
Votre moteur envoie à EDFlow un ensemble restreint d'événements (arrivées, triage, assignations, demandes d'examens et leur statut, orientations, départs). EDFlow ne reçoit jamais de valeurs de résultats, de diagnostics ni de notes cliniques, et n'écrit jamais dans le DME pendant le projet pilote. Consultez Concepts (en anglais).
Ce que fournissent vos équipes
| Équipe | Ce qu'elle fournit |
|---|---|
| Direction de l'urgence | Un parrain du projet pilote, une infirmière responsable championne par quart, un approbateur clinique pour le contenu destiné aux patients |
| Intégration | Un flux sortant du moteur (stockage et retransmission), des messages de test, la correspondance des codes d'examens et d'emplacements |
| Vie privée | L'EFVP et l'entente de mandataire; l'examen du dossier de sécurité; un compte de responsable de la vie privée |
| TI et sécurité | L'EMR, la liste d'autorisation réseau pour les postes du personnel et l'affichage, la GAM pour les téléphones du personnel, la connexion Microsoft Entra ID s'il y a lieu |
| Communications | Affiches, signalisation QR et cartes de visite, à l'aide de la trousse de communication pour les hôpitaux (en anglais) |
Critères de mise en service
Un site passe de la préparation du projet pilote à la mise en service seulement quand chaque critère est rempli. EDFlow affiche l'état de chaque critère sur la page de la plateforme, et personne ne peut les contourner :
- une exécution de conformité où chaque jeu d'essai réussit;
- un fonctionnement en parallèle de 14 jours avec au moins 98 % de concordance des jalons avec l'échantillon d'audit du site;
- un délai du DME à l'écran de 60 secondes ou moins au 95e centile;
- moins de 0,5 % d'événements rejetés, et aucun code non associé au cours des 30 derniers jours;
- un rapprochement de la liste qui clôt chaque congé de test;
- le dossier de sécurité clinique approuvé pour la configuration du site;
- l'EFVP et l'EMR enregistrées comme approuvées;
- la formation du personnel terminée pour les zones pilotes.
Le trafic de l'API d'intégration et les fonctions d'IA ont leurs propres critères, décrits dans Go live et AI (en anglais).
Indicateurs de réussite
Les cibles sont des cibles de projet pilote par rapport à la mesure de référence prise avant le projet dans le même site. « Pas pire » veut dire que l'intervalle de confiance à 95 % exclut une détérioration relative de plus de 10 %.
| Id | Ce que nous mesurons | Cible du projet pilote | Mesuré par |
|---|---|---|---|
M-01 | Told why about a long wait (Ontario ED short form Q1) | +15 percentage points | K-20 |
M-02 | The app helped a lot to know what was happening | ≥ 70% | K-22 |
M-03 | Overall rating 9–10 (top box) | +10 points | K-23 |
M-04 | Enough information about what to do after leaving | +10 points | K-24 |
M-05 | Door-to-doctor (PIA wait) p50 and p90 | Not worse; p90 ≤ 3.4 h | K-03 |
M-06 | Results-to-disposition p50 and p90 | −15% | K-09 |
M-07 | ED length of stay p50 and p90 by disposition | Not worse | K-04 |
M-08 | Boarding time p50 and p90 | Measured, no target | K-07 |
M-09 | Request time to acknowledge p50 / p90 | ≤ 3 min / ≤ 12 min | K-12 |
M-10 | Urgent request time to an in-person response p90 | ≤ 5 min; first response ≤ 2 min | K-12 |
M-11 | Request SLA compliance | ≥ 90% | K-14 |
M-12 | Family status calls to the desk (sampled tally) | −30% | — |
M-13 | Left without being seen rate | Not worse | K-05 |
M-14 | Unplanned 72-hour return rate | Not worse | K-25 |
M-15 | Wrong-patient access events | 0 | — |
M-16 | PHI found in any push, SMS, email, URL or log sample | 0 | — |
M-17 | Activation rate | ≥ 40% by pilot month 2 | K-16 |
M-18 | Family share rate among activated visits | ≥ 20% | K-18 |
M-19 | Activation-rate gap across preferred languages and age bands | ≤ 10 points | K-16 |
M-20 | Share of intervals within the “9 in 10” ceiling | ≥ 88% | K-26 |
M-21 | Patient-visible state lag p95 | ≤ 5 s ingest to screen; ≤ 60 s EHR action to screen | — |
M-22 | Availability of patient and staff surfaces (monthly) | ≥ 99.9% | — |
M-23 | Alerts per nurse per hour by role and shift | Reported; reviewed monthly | K-34 |
M-24 | Ambulance offload time p90 and share within target | Measured; not worse | K-32 |
M-25 | Clinical incidents attributed to the app | 0 severe; every incident reviewed within 10 business days | — |
Les définitions des analyses suivent les conventions du PAQ de l'Ontario et du SNISA. Consultez Analytics (en anglais).
Vie privée, résidence des données et sécurité
La production des hôpitaux est hébergée au Canada (AWS ca-central-1, avec la reprise après sinistre dans ca-west-1). EDFlow agit comme votre mandataire et votre fournisseur de services électroniques au sens de la LPRPS. Commencez par l'aperçu de la confiance et demandez le dossier de sécurité confidentiel à partir des documents de conformité (en anglais).
Ce que verront les patients et le personnel
- Filtres et vues
- Signal de goulot
- Demandes ouvertes
Voir aussi
- Démo, avec les hôpitaux fictifs
- Pilot playbook (en anglais)
- Integrating Epic and Oracle Health et Measuring ED flow, sur le site du produit (en anglais)
Dernière mise à jour le
Cette page vous a-t-elle été utile?
Démo
Essayez EDFlow avec deux hôpitaux ontariens fictifs : ce que montre chaque visite d'exemple, comment ouvrir le lanceur de démo avec un code d'invitation, et ce que la démo ne contiendra jamais.
Glossaire
Les termes de l'urgence utilisés dans EDFlow (ÉTG, EIM, résumé de départ, PSV, à jeun, orientation, code, attente d'un lit) avec les mots simples que voient les patients et les termes qu'utilise le personnel.