> Amélioration continue des processus > Parcours du patient > Veradigm (Allscripts) > Modèle de données

Votre modèle de données du parcours patient

Veradigm (Allscripts)

Attributs du parcours du patient (19) Activités du parcours du patient (13) Guides d’extraction (2)

Votre modèle de données du parcours patient

Ce modèle propose une méthode structurée pour recueillir les données nécessaires à l’analyse de votre processus de parcours patient. Il présente les attributs et les activités essentiels à suivre, ainsi que des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour préparer vos données à une analyse complète par Process Mining.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour une découverte précise du processus
Conseils pratiques pour extraire les données de votre système

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du parcours du patient

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le parcours du patient.

3 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Description
	Épisode patient PatientEpisodeId	Identifiant unique de la visite ou de la rencontre spécifique du patient.
Description L'épisode patient sert d'identifiant de cas principal. Il regroupe tous les événements liés au parcours de soins d'un patient pour une pathologie ou une période de prise en charge donnée. Il offre une vue intégrée des phases de diagnostic, de traitement et de rétablissement, en reliant les interactions avec les différents services au sein d'un ensemble cohérent. Dans les systèmes Veradigm (Allscripts), tels que Sunrise ou Paragon, il correspond généralement à l'identifiant de visite ou au numéro de rencontre. Pourquoi c’est important Il constitue la clé fondamentale du Process Mining et permet de reconstituer le parcours patient de bout en bout. Où les obtenir Il se trouve probablement dans l'en-tête des tables Visit ou Encounter, par exemple VISIT_ID ou ENCOUNTER_ID. Consultez la documentation Veradigm (Allscripts). Exemples EP-2023-998877VIS-10029384100029384ENC-554433
	Horodatage de l'événement EventDateTime	Date et heure exactes auxquelles l'activité s'est produite.
Description Enregistre le moment chronologique de l'activité. Il est indispensable pour calculer les temps de cycle et les durées, ainsi que pour ordonner correctement la séquence des événements. Dans les données de santé, une précision à la minute est essentielle pour analyser correctement les volumes traités. Pourquoi c’est important Permet de calculer tous les KPI temporels, notamment la durée moyenne du cycle du parcours patient et les temps d'attente. Où les obtenir Horodatages des transactions dans les tables sources, par exemple ADT_DATE, ORDER_DATE et RESULT_DATE. Exemples 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Nom de l'activité ActivityName	Événement clinique ou administratif précis réalisé.
Description Décrit l'étape réalisée dans le processus, telle que « Patient Registered », « Medication Administered » ou « Discharge Planning Initiated ». Cet attribut distingue les différentes étapes du parcours patient et est indispensable à la découverte des processus et à l'analyse des variantes. Pourquoi c’est important Définit les nœuds de la cartographie du processus. Sans lui, aucun flux de processus ne peut être visualisé. Où les obtenir Dérivé de différentes tables transactionnelles : événements ADT, prescriptions, résultats et tables de documentation clinique. Exemples Patient enregistréExamen diagnostique prescritMédicament administréPatient sorti
	Code du diagnostic principal PrimaryDiagnosisCode	Code ICD-10 ou SNOMED représentant la pathologie principale.
Description Motif codé de la visite du patient. Cet attribut sert de filtre à l'explorateur des variations des parcours de traitement. Il permet aux analystes de comparer la manière dont différentes pathologies, telles que la pneumonie ou l'insuffisance cardiaque, traversent le système. Pourquoi c’est important Nécessaire pour segmenter les processus selon la pathologie et vérifier le respect des protocoles. Où les obtenir Tables des diagnostics ou de la liste des problèmes, généralement avec des colonnes ICD-10. Consultez la documentation Veradigm (Allscripts). Exemples I50.9J18.9E11.9
	Date d'admission AdmissionDate	Date et heure auxquelles le patient a été officiellement admis.
Description Horodatage marquant le début du séjour hospitalier. Utilisé avec la date de sortie pour calculer la durée moyenne de séjour (ALOS). Pourquoi c’est important Point de référence essentiel pour calculer l'ALOS et mesurer les retards d'admission. Où les obtenir Table d'en-tête Visit/Encounter, par exemple ADMIT_DATE. Consultez la documentation Veradigm (Allscripts). Exemples 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Date de sortie DischargeDate	Date et heure auxquelles le patient est sorti.
Description Horodatage marquant la fin de l'épisode. Il sert à clôturer le cas dans le Process Mining et est indispensable au calcul de l'ALOS et des réadmissions. Pourquoi c’est important Définit la fin du cycle du processus et est essentiel à l'analyse des volumes traités. Où les obtenir Table d'en-tête Visit/Encounter, par exemple DISCH_DATE. Consultez la documentation Veradigm (Allscripts). Exemples 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Destination de sortie DischargeDisposition	Statut ou lieu où se trouve le patient au moment de sa sortie.
Description Indique la destination du patient après son séjour hospitalier, par exemple « Home », « Skilled Nursing Facility », « Expired » ou « Transfer ». Cet attribut est important pour analyser les risques de réadmission, car chaque destination présente un profil de risque différent. Pourquoi c’est important Apporte un contexte au Dashboard de planification des sorties et aide à expliquer les écarts d'ALOS. Où les obtenir Table d'en-tête Visit/Encounter, par exemple DISCH_DISP. Consultez la documentation Veradigm (Allscripts). Exemples DomicileTransféré vers un établissement de soins infirmiers spécialisésRetour à domicile avec soins à domicileSortie contre avis médical
	Nom du service DepartmentName	Unité ou service hospitalier où l'activité a eu lieu.
Description Indique le contexte géographique, par exemple « Emergency Room », « Cardiology » ou « Radiology ». Cet attribut est essentiel à l'analyse des goulots d'étranglement lors des admissions et des transferts, afin d'identifier les services où les patients restent bloqués lors de leurs déplacements entre les unités. Pourquoi c’est important Soutient l'analyse de l'utilisation des ressources et l'identification des goulots d'étranglement dans les services. Où les obtenir Tables de référence des lieux ou des services associées à la transaction. Consultez la documentation Veradigm (Allscripts). Exemples Service des urgencesICUChirurgie généraleRadiologie
	Numéro de dossier patient PatientMrn	Medical Record Number identifiant de manière unique le patient pour l'ensemble de ses épisodes.
