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 une structure détaillée pour la cartographie des `workflows` cliniques dans votre environnement Epic. Il décrit les points de données spécifiques et les jalons d'événements requis pour visualiser l'intégralité du parcours patient de l'admission à la sortie. En suivant ces directives, vous pouvez vous assurer que vos `data` sont structurées pour des informations opérationnelles approfondies et une prestation de soins améliorée.
  • `Attributs` recommandés pour le contexte clinique
  • Jalons clés du processus pour le suivi
  • Guide d'extraction spécifique pour Epic EHR
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs du parcours patient

Ce sont les champs de données recommandés à inclure dans votre `journal d'événements` pour une analyse complète du flux patient et de l'efficacité clinique.
5 Obligatoire 9 Recommandé 7 Facultatif
Nom Descriptionn
Épisode patient
PatientEpisodeId
L'identifiant unique de la rencontre patient spécifique ou de l'épisode de soins.
Descriptionn

L'Épisode Patient sert d'identifiant de case principal pour le Process Mining. Il regroupe tous les event cliniques, administratifs et logistiques liés à une période de care continue, telle qu'un séjour à l'hôpital ou une visite aux urgences. Dans Epic Clarity, cela correspond typiquement au numéro de série de contact (CSN) ou à l'ID de rencontre.

L'analyse de cet attribut permet la reconstruction du parcours patient complet. Il permet l'association des activités de triage, de diagnostic, de traitement et de sortie dans une instance de processus cohérente.

Pourquoi est-ce important ? :

C'est l'élément clé pour lier des événements disparates en un seul cas de processus.

Source des données :

Table Epic Clarity : PAT_ENC, Colonne : PAT_ENC_CSN_ID

Exemples
200459112200459113200459114200459115
Horodatage de l'événement
EventTimestamp
La date et l'heure exactes de l'activité.
Descriptionn

Cet attribut enregistre le moment précis où un event a été loggé dans le système Epic. Il est utilisé pour séquencer les activités et calculer toutes les métriques basées sur la durée, telles que la durée de séjour et les temps de cycle.

La précision de ce champ est indispensable pour identifier les points de blocage. Il prend en charge les dashboards de Débit du Triage et de Temps avant Diagnostic Définitif en fournissant les ancres temporelles pour les points de début et de fin.

Pourquoi est-ce important ? :

Il permet le calcul des temps de cycle, des délais et de l'ordonnancement des processus.

Source des données :

