Votre modèle de données du parcours patient
Votre modèle de données du parcours patient
- Attributs recommandés pour le contexte clinique
- Principaux jalons du processus à suivre
- Instructions d’extraction spécifiques au DSE Epic
Attributs du parcours patient
| 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 | |||
Activités du parcours 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 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 | |||
Guides d’extraction
Étapes
- Connectez-vous à Epic Hyperspace et ouvrez le 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 Date Range, par exemple Discharge Date = Last 90 Days, afin de capturer les épisodes terminés.
- Filtrez sur Encounter Type, par exemple « Hospital Encounter » ou « Emergency », afin d’exclure les visites ambulatoires sans rapport.
- Filtrez sur Service ou Facility si un périmètre précis est nécessaire.
- Configurez les colonnes affichées (onglet Display) :
- Il s’agit de l’étape essentielle de l’extraction. Recherchez et ajoutez les colonnes correspondant aux horodatages des activités requises.
- Ajoutez les identifiants du patient :
CSN(épisode patient),MRN(identifiant patient). - Ajoutez les données démographiques et attributs :
Service,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 l’association exacte.
- 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.
- Transformez les données :
- L’export RWB produit un jeu de données « Wide », avec une ligne par épisode patient et plusieurs colonnes d’horodatage.
- Vous devez dé-pivoter et restructurer ces données afin que chaque colonne d’horodatage devienne une ligne distincte du journal d’événements.
- Créez un fichier final contenant les colonnes
PatientEpisodeId,ActivityName,EventTimestampet les attributs associés.
- Formatez les dates : vérifiez que
EventTimestampest au format ISO (YYYY-MM-DD HH:MM:SS) compatible avec ProcessMind. - Effectuez la 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 la version d’Epic.
- Plage de dates : limitez-la initialement à 3 à 6 mois afin d’éviter les erreurs d’expiration du délai, car le RWB n’est pas optimisé pour les extractions massives.
- Limite de lignes : le RWB Epic impose souvent une limite, par exemple 25 000 ou 50 000 lignes. Vérifiez que votre plage de dates ne la dépasse pas ou exécutez plusieurs lots.
- Autorisations : les points de sécurité « Create » et « Export » de Reporting Workbench sont requis.
- Performance : exécutez la recherche en dehors des périodes de pointe si vous interrogez de longues périodes historiques.
- Granularité : cette méthode fournit des horodatages récapitulatifs au niveau de la rencontre, par exemple « First Med Admin ». Elle n’extrait pas chaque boucle, comme chaque comprimé administré, sauf si vous utilisez des modèles « Audit » spécifiques, rares dans ce cas d’usage.
a 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 à Epic Clarity Console ou à un client SQL connecté à la base de données 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 filtrage : avant d’exécuter le script complet, lancez de petites requêtes exploratoires afin d’identifier les valeurs
ORDER_TYPE_Ccorrespondant aux laboratoires, à l’imagerie, aux consultations et aux transferts dans votre instance Epic. Ces listes personnalisées, ou listes de catégories, varient selon l’hôpital.Configurez la période : repérez les clauses
WHEREdu script SQL fourni qui filtrentCONTACT_DATEouHOSP_ADMSN_TIME. Adaptez-les à la période souhaitée, par exemple les 6 derniers mois.Associez les flowsheets personnalisés (facultatif) : si vous avez besoin d’horodatages précis pour le triage ou la préparation de la sortie qui ne figurent pas dans la table principale des rencontres, identifiez le
FLO_MEAS_IDcorrespondant 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 de journal d’événements standardisée.Effectuez le post-traitement : la requête renvoie une liste à plat. Vérifiez que
EventTimestampn’est pas nul. Convertissez les formats de date et d’heure propres à la base de données au format ISO 8601 (YYYY-MM-DDTHH:MM:SS) si votre middleware l’exige.Exportez les données : enregistrez le résultat dans un fichier CSV. Vérifiez que les en-têtes correspondent aux Attributs définis, notamment PatientEpisodeId et ActivityName.
Importez les données dans ProcessMind : importez le CSV dans ProcessMind. Associez
PatientEpisodeIdà l’identifiant de dossier,ActivityNameà l’activité etEventTimestampà l’horodatage.
Configuration
- Connexion à la base de données : Epic Clarity, généralement avec un back-end 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 rencontres : le script filtre les rencontres hospitalières et d’urgence, avec des valeurs
ENC_TYPE_Csouvent égales à 3 et 50. Vérifiez toutefois ces valeurs dansZC_ENC_TYPE. - Types de commandes : une personnalisation des valeurs
ORDER_TYPE_Cest nécessaire pour les laboratoires, l’imagerie et les consultations, selon la configuration locale deZC_ORDER_TYPE. - Performances : le script parcourt des tables volumineuses, notamment
ORDER_PROCetCLARITY_ADT. Vérifiez que les index appropriés sont utilisés ou exécutez-le en dehors des heures de pointe.
a 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 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 %.
Aucune carte bancaire requise… La configuration ne prend que quelques minutes.