Description Le Medical Record Number (MRN), ou identifiant patient d'entreprise, reste constant pour un même patient au fil de ses différentes visites, contrairement à l'identifiant de l'épisode patient. Il s'agit de la clé essentielle pour relier plusieurs épisodes et calculer les taux de réadmission. Pourquoi c’est important Indispensable pour calculer le « taux de réadmission à 30 jours » et identifier les patients revenant dans l'établissement. Où les obtenir Index principal des patients ou tables démographiques, avec probablement les colonnes MRN et PATIENT_ID. Consultez la documentation Veradigm (Allscripts). Exemples MRN-884422P-10022399887766
	Professionnel de santé responsable AttendingProvider	Clinicien principalement responsable du patient pendant l'événement.
Description Identifie le médecin, l'infirmier ou le spécialiste qui réalise l'activité ou qui est responsable du plan de soins. L'analyse de cet attribut aide à comprendre l'utilisation des ressources cliniques et les variations des parcours de soins selon les médecins. Pourquoi c’est important Permet d'analyser les goulots d'étranglement liés aux ressources et de comparer les performances des équipes cliniques. Où les obtenir Tables transactionnelles, par exemple ORDERing_PROVIDER et ATTENDING_PHYSICIAN_ID. Consultez la documentation Veradigm (Allscripts). Exemples Dr Sarah SmithInfirmier praticien JonesTechnicien en radiologie A
	Réadmission IsReadmission	Indicateur précisant si cet épisode correspond à une réadmission dans les 30 jours.
Description Attribut booléen calculé. Il renvoie true si le patient a fait l’objet d’une sortie dans les 30 jours précédant la date d’admission actuelle. Il alimente le moniteur du taux de réadmissions évitables. Pourquoi c’est important Indicateur clé de performance pour la qualité hospitalière et le remboursement, notamment dans le cadre des réglementations de la CMS. Où les obtenir Calculé dans la couche ETL de transformation des données à partir de PatientMRN et des dates d’admission et de sortie. Exemples truefalse
	Centre de coûts CostCenter	Code financier associé au service ou au département.
Description Associe l’activité clinique à une unité financière. Cela facilite l’analyse du coût de l’activité ou de la performance financière générique des différents départements. Pourquoi c’est important Relie le Process Mining opérationnel à son impact financier. Où les obtenir Tables des départements ou du référentiel des prestations. Consultez la documentation de Veradigm (Allscripts). Exemples CC-1020CC-Rad-01Emergency-001
	Date du rendez-vous de suivi FollowUpAppointmentDate	Date du rendez-vous de suivi planifié.
Description Utilisé pour calculer le taux de rendez-vous de suivi planifiés. Si ce champ est renseigné, cela indique qu’un suivi a été planifié. S’il est nul ou vide, aucun suivi n’a été planifié. Pourquoi c’est important Mesure directement l’indicateur clé de performance du respect du suivi des soins. Où les obtenir Système de planification ou table des rendez-vous futurs associée au patient. Consultez la documentation de Veradigm (Allscripts). Exemples 2023-11-15T14:00:00Znull
	Délai d’obtention des résultats diagnostiques DiagnosticTurnaroundTime	Durée entre la prescription d’un examen et la réception de son résultat.
Description Durée calculée entre « Diagnostic Test Ordered » et « Diagnosis Confirmed », ou la réception du résultat. Utilisée dans la vue d’ensemble des délais d’obtention des résultats diagnostiques. Pourquoi c’est important Des délais élevés prolongent la durée d’hospitalisation ; cet indicateur permet de localiser les retards au laboratoire ou en radiologie. Où les obtenir Calcul : Timestamp(Result) - Timestamp(Order). Exemples 2 heures45 minutes1,5 jour
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière extraction ou mise à jour du dossier.
Description Indique la fraîcheur des données utilisées pour l'analyse. Ce champ aide les utilisateurs à déterminer s'ils consultent des données en temps réel ou un instantané d'une période antérieure. Pourquoi c’est important Garantit la transparence concernant la latence des données et facilite les stratégies de chargement incrémentiel. Où les obtenir Horodatage généré par le système lors de l'exécution du processus ETL ou de l'extraction. Exemples 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Identifiant de prescription OrderId	Identifiant des prescriptions spécifiques, notamment les analyses, les médicaments et les actes.
Description Relie l'événement « Order » à l'événement « Result » ou « Administration ». Il permet par exemple de relier « Diagnostic Test Ordered » à « Diagnostic Test Completed ». Ce niveau de détail est nécessaire au Dashboard des délais de réalisation des examens diagnostiques. Pourquoi c’est important Permet de calculer la durée d'étapes précises du processus, par exemple le délai de réalisation d'une analyse de laboratoire. Où les obtenir Tables de saisie des prescriptions, par exemple ORDER_ID et PLACER_ORDER_NUM. Consultez la documentation Veradigm (Allscripts). Exemples ORD-998877LAB-112233RX-445566
	Nom du médicament MedicationName	Nom du médicament prescrit ou administré.
Description Utilisé spécifiquement pour le Dashboard des écarts de délai d'administration des médicaments. Il aide à déterminer si certains médicaments, tels que les antibiotiques ou les traitements antidouleur, font l'objet de retards d'administration. Pourquoi c’est important Essentiel à l'analyse de la sécurité clinique et à l'optimisation des processus de pharmacie. Où les obtenir Dossier d’administration des médicaments (MAR) ou commandes de pharmacie. Consultez la documentation de Veradigm (Allscripts). Exemples AmoxicillineHéparineSulfate de morphine
	Respect du protocole IsProtocolCompliant	Indicateur précisant si le cas a suivi le parcours de soins standard.
