Votre modèle de données du parcours patient

Epic EHR
Votre modèle de données du parcours patient

Votre modèle de données du parcours patient

Ce modèle fournit un cadre complet pour cartographier les flux de travail cliniques dans votre environnement Epic. Il décrit les points de données et les jalons d’événements nécessaires pour visualiser l’intégralité du parcours patient, de l’admission à la sortie. En suivant ces recommandations, vous pouvez structurer vos données afin d’obtenir des analyses opérationnelles détaillées et d’améliorer la prestation des soins.
  • Attributs recommandés pour le contexte clinique
  • Principaux jalons du processus à suivre
  • Instructions d’extraction spécifiques au DSE Epic
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs du parcours patient

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le flux des patients et l’efficacité clinique.
5 Obligatoire 9 Recommandé 7 Facultatif
Nom Description
Épisode patient
PatientEpisodeId
Identifiant unique de la rencontre avec le patient ou de l’épisode de soins concerné.
Description

L’épisode patient constitue l’identifiant de cas principal pour le Process Mining. Il regroupe tous les événements cliniques, administratifs et logistiques associés à une même période continue de soins, par exemple une hospitalisation ou une visite aux urgences. Dans Epic Clarity, il correspond généralement au Contact Serial Number (CSN) ou à l’Encounter ID.

L’analyse de cet attribut permet de reconstituer le parcours complet du patient. Elle associe les activités de triage, de diagnostic, de traitement et de sortie au sein d’une même instance de processus cohérente.

Pourquoi c’est important

Il s’agit de la clé fondamentale permettant de relier des événements distincts au sein d’un même cas de processus.

Où les obtenir

Table Epic Clarity : PAT_ENC, colonne : PAT_ENC_CSN_ID

Exemples
200459112200459113200459114200459115
Horodatage de l’événement
EventTimestamp
Date et heure exactes auxquelles l’activité s’est produite.
Description

Cet attribut enregistre le moment précis où un événement a été consigné dans le système Epic. Il sert à ordonner les activités et à calculer tous les indicateurs fondés sur la durée, notamment la durée de séjour et les temps de cycle.

La précision de ce champ est essentielle pour identifier les goulots d’étranglement. Elle alimente les Dashboards Triage Throughput et Time to Definitive Diagnosis en fournissant les repères temporels des points de début et de fin.

Pourquoi c’est important

Il permet de calculer les temps de cycle, les délais et l’ordre des processus.

Où les obtenir

Différentes colonnes d’horodatage, par exemple EFFECTIVE_TIME et ORDER_TIME, selon la table source.

Exemples
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
Nom de l’activité
ActivityName
Action clinique ou administrative précise réalisée.
Description

Cet attribut enregistre le nom de l’événement qui se produit au cours du parcours du patient, par exemple « Patient enregistré », « Médicament administré » ou « Ordre de sortie signé ». Il constitue l’élément central de la définition du flux de processus.

Dans l’analyse, ce champ forme les nœuds de la cartographie du processus. Il est dérivé de différents codes de transaction et statuts de commande du DSE afin de créer un journal d’événements lisible.

Pourquoi c’est important

Il définit les étapes du processus et permet de visualiser le flux de travail.

Où les obtenir

Dérivé des tables CLARITY_ADT, ORDER_PROC et ORDER_MED.

Exemples
Triage terminéExamen diagnostique prescritPatient sortiMédicament administré
Dernière mise à jour des données
LastDataUpdate
Horodatage de l’extraction ou de la dernière actualisation des données.
Description

Cet attribut indique à quel moment l’enregistrement a été traité pour la dernière fois par le pipeline ETL. Il se distingue de l’horodatage de l’événement et contribue au suivi de l’actualité des données.

Les analystes l’utilisent pour déterminer si le Dashboard reflète la situation en temps réel ou si un problème de latence des données affecte la précision d’indicateurs tels que Triage Wait Times.

Pourquoi c’est important

Il aide à évaluer l’actualité et la fiabilité des données de Process Mining.

Où les obtenir

Horodatage du système ETL.

Exemples
2023-10-27T23:59:59Z2023-10-28T06:00:00Z
Système source
SourceSystem
Système de référence des données, généralement le DSE Epic.
Description

Cet attribut identifie l’origine des données. Même s’il s’agit principalement d’« Epic EHR » dans cette vue, il est utile lorsque les données sont combinées avec celles d’autres systèmes, comme un LIS distinct ou un système de facturation.

