Votre modèle de données pour le parcours du patient
Votre modèle de données pour le parcours du patient
- Attributs recommandés pour le contexte clinique
- Jalons clés du processus à suivre
- Consignes d’extraction spécifiques à Epic EHR
Attributs du parcours du patient
| Nom | Description | ||
|---|---|---|---|
| Épisode du patient PatientEpisodeId | Identifiant unique de la rencontre ou de l’épisode de soins du patient. | ||
| Description L’épisode du patient sert d’identifiant principal du cas pour le Process Mining. Il regroupe tous les événements cliniques, administratifs et logistiques liés à une période de soins continue, comme 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 permet d’associer les activités de triage, de diagnostic, de traitement et de sortie au sein d’une même instance de processus. Pourquoi est-ce important ? Il s’agit de la clé fondamentale qui permet de relier des événements distincts au sein d’un même cas de processus. Où trouver ces données 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é a eu lieu. | ||
| 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 toutes les métriques de durée, comme la durée de séjour et les temps de cycle. La précision de ce champ est essentielle pour repérer les goulots d’étranglement. Il alimente les Dashboards sur le débit du triage et le délai jusqu’au diagnostic définitif, en fournissant les repères temporels de début et de fin. Pourquoi est-ce important ? Il permet de calculer les temps de cycle, les délais et l’ordre des étapes du processus. Où trouver ces données Différentes colonnes d’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 | Action clinique ou administrative réalisée. | ||
| Description Cet attribut indique le nom de l’événement survenu dans le parcours du patient, par exemple « Patient enregistré », « Médicament administré » ou « Ordre de sortie signé ». Il constitue l’élément central qui définit le flux du processus. Dans l’analyse, ce champ fournit les nœuds de la cartographie du processus. Il est dérivé de différents codes de transaction et statuts d’ordonnance du dossier médical électronique afin de produire un journal d’événements lisible. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser le flux de travail. Où trouver ces données 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 des données ou de leur dernière actualisation. | ||
| Description Cet attribut indique la dernière date de traitement de l’enregistrement par le pipeline ETL. Il est distinct de l’horodatage de l’événement et permet de surveiller la fraîcheur des données. Les analystes s’en servent pour vérifier si le Dashboard reflète la situation actuelle ou si un décalage dans les données nuit à la précision d’indicateurs clés comme les temps d’attente au triage. Pourquoi est-ce important ? Il permet d’évaluer l’actualité et la fiabilité des données de Process Mining. Où trouver ces données 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 dossier médical électronique Epic. | ||
| Description Cet attribut indique l’origine des données. Il s’agit principalement d’Epic EHR dans cette vue, mais il est utile lorsque les données sont combinées à celles d’autres systèmes, comme un système LIS distinct (système d’information de laboratoire) ou un système de facturation. Dans l’analyse, il assure la traçabilité des données et facilite le diagnostic des problèmes lorsque certains événements semblent absents ou mal formés par rapport à la source. Pourquoi est-ce important ? Il assure la traçabilité et précise l’origine des données. Où trouver ces données Valeur codée en dur ou dérivée de la configuration de la chaîne de connexion. Exemples Dossier médical électronique EpicEpic ClarityEpic Caboodle | |||
| Code du diagnostic principal PrimaryDiagnosisCode | Code CIM-10 ou code interne correspondant au diagnostic principal. | ||
| Description Cet attribut enregistre l’affection confirmée du patient. Il est généralement renseigné lors de l’activité « Diagnostic confirmé ». Il sert à regrouper les cas par affection clinique dans la vue sur la conformité aux protocoles cliniques. Associé à « Produit », il permet aux analystes de comparer la prise en charge selon l’affection médicale. Pourquoi est-ce important ? Il regroupe les cas présentant des similitudes cliniques pour analyser le respect des protocoles. Où trouver ces données Table Epic Clarity : PAT_ENC_DX, colonne : DX_ID Exemples J18.9I21.9E11.9 | |||
| Destination après la sortie DischargeDisposition | Destination du patient après sa sortie (domicile, établissement de soins infirmiers, décès). | ||
| Description Cet attribut indique où le patient s’est rendu après avoir quitté l’hôpital. Il est enregistré lors de l’activité « Patient sorti ». Il est important pour le Dashboard sur le risque de réadmission, car les profils de réadmission diffèrent entre les patients qui rejoignent un établissement de soins infirmiers et ceux qui rentrent chez eux. Pourquoi est-ce important ? Il apporte un contexte au résultat du processus de soins. Où trouver ces données Table Epic Clarity : PAT_ENC, colonne : DISCH_DISP_C Exemples DomicileÉtablissement de soins infirmiersSoins à domicile | |||
| Heure de fin de l’événement EventEndTime | Horodatage de fin de l’activité. | ||
| Description De nombreux événements sont instantanés, mais certaines activités, comme « Examen diagnostique réalisé » ou « Consultation terminée », ont une durée. Cet attribut enregistre leur heure de fin. Il permet de calculer le temps de traitement actif et le temps d’attente. Il est particulièrement utile pour le Dashboard sur les temps de cycle des services de diagnostic. Pourquoi est-ce important ? Il permet de calculer la durée des activités et l’utilisation des ressources. Où trouver ces données Consultez la documentation Epic EHR pour connaître les colonnes d’heure de fin propres à ORDER_PROC. Exemples 2023-10-15T09:45:00Z2023-10-16T15:00:00Z | |||
| Identifiant du professionnel ProviderId | Identifiant de l’utilisateur ou du professionnel de santé 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 ou l’infirmière qui administre un médicament ou le médecin qui signe les ordres de sortie. Il est associé à l’attribut générique « Utilisateur » pour analyser les variations entre les ressources et leur charge de travail. Pour les activités automatisées, il peut s’agir de l’identifiant d’un utilisateur système. Pourquoi est-ce important ? Il permet d’analyser les écarts de performance et de charge de travail entre les membres du personnel. Où trouver ces 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 imprévue dans les 30 jours. | ||
| Description Cet attribut booléen indique si l’épisode a été suivi d’une autre admission non planifiée du même patient dans un délai de 30 jours. Il constitue la base de l’indicateur de performance clé du taux de réadmission non planifiée à 30 jours. Dans l’analyse, il s’agit d’une variable de résultat majeure. Les parcours de processus associés à la valeur « vrai » sont étudiés afin de repérer les causes profondes liées à la planification de la sortie. Pourquoi est-ce important ? Il permet de repérer les sorties mal préparées et les problèmes de qualité des soins. Où trouver ces données Calculé en SQL en recherchant les rencontres ultérieures associées au même MRN. Exemples truefalse | |||
| Niveau de gravité au 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 de segmenter les données dans le Dashboard sur l’intensité des ressources selon le score de gravité. Les patients dont l’état est plus grave suivent des parcours différents de ceux dont l’état est moins grave ; ce champ permet de distinguer ces variantes. Pourquoi est-ce important ? Il segmente le processus selon le degré d’urgence et la consommation de ressources prévue. Où trouver ces données Consultez la documentation Epic EHR pour connaître le champ de gravité dans les journaux des urgences. Exemples 1 - Réanimation2 - Urgence vitale3 - Urgent | |||
| Nom du service DepartmentName | Unité ou service hospitalier où l’activité a eu lieu. | ||
| Description Cet attribut indique le lieu fonctionnel de l’événement, par exemple « Urgences », « Radiologie » ou « Service de chirurgie générale ». Il est essentiel à l’analyse des transferts internes entre services. Ces données permettent de segmenter la cartographie du processus par service, afin que les responsables puissent distinguer les goulots d’étranglement propres à leur unité des problèmes touchant l’ensemble de l’hôpital. Pourquoi est-ce important ? Il permet de filtrer les données par service et d’analyser les transferts entre équipes. Où trouver ces données Table Epic Clarity : CLARITY_DEP, colonne : DEPARTMENT_NAME Exemples UrgencesRadiologieICUPédiatrie | |||
| Numéro de dossier médical du patient PatientMrn | Numéro de dossier médical 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 du patient au fil de ses visites. Cet attribut sert à repérer les réadmissions et à relier plusieurs épisodes dans le Dashboard sur le risque de réadmission. Dans le modèle générique, il est associé à « Client ». Pourquoi est-ce important ? Il est essentiel pour repérer les visites répétées et analyser l’historique du patient. Où trouver ces données Table Epic Clarity : PATIENT, colonne : PAT_ID ou PAT_MRN_ID Exemples MRN-882910MRN-112003MRN-554211 | |||
| Type de rencontre EncounterType | Catégorie de la visite du patient (par exemple, hospitalisation ou urgences). | ||
| Description Cet attribut catégorise la nature de l’épisode du patient. Les valeurs courantes comprennent « Urgences », « Hospitalisation », « Consultation ambulatoire » ou « Virtuelle ». Associé à « Type de cas », ce champ est essentiel pour filtrer l’analyse. Par exemple, le Dashboard sur la planification des sorties concerne principalement les hospitalisations, tandis que le triage est propre aux urgences. Pourquoi est-ce important ? Il fournit le contexte général de l’instance de processus. Où trouver ces données Table Epic Clarity : PAT_ENC, colonne : ENC_TYPE_C Exemples UrgencesConsultation ambulatoire à l’hôpitalHospitalisation | |||
| Coût de l’examen diagnostique DiagnosticOrderCost | Coût interne associé à un examen diagnostique ou à une intervention. | ||
| Description Cet attribut associe une valeur financière aux activités « Examen diagnostique réalisé ». Il permet d’ajouter une dimension financière à la cartographie du processus. Sans être une métrique clinique principale, il aide les services administratifs à comprendre le poids financier des différentes variantes du processus, notamment celles qui concernent des patients dont le score de gravité implique une forte mobilisation de ressources. Pourquoi est-ce important ? Il ajoute une dimension financière à l’analyse de l’efficacité du processus. Où trouver ces données Tables de facturation ou de comptabilité analytique associées à l’intervention. Exemples 150.001200.0045.00 | |||
| Durée d’attente avant transfert TransferWaitDuration | Temps écoulé entre l’ordre de transfert et le transfert effectif. | ||
| Description Cette métrique mesure le délai entre « Transfert demandé » et « Patient transféré ». Elle constitue la principale donnée de l’analyse des transferts internes entre services. Des valeurs élevées indiquent que des patients attendent un lit, ce qui bloque le flux en amont depuis les urgences. Pourquoi est-ce important ? Il met en évidence les goulots d’étranglement logistiques et les limites de capacité dans le parcours des patients. Où trouver ces données Calculé à partir de la différence entre les horodatages des événements de demande et de transfert. Exemples 2 h 30 min45 min12 h | |||
| État du respect du protocole ProtocolAdherenceStatus | Indique 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 (procédure opératoire normalisée). Il contribue à la vue sur la conformité aux protocoles cliniques. Les valeurs possibles comprennent « Conforme », « Étape omise » ou « Ordre non respecté ». Les responsables cliniques peuvent ainsi filtrer rapidement les cas non conformes sans examiner manuellement chaque cartographie de processus. Pourquoi est-ce important ? Il permet de repérer rapidement les écarts par rapport aux normes de soins fondées sur des données probantes. Où trouver ces données Calculé dans l’outil de Process Mining ou prétraité en SQL. Exemples ConformeNon conformeIncomplet | |||
| Mode de planification SchedulingMethod | Indique comment le rendez-vous de suivi a été pris. | ||
| Description Cet attribut indique le canal utilisé pour prendre les rendez-vous, par exemple « MyChart », « Cadence automatique » ou « Accueil ». Il est essentiel au Dashboard sur l’état de l’automatisation des rendez-vous de suivi en consultation ambulatoire. Si la valeur correspond à un canal numérique utilisé par le système ou par le patient, l’indicateur « IsAutomated » peut être défini sur vrai. Il met en évidence les résultats des initiatives de transformation numérique. Pourquoi est-ce important ? Il permet de suivre l’adoption des outils automatisés ou en libre-service. Où trouver ces données 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 site hospitalier. | ||
| Description Dans les systèmes de santé qui comptent plusieurs sites, cet attribut indique l’emplacement de l’établissement. Il permet de comparer les résultats entre différents hôpitaux. Associé à « Région », il permet de comparer plusieurs sites et de déterminer si un hôpital gère mieux le débit du triage qu’un autre. Pourquoi est-ce important ? Il permet de comparer les résultats des différents établissements d’un réseau de santé. Où trouver ces données Dérivé des données de référence sur les services ou les établissements. Exemples Site 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é du mode de planification. Si le rendez-vous a été pris via MyChart ou un flux de travail automatisé dans Cadence, sa valeur est « vrai ». Il contribue directement à l’indicateur de performance clé du taux d’automatisation de la planification des rendez-vous de suivi. Il aide les responsables opérationnels à comprendre dans quelle mesure la technologie prend en charge les tâches administratives. Pourquoi est-ce important ? Il mesure le degré d’automatisation du processus. Où trouver ces données Dérivé de SchedulingMethod. Exemples truefalse | |||
| Spécialité du prescripteur OrderingProviderSpecialty | Spécialité médicale du médecin qui demande une consultation ou un examen. | ||
| Description Cet attribut indique le service ou la spécialité du prescripteur, par exemple « Cardiologie » ou « Oncologie ». Il est utilisé dans le Dashboard sur les délais de consultation des spécialistes. Il permet de déterminer si certaines spécialités connaissent des temps d’attente plus longs que d’autres pour accéder aux services internes, et de repérer d’éventuels biais ou un manque de ressources dans certains services. Pourquoi est-ce important ? Il segmente la demande de services de diagnostic et de consultation. Où trouver ces données Consultez la documentation Epic EHR pour connaître les données de référence sur les prescripteurs. Exemples CardiologieMédecine interneOrthopédie | |||
Activités du parcours du patient
| 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 fin de la phase d’investigation. | ||
| Pourquoi est-ce important ? Nécessaire pour l’indicateur « Délai avant le diagnostic définitif ». Marque le passage de l’évaluation au traitement ciblé. Où trouver ces données Table PAT_ENC_DX ou mise à jour de PROBLEM_LIST associée à la consultation. Données à recueillir Enregistré lorsque le clinicien ajoute une entrée à l’activité Encounter Diagnosis Type d’événement explicit | |||
| Patient enregistré | Création initiale du dossier de consultation du patient dans le système, qui marque le début du séjour. Cet événement est enregistré lorsque le patient se présente au bureau d’accueil ou aux urgences et est admis dans Epic. | ||
| Pourquoi est-ce important ? Définit le point de départ de l’ensemble du parcours du patient et permet de calculer la durée totale du séjour. Indispensable au Dashboard « Débit du triage et temps d’attente ». Où trouver ces données Flux ADT (événement A04 ou A01) ou table Clarity PAT_ENC (création de HSP_ACCOUNT_ID). Données à recueillir 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 en hospitalisation. Cet événement est enregistré lorsque le patient est virtuellement retiré du recensement. | ||
| Pourquoi est-ce important ? Marque la fin officielle du séjour pour le calcul de la « Durée de séjour ». Indispensable à la « Découverte des variantes de parcours des patients ». Où trouver ces données Flux ADT (événement A03) ou PAT_ENC_HSP.DISCH_TIME. Données à recueillir Enregistré lorsque le personnel administratif termine le flux de travail de sortie Type d’événement explicit | |||
| Triage terminé | Fin de l’évaluation infirmière initiale ou du triage. Cet événement est généralement enregistré lorsque la feuille de suivi du triage est validée ou que le statut du triage passe à « Complete ». | ||
| Pourquoi est-ce important ? Indispensable au Dashboard « Débit du triage et temps d’attente » pour mesurer l’efficacité de l’accueil. Tout retard à cette étape se répercute sur l’ensemble du parcours de soins. Où trouver ces données PAT_ENC_HSP.TRIAGE_END_TIME ou horodatage de la validation d’une ligne précise de la feuille de suivi (FLO_MEASUREMENT). Données à recueillir 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. Dans Epic, cet événement est enregistré sous le type de procédure « Consult ». | ||
| Pourquoi est-ce important ? Point de départ de l’indicateur « Délai avant la consultation spécialisée ». Aide à repérer les pénuries dans certaines spécialités médicales. Où trouver ces données ORDER_PROC où ORDER_CLASS = « Consult » ou prescriptions d’orientation spécifiques. Données à recueillir Enregistré lorsque la demande de consultation est signée Type d’événement explicit | |||
| Consultation terminée | Fin de l’évaluation par le spécialiste, généralement marquée par la signature d’une note de consultation ou la clôture de la demande. | ||
| Pourquoi est-ce important ? Point final du « Délai avant la consultation spécialisée ». Indique que l’avis du spécialiste a été fourni et que le plan de soins peut se poursuivre. Où trouver ces données HNO_NOTE_TEXT (note enregistrée sous le type Consult) ou changement du statut ORDER_PROC à Completed. Données à recueillir Déduit de l’heure de création de la note de consultation ou de la mise à jour du statut de la prescription Type d’événement inferred | |||
| Examen diagnostique prescrit | Saisie d’une prescription d’imagerie (radiologie) ou d’examens de laboratoire. Cet événement est enregistré lorsqu’un médecin saisit et signe une prescription dans le système CPOE. | ||
| Pourquoi est-ce important ? Point de départ du Dashboard « Temps de cycle des services de diagnostic ». Un volume élevé de prescriptions sans résultats correspondants peut signaler des goulots d’étranglement. Où trouver ces données Table ORDER_PROC où ORDER_TYPE correspond à Lab ou Imaging/Radiology. Données à recueillir Enregistré lorsque le statut de la prescription passe à « Signed » ou « Active » Type d’événement explicit | |||
| Examen diagnostique réalisé | Réalisation effective de l’examen diagnostique ou saisie du résultat. Pour les analyses de laboratoire, l’événement correspond au traitement de l’échantillon ; pour l’imagerie, à la fin de l’examen. | ||
| Pourquoi est-ce important ? Point final de l’indicateur « Temps de cycle moyen des examens diagnostiques ». Essentiel pour comprendre les retards des services d’aide à la décision clinique. Où trouver ces données ORDER_PROC.PROC_END_TIME ou ORDER_STAT_HISTORY lorsque le statut passe à « Completed » ou « Resulted ». Données à recueillir Enregistré lorsque le technicien termine la tâche ou que l’interface reçoit le résultat 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 dossier d’administration des médicaments (MAR). | ||
| Pourquoi est-ce important ? Événement central du Dashboard « Performance de l’administration des médicaments ». Permet de suivre le respect du « Plan de traitement établi ». Où trouver ces données Table MAR_ADMIN_INFO, en particulier les événements dont l’action est « Given » ou « New Bag ». Données à recueillir Enregistré lorsque l’infirmier scanne le bracelet du patient et le médicament (BCMA) Type d’événement explicit | |||
| Ordre de sortie signé | Autorisation officielle du médecin permettant au patient de quitter l’hôpital. Il s’agit d’une prescription spécifique dans Epic. | ||
| Pourquoi est-ce important ? Étape importante de la « Préparation et réalisation de la sortie ». Le délai entre cette étape et le départ effectif correspond au retard administratif. Où trouver ces données ORDER_PROC dont le type est « Discharge Patient ». Données à recueillir Enregistré lorsque le médecin signe l’ordre de sortie Type d’événement explicit | |||
| Patient transféré | Déplacement physique du patient vers un nouveau service ou une autre unité. Cet événement est enregistré dans les données de transfert ADT. | ||
| Pourquoi est-ce important ? Point final du « Temps moyen de transfert entre services ». Alimente l’« Analyse des transferts internes entre services » pour repérer les goulots d’étranglement logistiques à l’hôpital. Où trouver ces données Flux ADT (événement A02) ou PAT_ENC_HSP_TRANSACTION (Transfer In). Données à recueillir Enregistré lorsque l’agent administratif de l’unité met à jour l’emplacement du patient dans Census Type d’événement explicit | |||
| Plan de soins lancé | Affectation au patient d’un parcours clinique ou d’un protocole précis. Cet événement est enregistré lorsqu’un ensemble de prescriptions standard ou un plan de soins est appliqué au contexte de la consultation. | ||
| Pourquoi est-ce important ? Alimente la vue « Respect des protocoles cliniques » en marquant l’intention de suivre les normes de soins. Les écarts par rapport aux étapes prévues peuvent être mesurés à partir de ce point. Où trouver ces données ORDER_SET_BKG ou tables de plans de soins indiquant qu’un protocole a été associé à la consultation. Données à recueillir Enregistré lorsque le clinicien sélectionne et signe un ensemble de prescriptions Type d’événement explicit | |||
| Préparation de la sortie lancée | Début des activités visant à préparer la sortie du patient. Cet événement est enregistré dans la documentation de Case Management ou par des types de prescriptions « Discharge » spécifiques. | ||
| Pourquoi est-ce important ? Indispensable au Dashboard « Préparation et réalisation de la sortie ». Un démarrage précoce est associé à une durée de séjour réduite. Où trouver ces données Création de HSP_DISCH_PLAN ou première note du gestionnaire de cas ou de l’assistant social. Données à recueillir Déduit de la première interaction avec Discharge Navigator ou d’une note de Case Mgmt Type d’événement inferred | |||
| Rendez-vous de suivi planifié | La prise de rendez-vous pour une future consultation ambulatoire du patient. Elle est enregistrée dans le module de planification Cadence, associé au dossier du patient. | ||
| Pourquoi est-ce important ? Contribue à l’indicateur « Taux d’automatisation de la planification des rendez-vous de suivi ». Assure la continuité des soins et aide à prévenir les réadmissions. Où trouver ces données PAT_ENC_APPT associé à l’identifiant du patient, créé à proximité de l’heure de sortie. Données à recueillir Enregistré lorsque le créneau de rendez-vous est confirmé dans Cadence Type d’événement explicit | |||
| Transfert demandé | 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 est-ce important ? Point de départ du « Temps moyen de transfert entre services ». Permet de distinguer la décision clinique de transférer le patient de la disponibilité logistique d’un lit. Où trouver ces données ADT_TRANSFER_ORDER ou ORDER_PROC (Bed Request). Données à recueillir Enregistré lorsque le médecin saisit la demande de transfert Type d’événement explicit | |||
Guides d’extraction
Étapes
- Connectez-vous à Epic Hyperspace et lancez Reporting Workbench (RWB) depuis l’activité Analytics ou My Reports.
- Créez un nouveau rapport en sélectionnant l’onglet Library, puis recherchez le modèle "Encounter Search" ou "Patient Encounters". Ce modèle permet de récupérer les détails au niveau du contact, identifiés par le CSN (Contact Serial Number).
- Configurez les critères (onglet Settings) :
- Définissez la plage de dates (par exemple, date de sortie = 90 derniers jours) pour inclure les épisodes terminés.
- Filtrez par type de prise en charge (par exemple, « Hospital Encounter », « Emergency ») afin d’exclure les visites ambulatoires non pertinentes.
- Filtrez par service ou établissement si vous devez limiter le périmètre.
- Configurez les colonnes à afficher (onglet Display) :
- Cette étape est essentielle pour l’extraction. Recherchez et ajoutez les colonnes correspondant aux horodatages des activités requises.
- Ajoutez les identifiants du patient :
CSN(épisode du patient),MRN(ID patient). - Ajoutez les données démographiques et attributs :
Department,Discharge Disposition,Primary Diagnosis Code,Provider. - Ajoutez les colonnes d’horodatage : recherchez des colonnes telles que
Admission Time,Triage End Time,Discharge Time,Discharge Order Time,First Med Admin Time, etc. (consultez la section Requête/Configuration pour connaître les correspondances exactes).
- Exécutez le rapport et vérifiez les résultats dans la fenêtre d’aperçu.
- Exportez les données :
- Cliquez sur Toolbar > Export.
- Sélectionnez le format CSV ou Text (Tab Delimited).
- Vérifiez que l’option « Include Column Headers » est cochée.
- Enregistrez le fichier sous le nom
Raw_Epic_Extract.csv.
- Transformation des données (essentielle) :
- L’exportation RWB produit un jeu de données « large » (une ligne par épisode patient, avec plusieurs colonnes d’horodatage).
- Vous devez dé-pivoter ces données pour que chaque colonne d’horodatage devienne une ligne distincte dans le journal d’événements.
- Créez un fichier final contenant les colonnes suivantes :
PatientEpisodeId,ActivityName,EventTimestampet les attributs associés.
- Formatez les dates : vérifiez que
EventTimestamprespecte le format ISO (YYYY-MM-DD HH:MM:SS) compatible avec ProcessMind. - Validation finale : vérifiez que le fichier contient les en-têtes
PatientEpisodeId,ActivityName,EventTimestamp, puis importez-le dans ProcessMind.
Configuration
- Modèle : utilisez « Encounter Search » (LBF) ou « Find Patients », selon votre version d’Epic.
- Plage de dates : commencez par une période de 3 à 6 mois pour éviter les délais d’expiration. RWB n’est pas optimisé pour les extractions massives.
- Limite de lignes : Epic RWB impose souvent une limite (par exemple, 25 000 ou 50 000 lignes). Vérifiez que la plage de dates ne la dépasse pas ou lancez plusieurs extractions.
- Autorisations : les autorisations de sécurité « Create » et « Export » de Reporting Workbench sont requises.
- Performances : pour les recherches portant sur une longue période historique, lancez l’extraction en dehors des heures de pointe.
- Granularité : cette méthode fournit des horodatages récapitulatifs au niveau de la prise en charge (par exemple, « First Med Admin »). Elle n’extrait pas chaque occurrence (par exemple, chaque comprimé administré), sauf avec des modèles « Audit » spécifiques, rarement utilisés dans ce contexte.
Exemple de requête sql
[REPORT CONFIGURATION SPECIFICATION]
# GENERAL SETTINGS
Application: Epic Reporting Workbench
Template_ID: Encounter_Search_LBF
Time_Horizon: Discharge Date between [Start Date] and [End Date]
Filters: Encounter Type IN ('Hospital Encounter', 'Emergency')
# COLUMN SELECTION MAPPING
# Map the following Epic RWB Columns (Display Names) to the Output Activities.
# Note: Column names may vary slightly by Epic customized build.
[MANDATORY ATTRIBUTES]
Column: Contact Serial Number (CSN) -> Target: PatientEpisodeId
Column: Patient MRN -> Target: PatientMrn
Column: Department at Discharge -> Target: DepartmentName
Column: Discharge Disposition -> Target: DischargeDisposition
Column: Primary Diagnosis ICD-10 -> Target: PrimaryDiagnosisCode
Column: Attending Provider -> Target: ProviderId
Column: Current Date -> Target: LastDataUpdate
Column: System Name (Fixed 'Epic') -> Target: SourceSystem
[ACTIVITY TIMESTAMP MAPPING]
# These columns represent the 'EventTimestamp' for the specific 'ActivityName'
1. Activity: Patient Registered
Epic_Column: Hospital Admission Time OR Check-In Time
2. Activity: Triage Completed
Epic_Column: Triage End Time OR Triage Acuity Time
3. Activity: Care Plan Initiated
Epic_Column: Care Plan Start Date
4. Activity: Diagnostic Test Ordered
Epic_Column: First Lab Order Time OR First Imaging Order Time
(Note: Select 'Earliest' if multiple columns exist)
5. Activity: Diagnostic Test Performed
Epic_Column: First Lab Result Time OR First Imaging End Time
6. Activity: Diagnosis Confirmed
Epic_Column: Principal Diagnosis Problem List Date
7. Activity: Consultation Requested
Epic_Column: Consult Order Create Time
8. Activity: Consultation Completed
Epic_Column: Consult Complete Time
9. Activity: Medication Administered
Epic_Column: First Medication Administration Time
10. Activity: Transfer Ordered
Epic_Column: Transfer Order Time
11. Activity: Patient Transferred
Epic_Column: Last Transfer In Time OR ADT Event Time
12. Activity: Discharge Planning Initiated
Epic_Column: Case Management Start Date
13. Activity: Discharge Order Signed
Epic_Column: Discharge Order Time
14. Activity: Patient Discharged
Epic_Column: Hospital Discharge Time
15. Activity: Follow-up Appointment Scheduled
Epic_Column: Discharge Follow-Up Appointment Made Date
# TRANSFORMATION LOGIC (PSEUDO-CODE)
# The export will be 'Wide'. Apply this logic to create the Event Log:
FOR EACH Row IN Exported_CSV:
EpisodeID = Row['Contact Serial Number']
FUNCTION CreateEvent(ActivityName, TimestampColumn):
IF Row[TimestampColumn] IS NOT NULL:
OUTPUT_ROW = {
'PatientEpisodeId': EpisodeID,
'ActivityName': ActivityName,
'EventTimestamp': Row[TimestampColumn],
'PatientMrn': Row['Patient MRN'],
'DepartmentName': Row['Department at Discharge'],
... [All Attributes]
}
APPEND OUTPUT_ROW TO Event_Log
# Execute for all 15 mappings defined above
CreateEvent('Patient Registered', 'Hospital Admission Time')
CreateEvent('Triage Completed', 'Triage End Time')
... [Repeat for all mapped columns]
END LOOP Étapes
Demandez l’accès à la base de données : vérifiez que vous disposez d’un accès en lecture à la console Epic Clarity ou à un client SQL connecté à la base Clarity de production ou de reporting. Vous aurez besoin d’autorisations sur
PAT_ENC,ORDER_PROC,CLARITY_ADT,MAR_ADMIN_INFOet les tables de référence associées.Définissez le périmètre et les identifiants de filtre : avant d’exécuter le script complet, lancez de petites requêtes exploratoires pour identifier les valeurs
ORDER_TYPE_Ccorrespondant aux analyses de laboratoire, à la radiologie, aux consultations et aux transferts dans votre instance Epic. Ces listes personnalisées (listes de catégories) varient selon les hôpitaux.Définissez la période : repérez dans le script SQL fourni les clauses
WHEREqui filtrent surCONTACT_DATEouHOSP_ADMSN_TIME. Adaptez-les à la période d’extraction souhaitée (par exemple, les six derniers mois).Associez les feuilles de suivi personnalisées (facultatif) : si vous avez besoin d’horodatages précis pour le triage ou la planification des sorties qui ne figurent pas dans la table principale des prises en charge, identifiez le
FLO_MEAS_ID(Flowsheet Measure ID) correspondant à ces champs et mettez à jour les sections réservées à cet effet dans le script.Exécutez la requête : lancez le script SQL complet dans votre client SQL (par exemple, SQL Server Management Studio ou Oracle SQL Developer). Le script utilise
UNION ALLpour regrouper différents événements cliniques dans une structure normalisée de journal d’événements.Post-traitement : la requête renvoie une liste à plat. Vérifiez que
EventTimestampn’est pas nul. Si votre intergiciel l’exige, convertissez les formats de date et d’heure propres à la base de données au format ISO 8601 (YYYY-MM-DDTHH:MM:SS).Exportez les données : enregistrez le résultat dans un fichier CSV. Vérifiez que les en-têtes correspondent aux attributs définis (PatientEpisodeId, ActivityName, etc.).
Importez les données dans ProcessMind : importez le fichier CSV dans ProcessMind. Associez
PatientEpisodeIdà l’ID de cas,ActivityNameà l’activité etEventTimestampà l’horodatage.
Configuration
- Connexion à la base de données : Epic Clarity (généralement avec un système dorsal MSSQL ou Oracle).
- Filtrage des dates : filtrez sur
PAT_ENC.HOSP_ADMSN_TIMEouPAT_ENC.CONTACT_DATE. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de préserver les performances des requêtes. - Types de prise en charge : le script filtre les prises en charge hospitalières et aux urgences (valeurs
ENC_TYPE_Cgénéralement égales à 3 et 50, à vérifier dansZC_ENC_TYPE). - Types de commande : les valeurs
ORDER_TYPE_Ccorrespondant aux analyses de laboratoire, à l’imagerie et aux consultations doivent être adaptées à la configuration locale de ZC_ORDER_TYPE. - Performances : le script parcourt des tables volumineuses (
ORDER_PROC,CLARITY_ADT). Vérifiez que les index appropriés sont utilisés ou lancez-le en dehors des heures de pointe.
Exemple de requête sql
WITH Cohort AS (
SELECT
pe.PAT_ENC_CSN_ID,
pe.PAT_ID,
pe.HOSP_ADMSN_TIME,
pe.HOSP_DISCH_TIME,
pe.DEPARTMENT_ID,
dep.DEPARTMENT_NAME,
emp.NAME AS ProviderName,
pat.PAT_MRN_ID,
pe.ACUITY_LEVEL_C,
disch.NAME AS DischargeDisposition,
pe.ENC_TYPE_C
FROM PAT_ENC pe
LEFT JOIN CLARITY_DEP dep ON pe.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON pe.VISIT_PROV_ID = emp.PROV_ID
LEFT JOIN PATIENT pat ON pe.PAT_ID = pat.PAT_ID
LEFT JOIN ZC_DISCH_DISP disch ON pe.DISCH_DISP_C = disch.DISCH_DISP_C
WHERE pe.HOSP_ADMSN_TIME >= DATEADD(month, -6, GETDATE())
AND pe.ENC_TYPE_C IN (3, 50) -- 3=Inpatient, 50=Emergency (Verify local codes)
)
-- 1. Patient Registered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)) AS PatientEpisodeId,
'Patient Registered' AS ActivityName,
c.HOSP_ADMSN_TIME AS EventTimestamp,
c.DepartmentName,
c.ProviderName AS ProviderId,
c.PAT_MRN_ID AS PatientMrn,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)) AS TriageAcuityLevel,
CAST(c.ENC_TYPE_C AS VARCHAR(50)) AS EncounterType,
NULL AS PrimaryDiagnosisCode,
NULL AS ReadmissionFlag,
c.DischargeDisposition,
'Epic EHR' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM Cohort c
WHERE c.HOSP_ADMSN_TIME IS NOT NULL
UNION ALL
-- 2. Triage Completed (Using Flowsheet or Triage Time)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Triage Completed',
ISNULL(pe.TRIAGE_END_INSTANT, c.HOSP_ADMSN_TIME), -- Fallback if specific column unused
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC pe ON c.PAT_ENC_CSN_ID = pe.PAT_ENC_CSN_ID
WHERE pe.TRIAGE_END_INSTANT IS NOT NULL
UNION ALL
-- 3. Care Plan Initiated (Based on Order Type)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Care Plan Initiated',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 100 -- Placeholder: Replace with ID for Care Plan/Protocol
UNION ALL
-- 4. Diagnostic Test Ordered (Lab/Radiology)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnostic Test Ordered',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C IN (1, 2) -- Placeholder: 1=Lab, 2=Radiology (Verify local codes)
UNION ALL
-- 5. Diagnostic Test Performed (Result Time or Procedure Start)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnostic Test Performed',
COALESCE(ord2.PROC_START_TIME, ord2.PROC_ENDING_TIME, ord.ORDER_INST),
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
JOIN ORDER_PROC_2 ord2 ON ord.ORDER_PROC_ID = ord2.ORDER_PROC_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C IN (1, 2)
AND ord2.PROC_START_TIME IS NOT NULL
UNION ALL
-- 6. Diagnosis Confirmed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnosis Confirmed',
dx.NOTED_DATE,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
edg.DX_NAME,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC_DX dx ON c.PAT_ENC_CSN_ID = dx.PAT_ENC_CSN_ID
JOIN CLARITY_EDG edg ON dx.DX_ID = edg.DX_ID
WHERE dx.NOTED_DATE IS NOT NULL
UNION ALL
-- 7. Consultation Requested
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Consultation Requested',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 35 -- Placeholder: Replace with ID for Consult
UNION ALL
-- 8. Consultation Completed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Consultation Completed',
ord.ORDER_END_TIME,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 35 -- Placeholder: Replace with ID for Consult
AND ord.ORDER_STATUS_C = 5 -- Placeholder: 5=Completed
AND ord.ORDER_END_TIME IS NOT NULL
UNION ALL
-- 9. Medication Administered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Medication Administered',
mar.TAKEN_TIME,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_MED med ON c.PAT_ENC_CSN_ID = med.PAT_ENC_CSN_ID
JOIN MAR_ADMIN_INFO mar ON med.ORDER_MED_ID = mar.ORDER_MED_ID
LEFT JOIN CLARITY_EMP emp ON mar.TAKEN_USER_ID = emp.USER_ID
WHERE mar.TAKEN_TIME IS NOT NULL
AND mar.MAR_ACTION_C = 1 -- Placeholder: 1=Given
UNION ALL
-- 10. Transfer Ordered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Transfer Ordered',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 60 -- Placeholder: Replace with ID for Transfer/Bed Request
UNION ALL
-- 11. Patient Transferred
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Patient Transferred',
adt.EFFECTIVE_TIME,
dep.DEPARTMENT_NAME,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN CLARITY_ADT adt ON c.PAT_ENC_CSN_ID = adt.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_DEP dep ON adt.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE adt.EVENT_TYPE_C = 3 -- 3=Transfer In
UNION ALL
-- 12. Discharge Planning Initiated
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Discharge Planning Initiated',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 70 -- Placeholder: Case Management/Discharge Order Type
UNION ALL
-- 13. Discharge Order Signed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Discharge Order Signed',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.PROC_CODE = 'DISCHARGE' -- Placeholder: Filter by specific discharge procedure code
UNION ALL
-- 14. Patient Discharged
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Patient Discharged',
c.HOSP_DISCH_TIME,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
WHERE c.HOSP_DISCH_TIME IS NOT NULL
UNION ALL
-- 15. Follow-up Appointment Scheduled
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Follow-up Appointment Scheduled',
next_pe.APPT_MADE_DATE,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC next_pe ON c.PAT_ID = next_pe.PAT_ID
WHERE next_pe.APPT_MADE_DATE BETWEEN c.HOSP_ADMSN_TIME AND ISNULL(c.HOSP_DISCH_TIME, GETDATE())
AND next_pe.CONTACT_DATE > c.HOSP_ADMSN_TIME -- The appointment is for a future date relative to admission Prêt à commencer ?
Commencez dès aujourd’hui à transformer vos opérations cliniques en appliquant ce modèle à vos données Epic. Notre équipe peut vous accompagner dans l’extraction afin que vous puissiez en tirer rapidement des résultats.
Optimisez le parcours de vos patients et réduisez le temps de cycle dès aujourd’hui
Repérez les goulots d’étranglement cliniques pour réduire le temps de cycle de 30 %.
Aucune carte bancaire requise… La configuration ne prend que quelques minutes.