Description Attribut calculé qui vérifie si certaines activités obligatoires, par exemple « Vitals Recorded » avant « Medication Administered », ont été réalisées dans le bon ordre. Il alimente le Dashboard de respect du protocole de soins. Pourquoi c’est important Automatise la détection des écarts de conformité sans examen manuel du dossier. Où les obtenir Calculé dans l’outil de Process Mining ou dans l’ETL à partir de la séquence des activités. Exemples truefalse
	Système source SourceSystem	Nom du système à l'origine des données.
Description Identifie l'instance logicielle qui fournit les données, telle que « Veradigm Sunrise » ou « Veradigm TouchWorks ». Cet attribut est particulièrement important dans les environnements multi-hospitaliers ou lors de la fusion de données provenant de services de soins aigus et ambulatoires. Pourquoi c’est important Assure la traçabilité et la lignée des données, ce qui est utile pour diagnostiquer les problèmes de qualité des données. Où les obtenir Codé en dur lors du processus ETL ou extrait des tables de métadonnées du système. Exemples Veradigm SunriseAllscripts PMVeradigm TouchWorks

Obligatoire Recommandé Facultatif

Activités du parcours du patient

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour obtenir une découverte précise du parcours du patient.

6 Recommandé 7 Facultatif

	Activité	Description
	Diagnostic confirmé	Cette activité indique qu'un clinicien a officiellement enregistré un diagnostic dans le dossier du patient. Elle peut être enregistrée lorsqu'un code de diagnostic est ajouté à la liste des problèmes ou lorsqu'une note clinique contenant le diagnostic est signée.
Pourquoi c’est important La confirmation du diagnostic constitue un tournant important qui détermine la suite du parcours thérapeutique. Elle permet d'analyser les variations des parcours de traitement selon les diagnostics. Où les obtenir L'information se trouve dans la liste des problèmes du patient, les enregistrements de diagnostic de la rencontre ou la documentation clinique. Elle peut être déduite de l'horodatage auquel le code du diagnostic principal est saisi et finalisé pour la rencontre. Collecte Utilisez l'horodatage de création ou de mise à jour de l'entrée correspondant au diagnostic principal pour l'épisode patient concerné. Type d’événement inferred
	Évaluation initiale terminée	Correspond à la fin de la première évaluation clinique réalisée par un infirmier ou un médecin, par exemple le triage ou l'admission initiale. Cet événement est souvent enregistré lorsqu'un formulaire ou une note clinique spécifique, comme « Nursing Initial Assessment », est signé et finalisé dans le DSE.
Pourquoi c’est important Cette activité constitue une étape précoce importante. Le délai entre l'inscription et cette évaluation met en évidence d'éventuels retards dans l'admission du patient et les premiers soins. Où les obtenir Déduit de l'horodatage de finalisation ou de signature des formulaires d'évaluation initiale ou des notes cliniques dans les modules de documentation clinique de Veradigm. Collecte Identifiez l'horodatage auquel le statut de la note ou du formulaire d'évaluation initiale passe à « completed » ou « signed ». Type d’événement inferred
	Patient enregistré	Marque le début officiel de l’épisode de soins, lorsque les informations du patient sont saisies dans le système Veradigm. Cet événement est généralement enregistré explicitement lorsqu’un utilisateur termine le flux de travail d’inscription, créant un nouvel enregistrement de rencontre patient avec un identifiant unique et un horodatage.
Pourquoi c’est important Il s'agit de l'activité initiale principale du parcours patient. Elle est indispensable pour calculer la durée totale du cycle du processus, la durée de séjour et les taux de prise en charge des patients. Où les obtenir Cet événement est enregistré dans le module d'inscription des patients ou dans le module ADT (Admission, Discharge, Transfer). Recherchez l'horodatage de création du dossier de rencontre ou de visite du patient. Collecte Horodatage issu de la table des rencontres ou des inscriptions, au moment de la création du dossier. Type d’événement explicit
	Patient sorti	Marque la fin officielle de l'épisode d'hospitalisation, lorsque le patient quitte officiellement l'établissement. Il s'agit d'un événement explicite et essentiel, capturé par le système ADT, qui met à jour le statut de la rencontre du patient en « discharged ».
Pourquoi c’est important Il s'agit de l'activité finale principale de la plupart des parcours patients. Elle est indispensable pour calculer la durée moyenne de séjour (ALOS) et la durée totale du cycle du processus. Où les obtenir Enregistré explicitement dans le module ADT. Le dossier de rencontre du patient comporte un horodatage de sortie et une destination de sortie. Collecte Utilisez l'horodatage de sortie du dossier principal de rencontre ou de visite du patient. Type d’événement explicit
	Plan de traitement créé	Correspond à la formalisation du plan de traitement du patient par l'équipe clinique. Cet événement est souvent enregistré lorsqu'un document « Plan of Care » spécifique ou un ensemble de premières prescriptions thérapeutiques est créé et signé dans le DSE.
Pourquoi c’est important Cette étape marque le début de la phase de traitement actif. Elle sert de référence pour mesurer le respect des protocoles de soins et le délai avant la première intervention thérapeutique, telle que l'administration d'un médicament. Où les obtenir Déduit de l'horodatage de signature d'un formulaire « Plan of Care » ou de l'horodatage de création du premier ensemble important de prescriptions thérapeutiques suivant le diagnostic. Collecte Recherchez l'horodatage auquel le document « Plan of Care » est finalisé ou signé par le clinicien responsable. Type d’événement inferred
	Planification de la sortie initiée	Correspond au début officiel du processus de planification de la sortie du patient. Cet événement peut être déduit de la création d'un document de planification de sortie, de la saisie d'une prescription de sortie ou de la réalisation d'une évaluation spécifique de planification de sortie.