Dans l’analyse, il garantit la traçabilité des données et facilite le diagnostic lorsque certains événements semblent absents ou incorrects par rapport à la source.

Pourquoi c’est important

Il assure la traçabilité et fournit le contexte relatif à l’origine des données.

Où les obtenir

Valeur codée en dur ou dérivée de la configuration de la chaîne de connexion.

Exemples
Epic EHREpic ClarityEpic Caboodle
Code du diagnostic principal
PrimaryDiagnosisCode
Code ICD-10 ou code interne représentant le diagnostic principal.
Description

Cet attribut enregistre l’affection médicale confirmée du patient. Il est généralement renseigné lors de l’activité « Diagnostic confirmé ».

Il sert à regrouper les cas par affection clinique pour la Clinical Protocol Compliance View. Son association à « Product » permet aux analystes d’observer comment la « production » des soins varie selon l’affection médicale.

Pourquoi c’est important

Il regroupe les cas présentant des caractéristiques cliniques similaires pour l’analyse des protocoles.

Où les obtenir

Table Epic Clarity : PAT_ENC_DX, colonne : DX_ID

Exemples
J18.9I21.9E11.9
Destination à la sortie
DischargeDisposition
Destination du patient à sa sortie, par exemple domicile, SNF ou décès.
Description

Cet attribut enregistre le lieu où le patient s’est rendu après avoir quitté l’hôpital. Il est renseigné lors de l’activité « Patient sorti ».

Il est essentiel pour le Dashboard Readmission Risk, car les patients orientés vers des établissements de soins infirmiers spécialisés (SNF) présentent des profils de réadmission différents de ceux qui retournent à domicile.

Pourquoi c’est important

Il permet de contextualiser le résultat du processus de soins.

Où les obtenir

Table Epic Clarity : PAT_ENC, colonne : DISCH_DISP_C

Exemples
DomicileÉtablissement de soins infirmiers spécialisésSoins à domicile
Heure de fin de l’événement
EventEndTime
Horodatage auquel l’activité a été terminée.
Description

Si de nombreux événements sont instantanés, certaines activités, comme « Test diagnostique réalisé » ou « Consultation terminée », ont une durée. Cet attribut enregistre l’heure de fin.

Il permet de calculer le temps de traitement actif par rapport au temps d’attente. Il est particulièrement pertinent pour le Dashboard Diagnostic Service Cycle Times.

Pourquoi c’est important

Il permet de calculer la durée des activités et l’utilisation des ressources.

Où les obtenir

Consultez la documentation Epic EHR pour connaître les colonnes spécifiques d’heure de fin dans ORDER_PROC.

Exemples
2023-10-15T09:45:00Z2023-10-16T15:00:00Z
ID du professionnel de santé
ProviderId
Identifiant de l’utilisateur ou du clinicien ayant réalisé l’activité.
Description

Cet attribut enregistre l’identifiant unique du membre du personnel responsable de l’événement, par exemple l’infirmier qui administre un médicament ou le médecin qui signe les ordres de sortie.

Il est associé à l’attribut générique « User » afin d’analyser les variations entre ressources et la charge de travail. Pour les activités automatisées, il peut s’agir de l’identifiant d’un utilisateur système.

Pourquoi c’est important

Il permet d’analyser les écarts de performance et de charge de travail entre les membres du personnel.

Où les obtenir

Table Epic Clarity : CLARITY_EMP, colonne : USER_ID

Exemples
EMP10023DOC5592SYSTÈME
Indicateur de réadmission
ReadmissionFlag
Indique si le patient est revenu de manière imprévue dans les 30 jours.
Description

Cet attribut booléen indique si l’épisode concerné a été suivi d’une nouvelle admission non planifiée du même patient dans un délai de 30 jours. Il constitue la base du KPI 30-Day Unplanned Readmission Rate.

Dans l’analyse, il sert de variable de résultat majeure. Les parcours de processus associés à la valeur « True » sont étudiés afin d’identifier les causes profondes au stade de la planification de la sortie.

Pourquoi c’est important

Il identifie les sorties mal préparées et les problèmes liés à la qualité des soins.

Où les obtenir

Calculé en SQL en recherchant les rencontres ultérieures du même MRN.

Exemples
truefalse
MRN du patient
PatientMrn
Medical Record Number identifiant le patient.
Description

Le MRN est l’identifiant unique du patient dans l’ensemble du système de santé, distinct de l’identifiant de l’épisode. Il permet de suivre l’historique d’un patient au fil de plusieurs visites.