Diverses colonnes horodatage (par exemple, EFFECTIVE_TIME, 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
L'action clinique ou administrative spécifique effectuée.
Descriptionn

Cet attribut capture le nom de l'event se produisant dans le parcours patient, tel que 'Patient enregistré', 'Médicament administré' ou 'Ordre de sortie signé'. Il est l'élément central pour définir le flux de processus.

Dans l'analyse, ce champ forme les nœuds de la cartographie des processus. Il est dérivé de divers codes de transaction et statuts d'ordre dans l'EHR pour créer un journal d'événements compréhensible par l'utilisateur.

Pourquoi est-ce important ? :

Il définit les étapes du processus et facilite la visualisation du workflow.

Source des données :

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

Exemples
Triage terminéTest diagnostique commandéPatient sortiMédicament administré
Dernière mise à jour des données
LastDataUpdate
L'horodatage de l'extraction ou de la dernière actualisation des données.
Descriptionn

Cet attribut indique la dernière fois que l'enregistrement a été traité par le pipeline ETL. Il est distinct du event horodatage et aide à surveiller la fraîcheur des data.

Les analystes l'utilisent pour déterminer si le tableau de bord reflète la réalité en temps réel ou s'il y a un problème de latence des data affectant la précision des KPI comme les Temps d'Attente au Triage.

Pourquoi est-ce important ? :

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

Source des données :

Horodatage du système ETL.

Exemples
2023-10-27T23:59:59Z2023-10-28T06:00:00Z
Système source
SourceSystem
Le système d'enregistrement des `data`, généralement Epic EHR.
Descriptionn

Cet attribut identifie l'origine des data. Bien que principalement 'Epic EHR' pour cette vue, il est utile si les data sont mélangées avec d'autres systèmes comme un LIS (Système d'Information de Laboratoire) séparé ou un système de facturation.

En analyse, il assure la traçabilité des data et aide au dépannage si des event spécifiques semblent manquants ou mal formés par rapport à la source.

Pourquoi est-ce important ? :

Il offre une traçabilité et un contexte pour l'origine des données.

Source des données :

Codé en dur ou dérivé de la configuration de la chaîne de connexion.

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

Cet attribut enregistre l'état de santé confirmé du patient. Il est généralement renseigné lors de l'activité 'Diagnostic Confirmé'.

Il est utilisé pour regrouper les case par condition clinique pour la Vue de Conformité au Protocole Clinique. Le mappage à 'Product' permet aux analystes de voir comment la 'production' de care diffère selon la condition médicale.

Pourquoi est-ce important ? :

Il regroupe les cas par similarité clinique pour l'analyse des protocoles.

Source des données :

Table Epic Clarity : PAT_ENC_DX, Colonne : DX_ID

Exemples
J18.9I21.9E11.9
Heure de fin de l'événement
EventEndTime
Le `horodatage` lorsque l'activité a été terminée.
Descriptionn

Bien que de nombreux event soient instantanés, certaines activités comme 'Test diagnostique effectué' ou 'Consultation terminée' ont une durée. Cet attribut capture le temps d'achèvement.

Il permet le calcul du temps de traitement actif par rapport au temps d'attente. Cela est particulièrement pertinent pour le tableau de bord des Temps de Cycle des Services Diagnostiques.

Pourquoi est-ce important ? :

Il permet le calcul de la durée de l'activité et de l'utilisation des ressources.

Source des données :

Consultez la documentation Epic EHR pour les colonnes d'heure de fin spécifiques dans ORDER_PROC.

Exemples
2023-10-15T09:45:00Z2023-10-16T15:00:00Z
ID du fournisseur
ProviderId
L'identifiant de l'utilisateur ou du collaborateur ayant effectué l'action.u clinicien qui a effectué l'activité.
Descriptionn

Cet attribut capture l'ID unique du membre du personnel responsable de l'event, tel que l'infirmière administrant le médicament ou le médecin signant les ordres de sortie.

Il est associé à l'attribut générique 'Utilisateur' pour analyser la variation des ressources et la charge de travail. Notez que pour les activités automatisées, cela pourrait être un ID d'utilisateur système.

Pourquoi est-ce important ? :

Il permet l'analyse de la variation de performance et de charge de travail parmi le personnel.

Source des données :

Table Epic Clarity : CLARITY_EMP, Colonne : USER_ID

Exemples
EMP10023DOC5592SYSTEM
Indicateur de réadmission
ReadmissionFlag
Indique si le patient est revenu de manière inattendue dans les 30 jours.
Descriptionn

Cet attribut booléen identifie si l'épisode spécifique a été suivi d'une autre admission imprévue pour le même patient dans une fenêtre de 30 jours. Il est le cœur du KPI Taux de Réadmission Imprévue à 30 Jours.

En analyse, cela sert de variable de résultat majeure. Les parcours de processus menant à un indicateur 'True' sont analysés pour trouver les causes profondes dans la phase de planification des sorties.

Pourquoi est-ce important ? :

Il identifie les processus de sortie échoués et les problèmes de qualité des soins.

Source des données :

Calculé via SQL en anticipant les futures rencontres pour le même MRN.

Exemples
truefaux
Modalité de sortie
DischargeDisposition
La destination du patient à sa sortie (Domicile, Établissement de soins de suite et de réadaptation (SSR), Décédé).
Descriptionn

Cet attribut enregistre l'endroit où le patient s'est rendu après avoir quitté l'hôpital. Il est capturé lors de l'activité 'Patient sorti'.

Ceci est impératif pour le tableau de bord de Risque de Réadmission, car les patients sortis vers des Établissements de Soins Infirmiers Qualifiés (ESIQ) ont des profils de réadmission différents de ceux sortis à domicile.

Pourquoi est-ce important ? :

Il contextualise le résultat du processus de soins.

Source des données :

Table Epic Clarity : PAT_ENC, Colonne : DISCH_DISP_C

Exemples
AccueilÉtablissement de soins de suite et de réadaptation (SSR)Soins à domicile
MRN du patient
PatientMrn
Le numéro de dossier médical identifiant le patient.
Descriptionn

Le MRN est l'identifiant unique du patient au sein du système de santé, distinct de l'ID d'épisode. Il permet de suivre l'historique d'un patient à travers plusieurs visites.

Cet attribut est utilisé pour détecter les réadmissions et lier des épisodes distincts pour le tableau de bord de Risque de Réadmission. Il est associé à 'Customer' dans le modèle générique.

Pourquoi est-ce important ? :

Il est indispensable pour identifier les visites répétées et analyser l'historique des patients.

Source des données :

Table Epic Clarity : PATIENT, Colonne : PAT_ID ou PAT_MRN_ID

Exemples
MRN-882910MRN-112003MRN-554211
Niveau d'acuité du triage
TriageAcuityLevel
Le score de gravité attribué au patient lors du triage.
Descriptionn

Cet attribut indique l'urgence de l'état du patient, typiquement sur une échelle (par exemple, niveaux ESI 1-5). Il est capturé pendant l'activité 'Triage terminé'.

Il permet la segmentation dans le tableau de bord 'Intensité des ressources par score de gravité'. Les patients à forte acuité suivent des parcours de processus différents de ceux à faible acuité, et ce champ aide à distinguer ces variantes.

Pourquoi est-ce important ? :

Il segmente le processus en fonction de l'urgence et de la consommation de ressources attendue.

Source des données :

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

Exemples
1 - Resuscitation2 - Emergent3 - Urgent
Nom du service
DepartmentName
L'unité hospitalière ou le service où l'activité a eu lieu.
Descriptionn

Cet attribut identifie l'emplacement fonctionnel de l'event, tel que 'Service des Urgences', 'Radiologie' ou 'Unité de Chirurgie Générale'. Il est impératif pour l'Analyse des Transferts Inter-Services.

Les data sont utilisées pour segmenter la cartographie des processus par service, permettant aux managers d'isoler les points de blocage spécifiques à leur unité par rapport aux problèmes systémiques à l'échelle de l'hôpital.

Pourquoi est-ce important ? :

Il permet un filtrage organisationnel et une analyse des transferts.

Source des données :

Table Epic Clarity : CLARITY_DEP, Colonne : DEPARTMENT_NAME

Exemples
Service des urgencesRadiologyUSIPédiatrie
Type d'épisode de soins
EncounterType
La classification de la visite du patient (par exemple, Hospitalisation, Urgences).
Descriptionn

Cet attribut catégorise la nature de l'épisode patient. Les valeurs courantes incluent 'Urgence', 'Hospitalisation', 'Ambulatoire' ou 'Virtuel'.

Mappé à 'CaseType', ce champ est indispensable pour filtrer l'analyse. Par exemple, le tableau de bord de Planification des Sorties est principalement pertinent pour les rencontres en hospitalisation, tandis que le Triage est spécifique aux urgences.

Pourquoi est-ce important ? :

Il fournit le contexte de haut niveau pour l'instance de processus.

Source des données :

Table Epic Clarity : PAT_ENC, Colonne : ENC_TYPE_C

Exemples
UrgencePatient externe hospitalierPatient hospitalisé
Coût de l'ordre diagnostique
DiagnosticOrderCost
Le coût interne associé à un test diagnostique ou une procédure.
Descriptionn

Cet attribut attribue une valeur financière aux activités de 'Test diagnostique effectué'. Il permet une superposition financière sur la cartographie des processus.

Bien que n'étant pas un indicateur clinique primaire, il aide l'administration à comprendre le poids financier des différentes variantes de processus, en particulier celles impliquant des scores de gravité à forte consommation de ressources.

Pourquoi est-ce important ? :

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

Source des données :

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

Exemples
150.001200.0045.00
Durée d'attente du transfert
TransferWaitDuration
Temps écoulé entre un ordre de transfert et le transfert réel.
Descriptionn

Cette métrique mesure l'écart entre 'Transfert ordonné' et 'Patient transféré'. C'est le point de data principal pour l'Analyse des Transferts Inter-Services.

Des valeurs élevées ici indiquent l'encombrement (patients en attente de lits), ce qui bloque le flux en amont du service des urgences.

Pourquoi est-ce important ? :

Il met en évidence les points de blocage logistiques et de capacité dans le flux patient.

Source des données :

Différence d'horodatage calculée entre les événements d'ordre et de transfert.

Exemples
2h 30m45m12h
Est-ce une planification automatisée
IsAutomatedScheduling
Indicateur signalant si la planification a été effectuée sans intervention du personnel.
Descriptionn

Cet attribut booléen est dérivé de la Méthode de Planification. Si le rendez-vous a été pris via MyChart ou un workflow Cadence automatisé, c'est True.

Il contribue directement au le KPI Taux d'Automatisation de la Planification du Suivi. Cela aide les leaders opérationnels à comprendre la part de la charge administrative transférée à la technologie.

Pourquoi est-ce important ? :

Il mesure le succès de l'automatisation des processus.

Source des données :

Dérivé de SchedulingMethod.

Exemples
truefaux
Méthode de prise de rendez-vous
SchedulingMethod
Indique comment le rendez-vous de suivi a été réservé.
Descriptionn

Cet attribut capture le canal utilisé pour prendre les rendez-vous, tel que 'MyChart', 'Cadence Auto' ou 'Guichet d'accueil'. Il est indispensable pour le tableau de bord de Statut d'Automatisation du Suivi Ambulatoire.

Si la valeur indique un système ou un canal numérique piloté par le patient, le drapeau 'IsAutomated' peut être défini sur vrai. Cela met en évidence le succès des initiatives de transformation numérique.

Pourquoi est-ce important ? :

Il suit l'adoption d'outils automatisés ou en self-service.

Source des données :

Consultez la documentation Epic EHR pour la source de création de rendez-vous.

Exemples
MyChartCadenceTéléphoneEn personne
Nom Région
RegionName
La région géographique ou le campus hospitalier.
Descriptionn

Pour les systèmes de santé avec plusieurs campus, cet attribut identifie l'emplacement de l'établissement. Il permet de comparer les performances entre différents sites hospitaliers.

Le mappage à la 'Région' permet le benchmarking multi-sites pour voir si un hôpital gère mieux le débit de triage qu'un autre.

Pourquoi est-ce important ? :

Il permet le benchmarking entre différents établissements d'un réseau de santé.

Source des données :

Dérivé des données de référence du Service ou de l'Établissement.

Exemples
Campus NordCentre-villeAile ouest
Spécialité du prescripteur
OrderingProviderSpecialty
La spécialité médicale du médecin demandant une consultation ou un test.
Descriptionn

Cet attribut capture le service ou la spécialité (par exemple, 'Cardiologie', 'Oncologie') du prestataire prescripteur. Il est utilisé dans le tableau de bord de Latence des Consultations Spécialisées.

Il aide à analyser si certaines spécialités sont confrontées à des temps d'attente plus longs pour les services internes que d'autres, révélant un biais potentiel ou des pénuries de ressources dans des lignes de service spécifiques.

Pourquoi est-ce important ? :

Il segmente la demande pour les services de diagnostic et de consultation.

Source des données :

Consultez la documentation Epic EHR pour les données de référence des fournisseurs.

Exemples
CardiologieMédecine interneOrthopédie
Statut de `Conformité` au protocole
ProtocolAdherenceStatus
Statut indiquant si le cas a suivi le parcours clinique standard.
Descriptionn

Cet attribut compare la séquence d'activités du case à un modèle de référence défini (Procédure Opérationnelle Standard). Il soutient la Vue de Conformité au Protocole Clinique.

Les valeurs peuvent inclure 'Conforme', 'Étape ignorée' ou 'Hors séquence'. Cela permet aux responsables cliniques de filtrer rapidement les case non conformes sans inspecter manuellement chaque cartographie de processus.

Pourquoi est-ce important ? :

Il identifie rapidement les écarts par rapport aux normes de soins basées sur des preuves.

Source des données :

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

Exemples
ConformeDéviantIncomplet
Obligatoire Recommandé Facultatif

Activités du parcours patient

Ce sont les étapes de processus et les jalons de soins essentiels à capturer dans votre `journal d'événements` pour une découverte précise de vos parcours cliniques.
4 Recommandé 11 Facultatif
Activité Descriptionn
Diagnostic confirmé
L'enregistrement d'un diagnostic confirmé dans la liste de problèmes du patient ou le champ de diagnostic de la rencontre. Représente la conclusion de la phase d'investigation.
Pourquoi est-ce important ? :

Requis pour le KPI 'Temps avant le diagnostic définitif'. Marque la transition de l'évaluation au traitement ciblé.

Source des données :

Table PAT_ENC_DX ou mise à jour de PROBLEM_LIST liée à la rencontre.

Capture

Comptabilisé lorsqu'un clinicien ajoute une entrée à l'activité Diagnostic de rencontre

Type d'événement explicit
Patient enregistré
La création initiale du dossier de rencontre patient dans le système, marquant le début de l'épisode de soins. Ceci est explicitement enregistré lorsqu'un patient arrive au guichet d'enregistrement ou au service d'urgence et est enregistré dans Epic.
Pourquoi est-ce important ? :

Établit le point d'ancrage pour l'ensemble du parcours patient et permet le calcul de la durée totale du séjour. Primordial pour le tableau de bord (tableau de bord) 'Débit de triage et temps d'attente'.

Source des données :

Flux ADT (Événement A04 ou A01) ou table Clarity PAT_ENC (création de l'ID de compte HSP).

Capture

Comptabilisé lorsque la transaction 'Check In' ou 'Admit' est exécutée

Type d'événement explicit
Patient sorti
La clôture officielle de la rencontre en hospitalisation. Comptabilisée lorsque le patient est virtuellement sorti du recensement.
Pourquoi est-ce important ? :

La fin formelle de l'épisode pour les calculs de 'Durée de Séjour'. Primordial pour la 'Découverte de variantes de flux patients'.

Source des données :

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

Capture

Comptabilisé lorsque le personnel administratif termine le workflow de sortie

Type d'événement explicit
Triage terminé
L'achèvement de l'évaluation infirmière initiale ou de l'évaluation du triage. Ceci est généralement enregistré lorsque la feuille de flux de triage est classée ou que le statut de triage passe à 'Complet'.
Pourquoi est-ce important ? :

Critique pour le tableau de bord (tableau de bord) 'Débit de triage et temps d'attente' afin de mesurer l'efficacité de l'accueil. Les retards ici se répercutent sur l'ensemble du parcours de soins.

Source des données :

PAT_ENC_HSP.TRIAGE_END_TIME ou horodatage de l'enregistrement d'une ligne spécifique de la feuille de flux (FLO_MEASUREMENT).

Capture

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

Type d'événement explicit
Consultation demandée
Un ordre est placé pour qu'un spécialiste évalue le patient. Comptabilisé comme un type d'ordre de procédure spécifique 'Consult' au sein d'Epic.
Pourquoi est-ce important ? :

Point de départ pour le KPI 'Délai de consultation spécialiste'. Aide à identifier les pénuries dans des spécialités médicales spécifiques.

Source des données :

ORDER_PROC où ORDER_CLASS = 'Consultation' ou ordres de référence spécifiques.

Capture

Comptabilisé lorsque l'ordre de consultation est signé

Type d'événement explicit
Consultation terminée
L'achèvement de l'évaluation spécialisée, généralement marqué par la signature d'une note de consultation ou la clôture de l'ordre de consultation.
Pourquoi est-ce important ? :

Point final pour le 'Délai de consultation spécialiste'. Indique que l'avis d'expert a été fourni et que le plan de soins peut se poursuivre.

Source des données :

HNO_NOTE_TEXT (Note classée avec le type Consult) ou changement de statut ORDER_PROC à Terminé.

Capture

Déduit de l'heure de création de la note de consultation ou de la mise à jour du statut de la commande.

Type d'événement inferred
Médicament administré
L'acte d'une infirmière ou d'un prestataire administrant des médicaments au patient. Comptabilisé dans le Dossier d'Administration des Médicaments (DAM).
Pourquoi est-ce important ? :

Événement clé pour le tableau de bord (tableau de bord) 'Performance de la livraison des médicaments'. Il suit l'adhésion au 'Plan de traitement développé'.

Source des données :

Table MAR_ADMIN_INFO, spécifiquement les événements avec l'action 'Donné' ou 'Nouvelle poche'.

Capture

Comptabilisé lorsque l'infirmière scanne le bracelet du patient et le médicament (BCMA)

Type d'événement explicit
Ordonnance de sortie signée
L'autorisation formelle du médecin pour que le patient quitte l'hôpital. Il s'agit d'une entrée d'ordre spécifique dans Epic.
Pourquoi est-ce important ? :

Un jalon critique dans la 'Planification et exécution de la sortie'. L'écart entre ce moment et le départ effectif représente un décalage administratif.

Source des données :

ORDER_PROC où le type est 'Sortie patient'.

Capture

Comptabilisé lorsque le médecin signe l'ordre de sortie

Type d'événement explicit
Patient transféré
Le mouvement physique du patient vers un nouveau service ou une nouvelle unité. Capturé via les `event` de transfert ADT.
Pourquoi est-ce important ? :

Point final pour le 'Temps moyen de transfert inter-service'. Soutient l''Analyse des transferts internes entre services' pour trouver les points de blocage (points de blocage) dans la logistique hospitalière.

Source des données :

Flux ADT (Événement A02) ou PAT_ENC_HSP_TRANSACTION (Transfert entrant).

Capture

Comptabilisé lorsque le commis d'unité met à jour l'emplacement du patient dans le recensement

Type d'événement explicit
Plan de soins initié
L'attribution d'un parcours clinique ou d'un protocole spécifique au patient. Ceci est enregistré lorsqu'un jeu d'ordres standard ou un plan de soins est appliqué au contexte de la rencontre.
Pourquoi est-ce important ? :

Soutient la 'Vue de Conformité au protocole clinique' en marquant l'intention de suivre une norme de soins. Les écarts par rapport aux étapes planifiées subséquentes peuvent être mesurées à partir de ce point.

Source des données :

Tables ORDER_SET_BKG ou de plan de soins indiquant qu'un protocole a été lié à la rencontre.

Capture

Comptabilisé lorsqu'un clinicien sélectionne « what-if »gne un ensemble d'ordres

Type d'événement explicit
Planification de la sortie initiée
Le début des activités de prélèvement.paration à la sortie du patient. Capturé via la documentation de gestion de cas ou des types d'ordres de 'sortie' spécifiques.
Pourquoi est-ce important ? :

Clé pour le tableau de bord (tableau de bord) 'Planification et exécution de la sortie'. Une initiation précoce est corrélée à une durée de séjour réduite.

Source des données :

Création de HSP_DISCH_PLAN ou première note par le gestionnaire de cas/travailleur social.

Capture

Déduit de la première interaction avec le navigateur de sortie ou de la note de gestion de cas.

Type d'événement inferred
Rendez-vous de suivi planifié
La prise de rendez-vous pour une future visite ambulatoire du patient. Comptabilisée dans le module de planification Cadence lié au dossier patient.
Pourquoi est-ce important ? :

Soutient le 'Taux d'automatisation de la planification du suivi'. Assure la continuité des soins et aide à prévenir les réadmissions.

Source des données :

PAT_ENC_APPT lié à l'identifiant du patient, créé à l'approche de l'heure de sortie.

Capture

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

Type d'événement explicit
Test diagnostique commandé
L'entrée d'un ordre pour l'imagerie (Radiologie) ou les services de laboratoire. Capturé lorsqu'un médecin entre « what-if »gne un ordre dans le système CPOE.
Pourquoi est-ce important ? :

Le point de départ du tableau de bord 'Temps de cycle des services diagnostiques'. Des volumes élevés sans résultats correspondants indiquent des points de blocage.

Source des données :

Table ORDER_PROC où ORDER_TYPE est Labo ou Imagerie/Radiologie.

Capture

Comptabilisé lorsque le statut de la commande devient 'Signé' ou 'Actif'

Type d'événement explicit
Test diagnostique effectué
L'exécution réelle du test diagnostique ou l'enregistrement du résultat. Pour les laboratoires, c'est lorsque l'échantillon est traité ; pour l'imagerie, lorsque le scan est terminé.
Pourquoi est-ce important ? :

Point final pour le KPI 'Temps de cycle moyen des tests diagnostiques'. Vital pour comprendre les retards dans les services de support à la décision clinique.

Source des données :

ORDER_PROC.PROC_END_TIME ou ORDER_STAT_HISTORY lorsque le statut passe à 'Terminé' ou 'Résultat obtenu'.

Capture

Comptabilisé lorsque le technicien termine la tâche ou que l'interface de résultat reçoit les données.

Type d'événement explicit
Transfert ordonné
Une demande de transfert du patient vers une autre unité ou un autre niveau de soins. Comptabilisée comme une 'Demande de lit' ou un 'Ordre de transfert' dans le système.
Pourquoi est-ce important ? :

Point de départ pour le 'Temps moyen de transfert inter-services'. Différencie la décision clinique de transfert de la disponibilité logistique d'un lit.

Source des données :

ADT_TRANSFER_ORDER ou ORDER_PROC (Demande de lit).

Capture

Comptabilisé lorsque le médecin saisit l'ordre de transfert

Type d'événement explicit
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos `données` d'Epic EHR