Pourquoi c’est important Cette activité constitue le point de départ pour mesurer l'efficacité du processus de sortie. Une planification précoce est souvent associée à des taux de réadmission plus faibles. Où les obtenir Déduit de l'horodatage de création d'une note de planification de sortie, d'un ensemble de prescriptions de sortie ou d'un formulaire d'évaluation spécifique dans Veradigm. Collecte Identifiez l'horodatage auquel une prescription ou un document spécifique à la sortie est créé pour la première fois dans le dossier de rencontre du patient. Type d’événement inferred
	Acte réalisé	Correspond à la réalisation d'un acte clinique ou chirurgical. Cet événement est généralement enregistré lorsqu'un clinicien signe la note relative à l'acte ou lorsque le statut de la prescription correspondante passe à « completed » dans le système.
Pourquoi c’est important Les actes constituent des étapes importantes dans de nombreux parcours patients. L'analyse de leur calendrier permet de mieux comprendre l'utilisation des ressources et l'efficacité de la planification. Où les obtenir Déduit de l'horodatage de signature d'une note d'acte dans le module de documentation clinique ou de l'horodatage de fin de l'acte dans le module des prescriptions. Collecte Utilisez l'horodatage de fin de la prescription de l'acte ou l'horodatage de signature de la documentation correspondante. Type d’événement inferred
	Constantes vitales enregistrées	Cette activité se produit chaque fois que les constantes vitales d'un patient, telles que la fréquence cardiaque, la pression artérielle et la température, sont enregistrées. Il s'agit d'un événement explicite capturé dans la documentation clinique ou dans la section flowsheet dédiée aux constantes vitales du DSE.
Pourquoi c’est important L'enregistrement fréquent des constantes vitales témoigne d'un suivi actif du patient. La fréquence et le calendrier des mesures peuvent être analysés afin de vérifier le respect des protocoles de surveillance. Où les obtenir Enregistré dans le référentiel de données cliniques ou les tables flowsheet où sont stockées les constantes vitales. Chaque entrée comporte un horodatage. Collecte Extrayez les horodatages des données flowsheet relatives aux constantes vitales pour la rencontre du patient. Type d’événement explicit
	Examen diagnostique prescrit	Cet événement se produit lorsqu'un clinicien prescrit un examen diagnostique, tel qu'une analyse de laboratoire ou un examen d'imagerie. Il est enregistré explicitement dans le système Computerized Physician Order Entry (CPOE) de Veradigm.
Pourquoi c’est important Il marque le début du sous-processus diagnostique. Il constitue le point de départ pour mesurer les délais de réalisation des examens et identifier les retards dans les procédures de prescription. Où les obtenir Enregistré dans le module des prescriptions ou dans les journaux du système CPOE. Chaque prescription comporte un horodatage indiquant le moment où elle a été créée. Collecte Extrayez l'horodatage de création des enregistrements de prescription correspondant aux examens diagnostiques concernés. Type d’événement explicit
	Examen diagnostique terminé	Correspond au moment où les résultats d'un examen diagnostique sont finalisés et mis à disposition dans le dossier du patient. Cet événement est généralement déduit du changement de statut de la prescription initiale, qui passe de « active » ou « in-progress » à « completed » ou « resulted ».
Pourquoi c’est important Cette activité constitue une étape essentielle pour mesurer les délais de réalisation des examens. Les retards entre la prescription et la fin de l'examen peuvent allonger considérablement le délai d'établissement du diagnostic. Où les obtenir Déduit du champ de statut de la prescription dans le module correspondant ou des horodatages du module de résultats associé, tel qu'un LIS ou un RIS. Collecte Identifiez l'horodatage auquel le statut de la prescription passe à un état final tel que « Completed » ou « Resulted ». Type d’événement inferred
	Médicament administré	Cet événement est enregistré lorsqu'un infirmier ou un clinicien documente l'administration d'un médicament au patient. Il est capturé dans le Medication Administration Record (MAR) ou le module eMAR, qui consigne l'heure exacte de l'administration.
Pourquoi c’est important Le suivi de l'administration des médicaments est essentiel pour analyser la ponctualité et le respect du traitement. L'écart entre la prescription et l'administration permet d'identifier les retards dans le processus de délivrance des médicaments. Où les obtenir Enregistré explicitement dans le module eMAR (electronic Medication Administration Record). Chaque événement d'administration comporte un horodatage précis, le médicament et la dose administrée. Collecte Extrayez les horodatages de la table eMAR pour chaque événement d'administration de médicament associé à la rencontre du patient. Type d’événement explicit
	Suivi planifié	Cette activité correspond à la planification d'un rendez-vous de suivi pour le patient après sa sortie. L'événement est capturé dans le module de planification lorsqu'un rendez-vous est pris et associé à la rencontre clôturée.
Pourquoi c’est important La planification du suivi est essentielle pour assurer la continuité des soins et réduire les réadmissions. Cette activité permet de mesurer le respect des protocoles post-sortie. Où les obtenir Enregistré dans le module de planification des rendez-vous. Recherchez l'horodatage de création d'un nouveau rendez-vous pour le patient, prévu après la date de sortie. Collecte Identifiez l'horodatage de création d'un rendez-vous dans le système de planification, associé au patient. Type d’événement explicit
	Transfert vers un service	Cet événement marque le transfert physique d'un patient d'un service ou d'une unité de soins vers un autre, par exemple des urgences vers une unité d'hospitalisation. Il est capturé par le système ADT de Veradigm.
Pourquoi c’est important Les transferts de patients sont des points fréquents de formation de goulots d'étranglement et de retards. L'analyse de leur durée et de leur fréquence aide à optimiser le parcours des patients et l'affectation des ressources entre les services. Où les obtenir Enregistré explicitement dans le module ADT. Chaque événement de transfert comprend le patient, les lieux de départ et d'arrivée, ainsi qu'un horodatage. Collecte Extrayez les journaux d'événements du système ADT correspondant aux déplacements des patients. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Veradigm (Allscripts)

Étapes