Cet attribut sert à détecter les réadmissions et à relier des épisodes distincts pour le Dashboard Readmission Risk. Il correspond à « Customer » dans le modèle générique.

Pourquoi c’est important

Il est essentiel pour identifier les visites répétées et analyser l’historique du patient.

Où les obtenir

Table Epic Clarity : PATIENT, colonne : PAT_ID ou PAT_MRN_ID

Exemples
MRN-882910MRN-112003MRN-554211
Niveau d’acuité du triage
TriageAcuityLevel
Score de gravité attribué au patient lors du triage.
Description

Cet attribut indique le degré d’urgence de l’état du patient, généralement sur une échelle, par exemple les niveaux ESI de 1 à 5. Il est enregistré lors de l’activité « Triage terminé ».

Il permet la segmentation dans le Dashboard Resource Intensity by Severity Score. Les patients présentant une forte acuité suivent des parcours différents de ceux dont l’acuité est faible, et ce champ aide à distinguer ces variantes.

Pourquoi c’est important

Il segmente le processus selon le degré d’urgence et la consommation attendue de ressources.

Où les obtenir

Consultez la documentation Epic EHR pour connaître le champ Acuity dans les journaux des urgences.

Exemples
1 - Réanimation2 - Urgence immédiate3 - Urgent
Nom du service
DepartmentName
Unité ou service hospitalier dans lequel l’activité a eu lieu.
Description

Cet attribut identifie le lieu fonctionnel de l’événement, par exemple « Service des urgences », « Radiologie » ou « Service de chirurgie générale ». Il est essentiel pour l’Internal Ward Transfer Analysis.

Les données servent à segmenter la cartographie du processus par service, afin de permettre aux responsables d’isoler les goulots d’étranglement propres à leur unité des problèmes systémiques qui concernent l’ensemble de l’hôpital.

Pourquoi c’est important

Il permet le filtrage organisationnel et l’analyse des transferts entre équipes.

Où les obtenir

Table Epic Clarity : CLARITY_DEP, colonne : DEPARTMENT_NAME

Exemples
Service des urgencesRadiologieICUPédiatrie
Type de rencontre
EncounterType
Classification de la visite du patient, par exemple hospitalisation ou urgence.
Description

Cet attribut catégorise la nature de l’épisode patient. Les valeurs courantes incluent « Emergency », « Inpatient », « Outpatient » et « Virtual ».

Associé à « CaseType », ce champ est fondamental pour filtrer l’analyse. Par exemple, le Dashboard Discharge Planning concerne principalement les rencontres en hospitalisation, tandis que le triage est propre aux urgences.

Pourquoi c’est important

Il fournit le contexte général de l’instance de processus.

Où les obtenir

Table Epic Clarity : PAT_ENC, colonne : ENC_TYPE_C

Exemples
UrgencesSoins ambulatoires hospitaliersHospitalisation complète
Coût de la demande diagnostique
DiagnosticOrderCost
Coût interne associé à un examen ou à une procédure diagnostique.
Description

Cet attribut attribue une valeur financière aux activités « Test diagnostique réalisé ». Il permet d’ajouter une dimension financière à la cartographie du processus.

Même s’il ne s’agit pas d’un indicateur clinique principal, il aide l’administration à comprendre le poids financier des différentes variantes de processus, notamment celles associées à des scores de gravité nécessitant beaucoup de ressources.

Pourquoi c’est important

Il ajoute une dimension financière à l’analyse de l’efficacité des processus.

Où les obtenir

Tables de facturation ou de comptabilité analytique associées à la procédure.

Exemples
150.001200.0045.00
Durée d’attente du transfert
TransferWaitDuration
Temps écoulé entre la demande de transfert et le transfert effectif.
Description

Cette mesure évalue l’écart entre « Transfert demandé » et « Patient transféré ». Elle constitue le principal indicateur de l’Internal Ward Transfer Analysis.

Des valeurs élevées indiquent une situation de « boarding », c’est-à-dire des patients en attente d’un lit, ce qui bloque le flux en amont depuis le service des urgences.

Pourquoi c’est important

Il met en évidence les goulots d’étranglement logistiques et liés à la capacité dans le parcours du patient.

Où les obtenir

Différence d’horodatage calculée entre les événements de demande et de transfert.

Exemples
2 h 30 min45 min12 h
Méthode de planification
SchedulingMethod
Indique la manière dont le rendez-vous de suivi a été pris.
Description

Cet attribut enregistre le canal utilisé pour prendre les rendez-vous, par exemple « MyChart », « Cadence Auto » ou « Front Desk ». Il est essentiel pour le Dashboard Outpatient Follow Up Automation Status.

Si la valeur indique un canal numérique géré par le système ou le patient, l’indicateur « IsAutomated » peut être défini sur true. Il met en évidence les résultats des initiatives de transformation numérique.

Pourquoi c’est important

Il suit l’adoption des outils automatisés ou en libre-service.

Où les obtenir

Consultez la documentation Epic EHR pour connaître la source de création des rendez-vous.

Exemples
MyChartCadenceTéléphoneEn personne
Nom de la région
RegionName
Région géographique ou campus hospitalier.
Description

Pour les systèmes de santé qui regroupent plusieurs campus, cet attribut identifie le site de l’établissement. Il permet de comparer les performances des différents sites hospitaliers.

Son association à « Region » permet une comparaison multi-sites afin de déterminer si un hôpital gère mieux le Triage Throughput qu’un autre.

Pourquoi c’est important

Il permet de comparer les performances des différents établissements d’un réseau de santé.

Où les obtenir

Dérivé des données de référence du service ou de l’établissement.

Exemples
Campus NordCentre-villeAile Ouest
Planification automatisée
IsAutomatedScheduling
Indicateur précisant si la planification a été effectuée sans intervention du personnel.
Description

Cet attribut booléen est dérivé de la méthode de planification. Si le rendez-vous a été pris via MyChart ou un flux de travail Cadence automatisé, sa valeur est True.

Il contribue directement à l’indicateur de taux d’automatisation de la planification des rendez-vous de suivi. Il aide les responsables opérationnels à comprendre quelle part de la charge administrative est transférée à la technologie.

Pourquoi c’est important

Il mesure la réussite de l’automatisation du processus.

Où les obtenir

Dérivé de SchedulingMethod.

Exemples
truefalse
Spécialité du prescripteur
OrderingProviderSpecialty
Spécialité médicale du médecin demandant une consultation ou un examen.
Description

Cet attribut enregistre le service ou la spécialité, par exemple « Cardiologie » ou « Oncologie », du prescripteur. Il est utilisé dans le Dashboard Specialist Consultation Latency.

Il permet d’analyser si certaines spécialités connaissent des temps d’attente plus longs que d’autres pour les services internes, et de mettre en évidence d’éventuels biais ou manques de ressources dans certaines filières de soins.

Pourquoi c’est important

Il segmente la demande de services diagnostiques et de consultation.

Où les obtenir

Consultez la documentation Epic EHR pour connaître les données de référence des professionnels de santé.

Exemples
CardiologieMédecine interneOrthopédie
Statut de respect du protocole
ProtocolAdherenceStatus
Statut indiquant si le cas a suivi le parcours clinique standard.
Description

Cet attribut compare la séquence des activités du cas à un modèle de référence défini, c’est-à-dire une procédure opératoire standard. Il alimente la Clinical Protocol Compliance View.

Les valeurs peuvent inclure « Compliant », « Skipped Step » ou « Out of Sequence ». Les responsables cliniques peuvent ainsi filtrer rapidement les cas non conformes sans examiner manuellement chaque cartographie de processus.

Pourquoi c’est important

Il identifie rapidement les écarts par rapport aux standards de soins fondés sur les données probantes.

Où les obtenir

Calculé dans l’outil de Process Mining ou prétraité en SQL.

Exemples
ConformeDéviantIncomplet
Obligatoire Recommandé Facultatif

Activités du parcours patient

Voici les étapes essentielles du processus et les jalons de prise en charge à enregistrer dans votre journal d’événements pour découvrir précisément vos parcours cliniques.
4 Recommandé 11 Facultatif
Activité Description
Diagnostic confirmé
Saisie d’un diagnostic confirmé dans la liste des problèmes du patient ou dans le champ de diagnostic de la consultation. Cet événement marque la conclusion de la phase d’investigation.
Pourquoi c’est important

Nécessaire à l’indicateur KPI « Time to Definitive Diagnosis ». Marque le passage de l’évaluation au traitement ciblé.

Où les obtenir

Table PAT_ENC_DX ou mise à jour de PROBLEM_LIST associée à la consultation.

Collecte

Enregistré lorsque le clinicien ajoute une entrée à l’activité Encounter Diagnosis

Type d’événement explicit
Patient enregistré
Création initiale de l’enregistrement de la consultation du patient dans le système, marquant le début de l’épisode de soins. Cet événement est explicitement enregistré lorsque le patient arrive au bureau des admissions ou aux urgences et est enregistré dans Epic.
Pourquoi c’est important