Identifier le canal d’interface cible : Connectez-vous à la console de gestion d’Allscripts Interface Engine (AIE). Repérez le canal d’interface principal qui traite les messages entrants du DSE, généralement nommé « EHR_Inbound » ou de manière similaire. Vérifiez que ce canal traite les types de messages ADT, SIU, ORM, ORU, RAS et DFT afin de couvrir l’ensemble des activités du parcours du patient.
Créer un canal de transfert ou d’export : Créez un nouveau canal de destination nommé « ProcessMining_Export ». Définissez le type de sortie sur « File Writer ». Ce canal recevra une copie des messages du canal source et les transformera en fichier plat au format CSV pour ProcessMind.
Configurer le routage des messages : Dans les règles de routage de l’AIE, configurez une règle de copie ou de routage pour envoyer les messages du canal DSE principal vers le nouveau canal « ProcessMining_Export ». Filtrez le routage afin de ne conserver que les types de messages nécessaires : ADT (enregistrement/transfert), SIU (planification), ORM (commandes), ORU (résultats/constantes), RAS (médicaments) et DFT (facturation/interventions).
Définir la logique de transformation : Dans le canal « ProcessMining_Export », ouvrez l’éditeur Transformation/Script. Vous devez implémenter un script d’analyse, présenté dans la section « query » ci-dessous, qui lit les segments HL7 et associe certains Trigger Events et codes de statut aux Activity Names standard requis, par exemple en associant « ADT^A01 » à « Patient Registered ».
Associer les attributs aux champs HL7 : Vérifiez que le script extrait « PatientEpisodeId » du segment PV1-19 (Visit Number) et « PatientMrn » du champ PID-3. Associez « EventDateTime » à MSH-7 ou EVN-2. Extrayez les informations cliniques telles que « DepartmentName » depuis PV1-3 et « AttendingProvider » depuis PV1-7.
Définir les paramètres du fichier de sortie : Configurez les paramètres de File Writer. Définissez le répertoire de sortie sur un chemin réseau sécurisé. Définissez la convention de nommage des fichiers, par exemple EventLog_YYYYMMDD_HH.csv. Sélectionnez le mode « Append » afin d’ajouter continuellement des lignes au journal.
Gérer les séparateurs et les caractères d’échappement : Dans le script, veillez à nettoyer les champs texte, tels que Diagnosis ou Department Name, afin de supprimer les virgules et les retours à la ligne susceptibles de perturber la structure CSV.
Activer et tester : Démarrez le canal « ProcessMining_Export ». Déclenchez un événement de test dans l’environnement de test de Veradigm, par exemple en enregistrant un patient test. Vérifiez qu’une nouvelle ligne apparaît dans le fichier CSV avec le bon Activity Name et l’horodatage correspondant.
Configurer la rotation des journaux : Configurez une rotation, par exemple chaque jour à minuit, afin de fermer le fichier CSV actuel et d’en commencer un nouveau. Les fichiers resteront ainsi d’une taille adaptée au chargement.
Rejouer les données historiques (facultatif) : Si des données historiques sont nécessaires, utilisez le « Message Browser » ou l’outil « Log Replay » de l’AIE pour renvoyer les journaux HL7 archivés des 3 à 6 derniers mois via le canal « ProcessMining_Export ». Surveillez les performances du système afin d’éviter tout ralentissement.
Récupérer et formater les fichiers : Accédez au répertoire de sortie, récupérez les fichiers CSV générés et vérifiez que leurs en-têtes correspondent aux exigences. Regroupez les fichiers quotidiens si nécessaire.
Charger les données dans ProcessMind : Importez le jeu de données final dans ProcessMind en associant « PatientEpisodeId » à Case ID, « ActivityName » à Activity et « EventDateTime » à Timestamp.

Configuration

Type de canal : File Writer / sortie du système de fichiers
Trigger Events : ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Encodage du fichier : UTF-8, essentiel pour les caractères spéciaux des noms et des diagnostics
Séparateur : virgule (,) ou barre verticale (|)
Format de date : ISO 8601 (YYYY-MM-DDTHH:MM:SS), recommandé pour convertir les horodatages HL7
Rotation des journaux : quotidienne ou lorsque la taille du fichier dépasse 100 Mo
Mode d’écriture : Append, sans écrasement
Performances : veillez à ce que le script de transformation reste léger afin d’éviter la mise en file d’attente ou l’accumulation de messages dans le moteur.

a Exemple de requête config

// AIE Transformation Script (Pseudo-code for Config)
// Objective: Parse HL7 message and append line to CSV
// Output Columns: PatientEpisodeId, ActivityName, EventDateTime, PatientMrn, AttendingProvider, DepartmentName, PrimaryDiagnosisCode

// 1. Initialize Variables
var msgType = HL7.GetField("MSH-9-1") + "^" + HL7.GetField("MSH-9-2");
var visitNumber = HL7.GetField("PV1-19");
var mrn = HL7.GetField("PID-3");
var eventTime = HL7.GetField("MSH-7"); // Or EVN-2
var provider = HL7.GetField("PV1-7");
var dept = HL7.GetField("PV1-3");
var diagnosis = HL7.GetField("DG1-3"); // For Diagnosis events
var orderStatus = HL7.GetField("ORC-5");
var resultStatus = HL7.GetField("OBR-25");
var activityName = "";