Établit le point d’ancrage de l’ensemble du parcours patient et permet de calculer la durée totale de séjour. Indispensable au Dashboard « Triage Throughput and Wait Times ».

Où les obtenir

Flux ADT (événement A04 ou A01) ou table Clarity PAT_ENC (création de HSP_ACCOUNT_ID).

Collecte

Enregistré lors de l’exécution de la transaction « Check In » ou « Admit »

Type d’événement explicit
Patient sorti
Clôture officielle de la consultation d’hospitalisation. Cet événement est enregistré lorsque le patient est retiré du recensement.
Pourquoi c’est important

Fin officielle de l’épisode pour le calcul de la durée de séjour. Indispensable à la « Patient Flow Variant Discovery ».

Où les obtenir

Flux ADT (événement A03) ou PAT_ENC_HSP.DISCH_TIME.

Collecte

Enregistré lorsque le personnel administratif termine le flux de travail de sortie

Type d’événement explicit
Triage terminé
Achèvement de l’évaluation infirmière initiale ou de l’évaluation de triage. Cet événement est généralement enregistré lorsque la feuille de triage est validée ou que le statut du triage passe à « Complete ».
Pourquoi c’est important

Indispensable au Dashboard « Triage Throughput and Wait Times » pour mesurer l’efficacité de l’accueil. Les retards à cette étape se répercutent sur l’ensemble du parcours de soins.

Où les obtenir

PAT_ENC_HSP.TRIAGE_END_TIME ou horodatage de la validation d’une ligne précise de la Flowsheet (FLO_MEASUREMENT).

Collecte

Enregistré lorsque la documentation du triage est signée ou que le champ de statut est mis à jour

Type d’événement explicit
Consultation demandée
Prescription demandant à un spécialiste d’évaluer le patient. Cet événement est enregistré dans Epic comme un type précis de prescription de procédure, « Consult ».
Pourquoi c’est important

Point de départ de l’indicateur KPI « Specialist Consultation Lead Time ». Aide à repérer les pénuries dans certaines spécialités médicales.

Où les obtenir

ORDER_PROC où ORDER_CLASS = « Consult » ou prescriptions d’orientation spécifiques.

Collecte

Enregistré lorsque la demande de consultation est signée

Type d’événement explicit
Consultation terminée
Achèvement de l’évaluation par le spécialiste, généralement marqué par la signature d’une Consult Note ou la clôture de la demande de consultation.
Pourquoi c’est important

Point final de « Specialist Consultation Lead Time ». Indique que l’avis spécialisé a été fourni et que le plan de soins peut se poursuivre.

Où les obtenir

HNO_NOTE_TEXT (note enregistrée avec le type Consult) ou changement du statut de ORDER_PROC à Completed.

Collecte

Déduit de l’heure de création de la Consult Note ou de la mise à jour du statut de la prescription

Type d’événement inferred
Examen diagnostique prescrit
Saisie d’une prescription d’imagerie (Radiology) ou de services de laboratoire. Cet événement est enregistré lorsqu’un médecin saisit et signe une prescription dans le système CPOE.
Pourquoi c’est important

Point de départ du Dashboard « Diagnostic Service Cycle Times ». Des volumes élevés à cette étape sans résultats correspondants indiquent la présence de goulots d’étranglement.

Où les obtenir

Table ORDER_PROC où ORDER_TYPE correspond à Lab ou Imaging/Radiology.

Collecte

Enregistré lorsque le statut de la prescription devient « Signed » ou « Active »

Type d’événement explicit
Examen diagnostique réalisé
Réalisation effective de l’examen diagnostique ou validation du résultat. Pour les analyses de laboratoire, il s’agit du traitement de l’échantillon ; pour l’imagerie, de la fin de l’examen.
Pourquoi c’est important

Point final de l’indicateur KPI « Mean Diagnostic Test Cycle Time ». Essentiel pour comprendre les retards des services d’aide à la décision clinique.

Où les obtenir

ORDER_PROC.PROC_END_TIME ou ORDER_STAT_HISTORY lorsque le statut passe à « Completed » ou « Resulted ».

Collecte

Enregistré lorsque le technicien termine la tâche ou que l’interface de résultats reçoit les données

Type d’événement explicit
Médicament administré
Administration d’un médicament au patient par un infirmier ou un professionnel de santé. Cet événement est enregistré dans le Medication Administration Record (MAR).
Pourquoi c’est important

Événement central du Dashboard « Medication Delivery Performance ». Suit le respect du « Treatment Plan Developed ».

Où les obtenir

Table MAR_ADMIN_INFO, notamment les événements dont l’action est « Given » ou « New Bag ».

Collecte

Enregistré lorsque l’infirmier scanne le bracelet du patient et le médicament (BCMA)

Type d’événement explicit
Patient transféré
Déplacement physique du patient vers un nouveau service ou une nouvelle unité. Cet événement est enregistré par les événements de transfert ADT.
Pourquoi c’est important

Point final de l’indicateur « Average Inter-Ward Transfer Time ». Alimente l’« Internal Ward Transfer Analysis » pour repérer les goulots d’étranglement de la logistique hospitalière.

Où les obtenir

Flux ADT (événement A02) ou PAT_ENC_HSP_TRANSACTION (Transfer In).

Collecte

Enregistré lorsque le secrétaire d’unité met à jour l’emplacement du patient dans Census

Type d’événement explicit
Plan de soins initié
Attribution au patient d’un parcours clinique ou d’un protocole précis. Cet événement est enregistré lorsqu’un Order Set ou un Care Plan standard est appliqué au contexte de la consultation.
Pourquoi c’est important

Alimente la « Clinical Protocol Compliance View » en marquant l’intention de suivre un standard de soins. Les écarts par rapport aux étapes planifiées suivantes peuvent être mesurés à partir de ce point.

Où les obtenir

Tables ORDER_SET_BKG ou de Care Plan indiquant qu’un protocole a été associé à la consultation.

Collecte

Enregistré lorsque le clinicien sélectionne et signe un Order Set

Type d’événement explicit
Préparation de la sortie initiée
Début des activités de préparation de la sortie du patient. Cet événement est enregistré dans la documentation de Case Management ou au moyen de types de prescriptions « Discharge » spécifiques.
Pourquoi c’est important

Essentiel au Dashboard « Discharge Planning and Execution ». Une initiation précoce est corrélée à une réduction de la durée de séjour.

Où les obtenir

Création de HSP_DISCH_PLAN ou première note du Case Manager ou du Social Worker.

Collecte

Déduit de la première interaction avec le Discharge Navigator ou de la note de Case Mgmt

Type d’événement inferred
Prescription de sortie signée
Autorisation officielle donnée par le médecin pour que le patient quitte l’hôpital. Il s’agit d’une prescription spécifique saisie dans Epic.
Pourquoi c’est important

Étape essentielle de « Discharge Planning and Execution ». L’écart entre cette étape et le départ effectif représente le retard administratif.

Où les obtenir

ORDER_PROC dont le type est « Discharge Patient ».

Collecte

Enregistré lorsque le médecin signe la prescription de sortie

Type d’événement explicit
Rendez-vous de suivi planifié
Réservation d’une future consultation externe pour le patient. Cet événement est enregistré dans le module de planification Cadence, associé au dossier du patient.
Pourquoi c’est important

Alimente le « Follow-up Scheduling Automation Rate ». Garantit la continuité des soins et contribue à prévenir les réadmissions.

Où les obtenir

PAT_ENC_APPT associé à l’identifiant du patient et créé à proximité de l’heure de sortie.

Collecte

Enregistré lorsque le créneau de rendez-vous est confirmé dans Cadence

Type d’événement explicit
Transfert prescrit
Demande de transfert du patient vers une autre unité ou un autre niveau de soins. Cet événement est enregistré dans le système sous la forme d’une « Bed Request » ou d’un « Transfer Order ».
Pourquoi c’est important

Point de départ de l’indicateur « Average Inter-Ward Transfer Time ». Distingue la décision clinique de transférer de la disponibilité logistique d’un lit.

Où les obtenir

ADT_TRANSFER_ORDER ou ORDER_PROC (Bed Request).

Collecte

Enregistré lorsque le médecin saisit la demande de transfert

Type d’événement explicit
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données depuis le DSE Epic

Prêt à commencer ?

Commencez dès aujourd’hui à transformer vos opérations cliniques en appliquant ce modèle à vos données Epic. Notre équipe vous accompagne dans le processus d’extraction afin d’obtenir rapidement des résultats.

Optimisez dès aujourd’hui le parcours de vos patients et réduisez le temps de cycle

Identifiez les goulots d’étranglement cliniques pour réduire le temps de cycle de 30 %.

Démarrer l’essai gratuit

Aucune carte bancaire requise… La configuration ne prend que quelques minutes.