// 2. Map Message Types to Activities
// Registration & Admission
if (msgType == "ADT^A04" || msgType == "ADT^A01") {
    activityName = "Patient Registered";
}
else if (msgType == "ADT^A02") {
    activityName = "Transfer to Department";
}
else if (msgType == "ADT^A03") {
    activityName = "Patient Discharged";
}
// Scheduling
else if (msgType == "SIU^S12") {
    activityName = "Follow-up Scheduled";
}
// Orders (Diagnostics, Care Plans, Discharge Planning)
else if (msgType == "ORM^O01") {
    var orderControl = HL7.GetField("ORC-1");
    var orderType = HL7.GetField("OBR-4"); // Check for specific service codes
    
    if (orderControl == "NW") { // New Order
        if (orderType.Contains("LAB") || orderType.Contains("RAD")) {
            activityName = "Diagnostic Test Ordered";
        }
        else if (orderType.Contains("DISCHARGE")) {
            activityName = "Discharge Planning Initiated";
        }
        else if (orderType.Contains("CARE_PLAN")) {
            activityName = "Treatment Plan Created";
        }
    }
}
// Results & Vitals
else if (msgType == "ORU^R01") {
    // Check if it is Vitals or Lab Result based on OBX codes or sending app
    var observationId = HL7.GetField("OBX-3"); 
    if (observationId.Contains("VITALS")) {
        activityName = "Vitals Recorded";
    } else {
        if (resultStatus == "F" || resultStatus == "C") {
            activityName = "Diagnostic Test Completed";
        }
    }
    
    // Initial Assessment Check (often a specific doc type in ORU or MDM)
    if (observationId.Contains("INITIAL_ASSESS")) {
        activityName = "Initial Assessment Completed";
    }
}
// Medication Administration (RAS)
else if (msgType == "RAS^O17") {
    activityName = "Medication Administered";
}
// Billing/Procedures (DFT)
else if (msgType == "DFT^P03") {
    activityName = "Procedure Performed";
}
// Diagnosis Updates (Often in ADT or DFT, logic depends on config)
else if (msgType == "ADT^A08" && diagnosis != "") {
    // Check if diagnosis segment is new/updated
    activityName = "Diagnosis Confirmed";
}

// 3. Write to File if Activity Identified
if (activityName != "" && visitNumber != "") {
    // Format Date to ISO
    var formattedDate = FormatDate(eventTime, "yyyy-MM-dd HH:mm:ss");
    
    // Construct CSV Line
    var csvLine = visitNumber + "," + 
                  activityName + "," + 
                  formattedDate + "," + 
                  mrn + "," + 
                  provider + "," + 
                  dept + "," + 
                  diagnosis;
                  
    File.WriteLine("[Configured_Output_Path]\\PatientJourneyLog.csv", csvLine);
}

Étapes

Prérequis et accès : Vérifiez que vous disposez d’identifiants valides pour l’API Unity de Veradigm (Allscripts). Vous aurez besoin d’un Appname autorisé pour votre organisation, ainsi que d’un UserID et d’un Password valides, ou d’un jeton d’authentification. Vérifiez que le compte utilisateur est autorisé à accéder aux domaines cliniques, notamment Encounters, Orders, Results, Vitals et Problems.
Préparer l’environnement : Installez Python 3.8 ou une version ultérieure. Installez les bibliothèques nécessaires avec pip : pip install requests pandas. Elles serviront à envoyer des requêtes HTTP à l’API Unity et à manipuler les données obtenues.
Configurer le script : Ouvrez le script Python fourni. Repérez la section CONFIGURATION au début du fichier. Modifiez API_URL pour qu’il pointe vers le point de terminaison de votre environnement Unity, par exemple unity.veradigm.com ou une passerelle interne. Remplacez les identifiants fictifs ([YourAppName], [YourUserID], etc.) par vos identifiants réels. Définissez START_DATE et END_DATE selon la période d’analyse souhaitée.
Vue d’ensemble de la logique du script : Le script commence par s’authentifier auprès de l’API afin d’obtenir un jeton de sécurité. Il appelle ensuite GetEncounterInfo pour récupérer tous les épisodes de patients compris dans la période définie. Cette liste de rencontres constitue l’itérateur central de l’extraction.
Boucle d’extraction des activités : Pour chaque EncounterID identifié, le script effectue des appels API secondaires vers des points de terminaison spécialisés. Il appelle GetOrders pour rechercher les examens diagnostiques et les interventions, GetResults pour identifier les examens terminés, GetVitals pour récupérer les relevés de constantes et GetPatientProblems pour obtenir les diagnostics confirmés. Il parcourt également les notes cliniques afin de repérer les évaluations et les plans de traitement.
Transformation des données : À mesure que l’API renvoie les données JSON brutes, le script analyse certains champs afin de les associer au schéma ProcessMind. Par exemple, OrderDateTime est associé à EventDateTime pour l’activité « Diagnostic Test Ordered ». Le script applique systématiquement PatientEpisodeId, correspondant à l’identifiant de la rencontre, à tous les enregistrements associés.
Gestion des événements ADT et des transferts : La logique du script vérifie l’historique des emplacements de la rencontre, s’il est disponible via certains appels Audit ou ADT, ou déduit les transferts à partir des changements de département consignés dans la documentation clinique afin de générer les événements « Transfer to Department ».
Logique de suivi : Après le traitement de la rencontre, le script interroge GetSchedule pour le même PatientID afin de rechercher les rendez-vous postérieurs à DischargeDate et de générer l’activité « Follow-up Scheduled ».
Validation : Le script comprend une étape de validation locale qui affiche dans la console le nombre de lignes par type d’activité. Examinez ce résultat afin de vérifier qu’aucun type d’activité ne comporte zéro enregistrement, sauf si cela est attendu.
Export : Le jeu de données final est regroupé dans un DataFrame Pandas. Le script calcule les attributs dérivés tels que LengthOfStay et IsReadmission en triant les données par patient et par heure. Il exporte ensuite le journal d’événements nettoyé dans un fichier CSV nommé veradigm_patient_journey_log.csv.
Vérification finale : Ouvrez le fichier CSV généré. Vérifiez que les dates sont au format ISO 8601 (YYYY-MM-DD HH:MM:SS) et que les champs texte tels que ActivityName ne contiennent pas de caractères utilisés comme séparateurs.
Chargement : Importez le fichier CSV dans ProcessMind. Associez PatientEpisodeId à Case ID, ActivityName à Activity et EventDateTime à Timestamp.

Configuration

API_URL : URL de base des services de l’API Unity. Elle varie selon l’installation du client, sur site ou dans le cloud. Vérifiez que le protocole https est correct.
Appname : identifiant unique de l’application enregistré auprès de Veradigm/Allscripts. Il détermine l’étendue des accès aux données.
Période : la période d’extraction recommandée est de 3 à 6 mois. Les périodes plus longues peuvent entraîner un dépassement de délai ; envisagez un traitement par mois si le volume est important.
Paramètres de délai : le script utilise par défaut un délai de 30 secondes pour les appels API. Augmentez-le si le système DSE est fortement sollicité.
Traitement par lots : le script parcourt les rencontres une par une. Pour les systèmes à fort volume, il peut être nécessaire de le modifier afin de récupérer les données en masse, si les points de terminaison le permettent, ou d’exécuter des threads en parallèle.
Logique de correspondance : le script associe OrderType aux activités. Vérifiez que les codes de type de commande propres à votre système, par exemple « Lab » ou « Rad », correspondent à la logique de la fonction process_orders.

a Exemple de requête python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_URL = class="hl-string">"https://unity.veradigm.com/[YourEnvironment]/unity/unityservice.svc/json"
APP_NAME = class="hl-string">"[YourAppName]"
USER_ID = class="hl-string">"[YourUserID]"
PASSWORD = class="hl-string">"[YourPassword]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"veradigm_patient_journey_log.csv"

class=class="hl-string">"hl-comment"># Global Session Token
TOKEN = None

def get_security_token():
    class="hl-string">"""Authenticate and retrieve security token."""
    payload = {
        class="hl-string">"Action": class="hl-string">"GetToken",
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Username": USER_ID,
        class="hl-string">"Password": PASSWORD
    }
    try:
        response = requests.post(API_URL, json=payload)
        response.raise_for_status()
        data = response.json()
        class=class="hl-string">"hl-comment"># Depending on Unity version, token might be in body or header. Assuming body here.
        return data[0][class="hl-string">'Token'] if isinstance(data, list) else data.get(class="hl-string">'Token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def make_unity_request(action, params):
    class="hl-string">"""Wrapper for Unity API calls."""
    payload = {
        class="hl-string">"Action": action,
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Token": TOKEN
    }
    payload.update(params)
    
    try:
        response = requests.post(API_URL, json=payload, timeout=30)
        response.raise_for_status()
        class=class="hl-string">"hl-comment"># Unity often returns a list of dictionaries
        return response.json()
    except Exception as e:
        print(fclass="hl-string">"API Call Error ({action}): {e}")
        return []

def extract_patient_journey():
    global TOKEN
    TOKEN = get_security_token()
    if not TOKEN:
        return

    print(class="hl-string">"Token acquired. Starting extraction...")
    
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Get Encounters within Date Range
    class=class="hl-string">"hl-comment"># Using GetEncounterInfo or similar search action
    encounters = make_unity_request(class="hl-string">"GetEncounterInfo", {
        class="hl-string">"StartEncounterDate": START_DATE,
        class="hl-string">"EndEncounterDate": END_DATE
    })

    print(fclass="hl-string">"Found {len(encounters)} encounters. Processing details...")

    for enc in encounters:
        try:
            class=class="hl-string">"hl-comment"># Basic Encounter Data
            episode_id = str(enc.get(class="hl-string">'EncounterID'))
            patient_id = enc.get(class="hl-string">'PatientID')
            mrn = enc.get(class="hl-string">'MRN', class="hl-string">'')
            admit_time = enc.get(class="hl-string">'EncounterDate') class=class="hl-string">"hl-comment"># ISO string expected
            discharge_time = enc.get(class="hl-string">'DischargeDate')
            dept_name = enc.get(class="hl-string">'Department', class="hl-string">'General')
            attending = enc.get(class="hl-string">'ProviderName', class="hl-string">'Unknown')
            
            class=class="hl-string">"hl-comment"># --- Activity: Patient Registered ---
            if admit_time:
                event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Registered",
                    class="hl-string">"EventDateTime": admit_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># --- Activity: Patient Discharged ---
            if discharge_time:
                 event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Discharged",
                    class="hl-string">"EventDateTime": discharge_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># 2. Get Orders (Labs, Procedures, Consults)
            orders = make_unity_request(class="hl-string">"GetOrders", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for order in orders:
                order_time = order.get(class="hl-string">'OrderDate')
                order_type = order.get(class="hl-string">'OrderType', class="hl-string">'').lower()
                order_name = order.get(class="hl-string">'OrderName', class="hl-string">'Unknown Order')
                
                class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Ordered ---
                if class="hl-string">'lab' in order_type or class="hl-string">'imaging' in order_type or class="hl-string">'radiology' in order_type:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Ordered",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_OrderName": order_name
                    })

                class=class="hl-string">"hl-comment"># --- Activity: Procedure Performed ---
                class=class="hl-string">"hl-comment"># Often procedures are orders with status completed or specific types
                if class="hl-string">'procedure' in order_type and order.get(class="hl-string">'Status') == class="hl-string">'Completed':
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Procedure Performed",
                        class="hl-string">"EventDateTime": order.get(class="hl-string">'CompletionDate', order_time),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ProcedureName": order_name
                    })
                    
                class=class="hl-string">"hl-comment"># --- Activity: Discharge Planning Initiated ---
                if class="hl-string">'discharge' in order_name.lower():
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Discharge Planning Initiated",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 3. Get Results (Lab completion)
            results = make_unity_request(class="hl-string">"GetResults", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for res in results:
                result_time = res.get(class="hl-string">'ResultDate')
                if result_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Completed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Completed",
                        class="hl-string">"EventDateTime": result_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ResultName": res.get(class="hl-string">'TestName', class="hl-string">'Unknown Test')
                    })

            class=class="hl-string">"hl-comment"># 4. Get Problems (Diagnosis)
            problems = make_unity_request(class="hl-string">"GetPatientProblems", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for prob in problems:
                onset_date = prob.get(class="hl-string">'OnsetDate') or prob.get(class="hl-string">'DateEntered')
                if onset_date:
                     class=class="hl-string">"hl-comment"># --- Activity: Diagnosis Confirmed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnosis Confirmed",
                        class="hl-string">"EventDateTime": onset_date,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"PrimaryDiagnosisCode": prob.get(class="hl-string">'ICD10', class="hl-string">''),
                        class="hl-string">"Attribute_DiagnosisName": prob.get(class="hl-string">'ProblemDescription', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 5. Get Vitals
            vitals = make_unity_request(class="hl-string">"GetVitals", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for vit in vitals:
                taken_time = vit.get(class="hl-string">'DateTaken')
                if taken_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Vitals Recorded ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Vitals Recorded",
                        class="hl-string">"EventDateTime": taken_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 6. Get Clinical Notes (Assessments, Plans)
            class=class="hl-string">"hl-comment"># Sometimes accessed via GetNoteInfo or GetChart
            notes = make_unity_request(class="hl-string">"GetNoteInfo", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for note in notes:
                note_date = note.get(class="hl-string">'NoteDate')
                note_title = note.get(class="hl-string">'DocumentType', class="hl-string">'').lower()
                
                class=class="hl-string">"hl-comment"># --- Activity: Initial Assessment Completed ---
                if class="hl-string">'initial' in note_title or class="hl-string">'assessment' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Initial Assessment Completed",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })
                
                class=class="hl-string">"hl-comment"># --- Activity: Treatment Plan Created ---
                if class="hl-string">'plan' in note_title or class="hl-string">'care' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Treatment Plan Created",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 7. Med Administration (GetMedicationAdministration or inferred from Med History)
            meds = make_unity_request(class="hl-string">"GetMedicationAdministration", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for med in meds:
                admin_time = med.get(class="hl-string">'AdministrationDate')
                if admin_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Medication Administered ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Medication Administered",
                        class="hl-string">"EventDateTime": admin_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_MedicationName": med.get(class="hl-string">'MedicationName', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 8. Transfer Events (Infer from ADT or Audit log)
            class=class="hl-string">"hl-comment"># Simulating transfer extraction via AuditLog for Location changes
            audit_logs = make_unity_request(class="hl-string">"GetAuditLog", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for log in audit_logs:
                if class="hl-string">"Transfer" in log.get(class="hl-string">'EventName', class="hl-string">'') or class="hl-string">"Location Change" in log.get(class="hl-string">'EventName', class="hl-string">''):
                     class=class="hl-string">"hl-comment"># --- Activity: Transfer to Department ---
                     event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Transfer to Department",
                        class="hl-string">"EventDateTime": log.get(class="hl-string">'EventDate'),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"DepartmentName": log.get(class="hl-string">'NewValue', class="hl-string">'Unknown Dept')
                     })

            class=class="hl-string">"hl-comment"># 9. Follow-up Scheduled
            if discharge_time:
                future_appts = make_unity_request(class="hl-string">"GetSchedule", {class="hl-string">"PatientID": patient_id, class="hl-string">"StartDate": discharge_time})
                for appt in future_appts:
                    class=class="hl-string">"hl-comment"># --- Activity: Follow-up Scheduled ---
                    class=class="hl-string">"hl-comment"># Note: We want the time the appt was BOOKED, but Unity usually gives ApptDate.
                    class=class="hl-string">"hl-comment"># We will use the creation date of the appt if available, otherwise ApptDate as proxy
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Follow-up Scheduled",
                        class="hl-string">"EventDateTime": appt.get(class="hl-string">'DateBooked', appt.get(class="hl-string">'ApptDate')), 
                        class="hl-string">"PatientMrn": mrn
                    })

        except Exception as e:
            print(fclass="hl-string">"Error processing encounter {enc.get('EncounterID')}: {e}")
            continue

    class=class="hl-string">"hl-comment"># Post-Processing: Create DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Helper: Convert strings to datetime
    df[class="hl-string">'EventDateTime'] = pd.to_datetime(df[class="hl-string">'EventDateTime'], errors=class="hl-string">'coerce')
    df = df.dropna(subset=[class="hl-string">'EventDateTime', class="hl-string">'PatientEpisodeId'])
    
    class=class="hl-string">"hl-comment"># Calculate LOS and Readmission
    df[class="hl-string">'AdmissionDate'] = pd.to_datetime(df[class="hl-string">'AdmissionDate'], errors=class="hl-string">'coerce')
    df[class="hl-string">'DischargeDate'] = pd.to_datetime(df[class="hl-string">'DischargeDate'], errors=class="hl-string">'coerce')
    
    class=class="hl-string">"hl-comment"># LOS
    df[class="hl-string">'LengthOfStay'] = (df[class="hl-string">'DischargeDate'] - df[class="hl-string">'AdmissionDate']).dt.days

    class=class="hl-string">"hl-comment"># IsReadmission (Simplified: check if patient had previous discharge within 30 days)
    class=class="hl-string">"hl-comment"># Requires sorting by patient and admission time first
    class=class="hl-string">"hl-comment"># This is complex in a flat event log context, simplified here as placeholder logic
    df[class="hl-string">'IsReadmission'] = False 

    print(fclass="hl-string">"Extraction complete. Rows: {len(df)}")
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Data saved to {OUTPUT_FILE}")

if __name__ == class="hl-string">"__main__":
    extract_patient_journey()

Prêt à commencer ?

Commencez dès aujourd’hui à optimiser l’expérience des patients et l’efficacité opérationnelle. Vos données vous permettront de révéler des analyses utiles et d’apporter des améliorations significatives.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

Réduisez de 30 % la durée des parcours des patients et améliorez les résultats de soins.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Commencez immédiatement.

Votre modèle de données du parcours patient

Votre modèle de données du parcours patient

Attributs du parcours du patient

Activités du parcours du patient

Guides d’extraction

Export du journal d’événements du moteur d’interface Allscripts

Étapes

Configuration

a Exemple de requête config

Extraction de l’API Veradigm Unity avec Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

Votre modèle de données du parcours patient

Votre modèle de données du parcours patient

Attributs du parcours du patient

Activités du parcours du patient

Guides d’extraction

Export du journal d’événements du moteur d’interface Allscripts

Étapes

Configuration

a Exemple de requête config

Extraction de l’API Veradigm Unity avec Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui les parcours des patients dans Veradigm

Nous attachons de l’importance à votre confidentialité