> Amélioration Continue des Processusus > Parcours de soins > Veradigm (Allscripts) > Template de données

Votre modèle de données du Parcours Patient

Veradigm (Allscripts)

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

Votre modèle de données du Parcours Patient

Ce modèle offre une approche structurée pour la collecte des données nécessaires à l'analyse de vos processus de parcours patient. Il décrit les attributs et 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 de Process Mining.

Attributs recommandés à collecter pour une analyse complète
Activités clés à suivre pour une découverte précise des processus
Conseils pratiques pour l'extraction des données de votre système

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs du parcours patient

Ce sont les champs de données recommandés à inclure dans votre Journal d'événements pour une analyse complète du processus du parcours patient.

3 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Descriptionn
	Épisode patient PatientEpisodeId	Identifiant unique pour la visite ou la consultation spécifique du patient.
Descriptionn L'Épisode Patient sert d'identifiant de dossier principal, regroupant tous les événements liés au parcours de soins spécifique d'un patient pour une condition ou une période de soins donnée. Cela permet une vue intégrée des phases de diagnostic, de traitement et de rétablissement, reliant diverses interactions départementales en un tout cohérent. Dans les systèmes Veradigm (Allscripts) (comme Sunrise ou Paragon), cela correspond généralement à l'ID de Visite ou au Numéro de Consultation. Pourquoi est-ce important ? : C'est l'élément clé pour le Process Mining, permettant de reconstituer le parcours patient complet. Source des données : Probablement trouvé dans l'en-tête des tables de visite ou de consultation (par exemple, VISIT_ID, ENCOUNTER_ID). Consultez la documentation Veradigm (Allscripts). Exemples EP-2023-998877VIS-10029384100029384ENC-554433
	Horodatage de l'événement EventDateTime	La date et l'heure exactes de l'activité.
Descriptionn Enregistre le point chronologique de l'activité. Ceci est indispensable pour calculer les temps de cycle, les durées et ordonner correctement la séquence des événements. Dans les données de santé, une précision à la minute près est fondamentale pour une analyse précise du débit. Pourquoi est-ce important ? : Permet le calcul de tous les KPI basés sur le temps, y compris le temps de cycle moyen du parcours patient et les temps d'attente. Source des données : Dates/heures de transaction dans les tables sources (par exemple, ADT_DATE, ORDER_DATE, RESULT_DATE). Exemples 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Nom de l'activité ActivityName	L'événement clinique ou administratif spécifique effectué.
Descriptionn Décrit l'étape réalisée dans le processus, telle que « Patient enregistré », « Médicament administré » ou « Planification de la sortie initiée ». Cet attribut différencie les différentes étapes du parcours patient et est indispensable pour la découverte de processus et l'analyse des variantes. Pourquoi est-ce important ? : Définit les nœuds dans la carte de processus ; sans cela, aucun flux de processus ne peut être visualisé. Source des données : Dérivé de diverses tables transactionnelles : événements ADT, Commandes, Résultats et tables de Documentation Clinique. Exemples Patient enregistréTest diagnostique commandéMédicament administréPatient sorti
	Code de diagnostic principal PrimaryDiagnosisCode	Le code CIM-10 ou SNOMED représentant la condition principale.
Descriptionn La raison codifiée de la visite du patient. Cet attribut est le filtre pour l'« Explorateur de variations de parcours de traitement ». Il permet aux analystes de comparer la façon dont différentes conditions (par exemple, pneumonie vs insuffisance cardiaque) évoluent dans le système. Pourquoi est-ce important ? : Requis pour segmenter les processus par condition clinique et vérifier l'adhésion au protocole. Source des données : Tables de diagnostic ou de liste de problèmes (généralement des colonnes CIM-10). Consultez la documentation Veradigm (Allscripts). Exemples I50.9J18.9E11.9
	Date d'admission AdmissionDate	La date et l'heure de l'admission formelle du patient.
Descriptionn La date/heure marquant le début du séjour hospitalier. Utilisée conjointement avec la Date de sortie pour calculer la Durée de séjour (DMS). Pourquoi est-ce important ? : Point de repère essentiel pour le calcul de la DMS et la mesure des retards d'admission. Source des données : Table d'en-tête Visite/Consultation (par exemple, ADMIT_DATE). Consultez la documentation Veradigm (Allscripts). Exemples 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Date de sortie DischargeDate	La date et l'heure de la sortie du patient.
Descriptionn La date/heure marquant la fin de l'épisode. Ceci est utilisé pour clôturer le cas dans le Process Mining et est indispensable pour les calculs de DMS et de Réadmission. Pourquoi est-ce important ? : Définit la fin du cycle de processus ; essentiel pour l'analyse du débit. Source des données : Table d'en-tête Visite/Consultation (par exemple, DISCH_DATE). Consultez la documentation Veradigm (Allscripts). Exemples 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Médecin traitant AttendingProvider	Le clinicien principal responsable du patient pendant l'événement.
Descriptionn Identifie le médecin, l'infirmière ou le spécialiste réalisant l'activité ou responsable du plan de soins. L'analyse de cet attribut aide à comprendre l'« Utilisation des ressources cliniques » et les variations des parcours de soins par médecin. Pourquoi est-ce important ? : Permet l'analyse des points de blocage des ressources et l'étalonnage des performances du personnel clinique. Source des données : Tables de transaction (par exemple, ORDERing_PROVIDER, ATTENDING_PHYSICIAN_ID). Consultez la documentation Veradigm (Allscripts). Exemples Dr. Sarah SmithNurse Practitioner JonesRadiology Tech A
	Modalité de sortie DischargeDisposition	Le statut ou la localisation du patient à la sortie.
Descriptionn Indique où le patient est allé après le séjour hospitalier (par ex., « Domicile », « Établissement de soins de suite et de réadaptation (SSR) », « Décédé », « Transfert »). Ceci est important pour analyser les risques de réadmission, car différentes dispositions comportent différents profils de risque. Pourquoi est-ce important ? : Contextualise le tableau de bord « Planification de la sortie » et aide à expliquer les variations de la DMS. Source des données : Table d'en-tête Visite/Consultation (par exemple, DISCH_DISP). Consultez la documentation Veradigm (Allscripts). Exemples AccueilTransféré vers un établissement de soinsDomicile avec soins à domicileSortie contre avis médical
	MRN du patient PatientMrn	Numéro de dossier médical identifiant de manière unique le patient à travers les épisodes.
Descriptionn Le Numéro de Dossier Médical (NDM) ou l'ID Patient Entreprise. Contrairement à l'ID d'Épisode Patient, cet ID reste constant pour le patient à travers les différentes visites. C'est la clé critique pour lier des épisodes distincts afin de calculer les taux de réadmission. Pourquoi est-ce important ? : Primordial pour le « Taux de réadmission à 30 jours » et l'identification des clients récurrents. Source des données : Index principal des patients ou tables démographiques (colonnes probables : MRN, PATIENT_ID). Consultez la documentation Veradigm (Allscripts). Exemples MRN-884422P-10022399887766
	Nom du service DepartmentName	L'unité hospitalière ou le service où l'activité a eu lieu.
Descriptionn Indique le contexte de localisation, tel que « Urgences », « Cardiologie » ou « Radiologie ». Ceci est indispensable à l'« Analyse des points de blocage d'admission et de transfert » afin de voir où les patients sont bloqués lors des transferts entre les services. Pourquoi est-ce important ? : Prend en charge l'analyse de l'utilisation des ressources et l'identification des points de blocage des services. Source des données : Tables maîtresses de localisation ou de service liées à la transaction. Consultez la documentation Veradigm (Allscripts). Exemples Service des urgencesUSIChirurgie généraleRadiology
	Réadmission IsReadmission	Indicateur signalant si cet épisode est une réadmission dans les 30 jours.
Descriptionn Un attribut booléen calculé. Il renvoie vrai si le patient a eu une sortie antérieure dans les 30 jours suivant la date d'admission actuelle. Ceci alimente le « Moniteur de taux de réadmission évitable ». Pourquoi est-ce important ? : KPI essentiel pour la qualité hospitalière et le remboursement (en particulier pour les réglementations CMS). Source des données : Calculé dans la couche ETL/transformation de données à l'aide des dates PatientMRN et d'admission/sortie. Exemples truefaux
	Centre de coûts CostCenter	Le code financier associé au service ou à la prestation.
Descriptionn Associe l'activité clinique à une unité financière. Cela aide à analyser le 'Coût d'activité' ou la performance financière générique de différents services. Pourquoi est-ce important ? : Connecte le Process Mining opérationnel à l'impact financier. Source des données : Tables des départements ou du plan comptable. Consultez la documentation Veradigm (Allscripts). Exemples CC-1020CC-Rad-01Emergency-001
	Conforme au protocole IsProtocolCompliant	Indicateur signalant si le cas a suivi le parcours de soins standard.
Descriptionn Un attribut calculé qui vérifie si des activités obligatoires spécifiques (par ex., « Signes vitaux enregistrés » avant « Médicament administré ») ont eu lieu dans le bon ordre. Prend en charge le « Tableau de bord d'adhérence au protocole de soins ». Pourquoi est-ce important ? : Automatise la détection des non-conformités sans révision manuelle des dossiers. Source des données : Calculé dans l'outil de Process Mining ou l'ETL en fonction de la séquence d'activités. Exemples truefaux
	Date du rendez-vous de suivi FollowUpAppointmentDate	Date du rendez-vous de suivi programmé.
Descriptionn Utilisé pour calculer le 'Taux de rendez-vous de suivi programmés'. Si ce champ est renseigné, cela indique qu'un suivi a été programmé. S'il est nul/vide, ce n'est pas le cas. Pourquoi est-ce important ? : Mesure directement le KPI « Conformité des soins de suivi ». Source des données : Système de planification ou table des futurs rendez-vous liés au patient. Consultez la documentation Veradigm (Allscripts). Exemples 2023-11-15T14:00:00Znull
	Délai de traitement diagnostique DiagnosticTurnaroundTime	Durée entre la commande de test et le résultat du test.
Descriptionn Durée calculée entre « Test diagnostique commandé » et « Diagnostic confirmé » (ou résultat reçu). Utilisé pour l'« Aperçu du délai de traitement diagnostique ». Pourquoi est-ce important ? : Des délais de traitement élevés prolongent la durée de séjour ; cette métrique identifie les retards de laboratoire/radiologie. Source des données : Calculé : Horodatage(Résultat) - Horodatage(Commande). Exemples 2 heures45 minutes1,5 jours
	Dernière mise à jour des données LastDataUpdate	Date/heure de la dernière extraction ou mise à jour de l'enregistrement.
Descriptionn Indique la la réactualisation des données utilisées pour l'analyse. Ce champ aide les utilisateurs à comprendre s'ils examinent des données en temps réel ou un instantané d'une période antérieure. Pourquoi est-ce important ? : Assure la transparence concernant la latence des données et aide aux stratégies de chargement de données incrémentiel. Source des données : Date/heure générée par le système lors de l'exécution de l'ETL/extraction. Exemples 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	ID commande OrderId	Identifiant pour des commandes spécifiques (Laboratoires, Médicaments, Procédures).
Descriptionn Lie l'événement 'Commande' à l'événement 'Résultat' ou 'Administration'. Par exemple, lier 'Test diagnostique commandé' à 'Test diagnostique effectué'. Cette granularité est requise pour le tableau de bord des 'Délais d'exécution des diagnostics'. Pourquoi est-ce important ? : Permet le calcul des durées d'étapes de processus spécifiques (par ex., temps de traitement du laboratoire). Source des données : Tables de saisie des commandes (par exemple, ORDER_ID, PLACER_ORDER_NUM). Consultez la documentation Veradigm (Allscripts). Exemples ORD-998877LAB-112233RX-445566
	Nom du médicament MedicationName	Le nom du médicament commandé ou administré.
Descriptionn Utilisé spécifiquement pour le tableau de bord des 'Écarts de temps d'administration des médicaments'. Il aide à identifier si des médicaments spécifiques (par exemple, antibiotiques, gestion de la douleur) subissent des retards d'administration. Pourquoi est-ce important ? : Critique pour l'analyse de la sécurité clinique et l'optimisation des processus de pharmacie. Source des données : Dossier d'administration des médicaments (MAR) ou commandes de pharmacie. Consultez la documentation Veradigm (Allscripts). Exemples AmoxicillinHeparinMorphine Sulfate
	Système source SourceSystem	Le nom du système d'où proviennent les données.
Descriptionn Identifie l'instance logicielle fournissant les données, telle que « Veradigm Sunrise » ou « Veradigm TouchWorks ». Ceci est particulièrement important dans les environnements multi-hospitaliers ou lors de la fusion de données provenant de milieux de soins aigus et ambulatoires. Pourquoi est-ce important ? : Fournit une traçabilité et une traçabilité des données, ce qui est utile lors du débogage des problèmes de qualité des données. Source des données : Codé en dur pendant le 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 patient

Ce sont les étapes clés du processus et les jalons à capturer dans votre Journal d'événements pour une découverte précise du processus du parcours patient.

6 Recommandé 7 Facultatif

	Activité	Descriptionn
	Diagnostic confirmé	Cette activité signifie qu'un clinicien a officiellement enregistré un diagnostic dans le dossier du patient. Cela peut être capturé lorsqu'un code de diagnostic est ajouté à la liste des problèmes ou lorsqu'une note clinique contenant le diagnostic est signée.
Pourquoi est-ce important ? : La confirmation du diagnostic est un tournant crucial qui dicte la voie de traitement ultérieure. Elle permet d'analyser les variations des parcours de traitement en fonction des différents diagnostics. Source des données : Trouvé dans la liste des problèmes du patient, les enregistrements de diagnostic de la rencontre ou la documentation clinique. Il peut être déduit de l'horodatage lorsqu'un code de diagnostic principal est saisi et finalisé pour la rencontre. Capture Utilisez la date/heure de création ou de mise à jour de l'entrée du diagnostic principal pour l'épisode patient spécifique. Type d'événement inferred
	Évaluation initiale terminée	Représente l'achèvement de la première évaluation clinique par une infirmière ou un médecin, comme le triage ou l'admission initiale. Ceci est souvent capturé lorsqu'un formulaire ou une note clinique spécifique, tel qu'une 'Évaluation initiale infirmière', est signé et finalisé dans le DSE.
Pourquoi est-ce important ? : Cette activité est un jalon précoce clé. Le temps entre l'enregistrement et cette évaluation met en évidence les retards potentiels dans l'admission du patient et les soins initiaux. Source des données : Déduit de l'horodatage de finalisation ou de signature des formulaires d'évaluation initiale ou des notes cliniques danss modules de documentation clinique de Veradigm. Capture Identifier l'horodatage lorsque le statut de la note ou du formulaire d'évaluation initiale est passé à « terminé » ou « signé ». Type d'événement inferred
	Patient enregistré	Marque le début officiel de l'épisode patient lorsque les informations du patient sont saisies dans le système Veradigm. Cet événement est généralement capturé explicitement lorsqu'un utilisateur complète le workflow d'enregistrement, créant un nouveau dossier de consultation patient avec un identifiant unique et une date/heure.
Pourquoi est-ce important ? : C'est l'activité de début principale du parcours patient. Elle est indispensablele pour le calcul du temps de cycle global du processus, de la durée de séjour et des taux de débit patient. Source des données : Cet événement est enregistré dans le module d'enregistrement du patient ou ADT (Admission, Sortie, Transfert). Recherchez la date/heure de création de la consultation ou du dossier de visite du patient. Capture Date/heure de la table de consultation patient ou d'enregistrement lors de la création de l'enregistrement. Type d'événement explicit
	Patient sorti	Marque la fin officielle de l'épisode d'hospitalisation, lorsque le patient est officiellement renvoyé de l'établissement. Il s'agit d'un événement explicite et clé capturé par le système ADT, qui met à jour le statut de la consultation du patient à 'sorti'.
Pourquoi est-ce important ? : C'est l'activité de fin principale pour la plupart des parcours patient. Elle est indispensable pour le calcul de la Durée Moyenne de Séjour (DMS) et du temps de cycle global du processus. Source des données : Comptabilisé explicitement dans le module ADT. Le dossier de rencontre du patient aura un horodatage de sortie et une disposition. Capture Utilisez la date/heure de sortie de la consultation principale ou du dossier de visite du patient. Type d'événement explicit
	Plan de traitement créé	Représente la formalisation du plan de traitement d'un patient par l'équipe clinique. Ceci est souvent capturé lorsqu'un document spécifique 'Plan de soins' ou un ensemble d'ordres de traitement initiaux est créé « what-if »gné dans le DSE.
Pourquoi est-ce important ? : Ce jalon initie la phase de traitement actif. C'est la référence pour mesurer l'adhésion aux protocoles de soins et le temps jusqu'à la première action de traitement, comme l'administration de médicaments. Source des données : Déduit de l'horodatage de signature sur un formulaire de « Plan de soins » ou de l'horodatage de création du premier ensemble majeur de commandes thérapeutiques après le diagnostic. Capture Trouvez l'horodatage lorsque un document de « Plan de soins » est finalisé ou signé par le clinicien traitant. Type d'événement inferred
	Planification de la sortie initiée	Représente le début formel du processus de planification de la sortie pour un patient. Cela peut être déduit de la création d'un document de plan de sortie, de la saisie d'un ordre de sortie ou de l'achèvement d'une évaluation spécifique de planification de sortie.
Pourquoi est-ce important ? : Cette activité est le point de départ pour mesurer l'efficacité du processus de sortie. Une initiation précoce de la planification est souvent corrélée à des taux de réadmission plus faibles. Source des données : Déduit de l'horodatage de création d'une note de planification de sortie, d'un ensemble de commandes de sortie ou d'un formulaire d'évaluation spécifique dans Veradigm. Capture Identifier l'horodatage de la première création d'une commande ou d'un document spécifique à la sortie pour la rencontre du patient. Type d'événement inferred
	Médicament administré	Cet événement est enregistré lorsqu'une infirmière ou un clinicien documente l'administration d'un médicament au patient. Ceci est capturé dans le Dossier d'Administration des Médicaments (MAR) ou le module eMAR, qui enregistre l'heure exacte de l'administration.
Pourquoi est-ce important ? : Le suivi de l'administration des médicaments est indispensable à analyser la rapidité et l'adhésion au traitement. L'écart entre la commande et l'administration aide à identifier les retards dans le processus de délivrance des médicaments. Source des données : Comptabilisé explicitement dans le module eMAR (Electronic Medication Administration Record). Chaque événement d'administration a un horodatage, un médicament et une posologie spécifiques. Capture Extrayez les horodatages de la table eMAR pour chaque événement d'administration de médicaments lié à la rencontre patient. Type d'événement explicit
	Procédure effectuée	Représente l'achèvement d'une procédure clinique ou chirurgicale. Ceci est généralement capturé lorsqu'un clinicien signe la note de procédure ou lorsque le statut de la commande de procédure est mis à jour à 'terminé' dans le système.
Pourquoi est-ce important ? : Les procédures sont des étapes importantes dans de nombreux parcours patient. L'analyse de leur chronologie aide à comprendre l'utilisation des ressources et l'efficacité de la planification. Source des données : Déduit de l'horodatage de signature d'une note de procédure dans le module de documentation clinique ou de l'horodatage d'achèvement dans le module des commandes pour cette procédure. Capture Utilisez la date/heure d'achèvement de la commande de procédure ou la date/heure de signature de la documentation de procédure associée. Type d'événement inferred
	Signes vitaux enregistrés	Cette activité se produit chaque fois que les signes vitaux d'un patient, tels que le rythme cardiaque, la tension artérielle et la température, sont enregistrés. Il s'agit d'un événement explicite capturé dans la documentationumentation clinique ou la section des feuilles de flux spécifiques aux signes vitaux du DSE.
Pourquoi est-ce important ? : L'enregistrement fréquent des signes vitaux indique une surveillance active du patient. La fréquence et le moment peuvent être analysés pour assurer la conformité aux protocoles de surveillance. Source des données : Comptabilisé dans le référentiel de données cliniques ou les tables de feuilles de flux où les signes vitaux sont stockés. Chaque entrée a une date/heure. Capture Extrayez les horodatages des données de la feuille de surveillance des signes vitaux pour la rencontre patient. Type d'événement explicit
	Suivi programmé	Cette activité représente la planification d'un rendez-vous de suivi pour le patient après la sortie. Cet événement est capturé dans le module de planification lorsqu'un rendez-vous est pris et est lié à la consultation de sortie.
Pourquoi est-ce important ? : S'assurer que les soins de suivi sont programmés est impératif pour la continuité des soins et la réduction des réadmissions. Cette activité aide à mesurer la conformité aux protocoles post-sortie. Source des données : Comptabilisé dans le module de planification des rendez-vous. Recherchez la date/heure de création d'un nouveau rendez-vous pour le patient qui a lieu après la date de sortie. Capture Identifier l'horodatage de création d'un enregistrement de rendez-vous dans le système de planification lié au patient. Type d'événement explicit
	Test diagnostique commandé	Cet événement se produit lorsqu'un clinicien passe une commande pour un test diagnostique, tel qu'un test de laboratoire ou une imagerie. Il est capturé explicitement via le système CPOE (Saisie des Prescriptions Informatisée) dans Veradigm.
Pourquoi est-ce important ? : Cela marque le début du sous-processus diagnostique. C'est le point de départ pour mesurer les délais d'exécution des diagnostics et identifier les retards dans la commande des procédures. Source des données : Comptabilisé dans le module des commandes ou les journaux du système CPOE. Chaque commande aura une date/heure indiquant quand elle a été passée. Capture Extrayez l'horodatage de création des enregistrements de saisie de commandes pour les tests diagnostiques pertinents. Type d'événement explicit
	Test diagnostique terminé	Représente le moment où les résultats d'un test diagnostique sont finalisés et mis à disposition dans le dossier du patient. Ceci est généralement déduit d'un changement de statut sur la commande originale de 'actif' ou 'en cours' à 'terminé' ou 'résultat obtenu'.
Pourquoi est-ce important ? : Cette activité est un jalon critique pour mesurer les délais d'exécution des diagnostics. Les retards entre la commande et l'achèvement peuvent avoir un impact significatif sur le délai de diagnostic. Source des données : Déduit du champ d'état de la commande dans le module des commandes ou des horodatages dans le module de résultats correspondant, comme le SIL ou le RIS. Capture Identifier l'horodatage lorsque le statut de la commande passe à un état terminal comme « Terminée » ou « Résultat obtenu ». Type d'événement inferred
	Transfert vers le service	Cet événement marque le transfert physique d'un patient d'un service ou d'une unité de soins à un autre, tel que des urgences à un service d'hospitalisation. Ceci est capturé par le système ADT (Admission, Sortie, Transfert) dans Veradigm.
Pourquoi est-ce important ? : Les transferts de patients sont des points courants de points de blocage et de retards. L'analyse de la durée et de la fréquence des transferts aide à optimiser le flux patient et l'allocation des ressources entre les services. Source des données : Comptabilisé explicitement dans le module ADT. Chaque événement de transfert inclut le patient, les lieux de/vers, et un horodatage. Capture Extrayez les journaux d'événements du système ADT correspondant aux mouvements des patients. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Veradigm (Allscripts)

Étapes

Identifier le canal d'interface cible : Connectez-vous à la console de gestion d'Allscripts Interface Engine (AIE). Localisez le canal d'interface principal traitant les messages entrants du DSE (généralement étiqueté « EHR_Inbound » ou similaire). Assurez-vous que ce canal gère les types de messages ADT, SIU, ORM, ORU, RAS et DFT pour capturer l'étendue complète des activités du parcours patient.
Créer un nouveau canal de passage/d'exportation : 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 un format de fichier plat (CSV) pour ProcessMind.
Configurer le routage des messages : Dans les règles de routage AIE, configurez une règle de copie/routage pour envoyer les messages du canal DSE principal vers le nouveau canal « ProcessMining_Export ». Filtrez le routage pour n'inclure que les types de messages nécessaires : ADT (enregistrement/transfert), SIU (planification), ORM (commandes), ORU (résultats/signes vitaux), RAS (médicaments) et DFT (facturation/procédures).
Définir la logique de transformation : Dans le canal « ProcessMining_Export », ouvrez l'éditeur de transformation/script. Vous devez implémenter un script de parsing (voir la section « query » ci-dessous) qui lit les segments HL7 bruts et mappe les événements déclencheurs et les codes d'état spécifiques aux noms d'activité standard requis (par ex., mapper « ADT^A01 » à « Patient Registered »).
Mapper les attributs aux champs HL7 : Assurez-vous que le script extrait le « PatientEpisodeId » du segment PV1-19 (numéro de visite) et le « PatientMrn » de PID-3. Mappez le « EventDateTime » à MSH-7 ou EVN-2. Extrayez les détails cliniques comme « (DepartmentName) » de PV1-3 et « AttendingProvider » de 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 ex., EventLog_YYYYMMDD_HH.csv). Définissez le mode de fichier sur « Append » pour ajouter continuellement des lignes au journal.
Gérer les délimiteurs et l'échappement : Dans le script, assurez-vous que les champs de texte (comme le diagnostic ou le nom du département) sont nettoyés pour supprimer les virgules ou les retours à la ligne afin d'éviter de casser la structure CSV.
Activer et tester : Démarrez le canal « ProcessMining_Export ». Déclenchez un événement de test dans l'environnement de test Veradigm (par ex., enregistrez un patient test). Vérifiez qu'une nouvelle ligne apparaît dans le fichier CSV avec le nom d'activité et l'horodatage corrects.
Configurer la rotation des journaux : Configurez un calendrier de rotation (par ex., quotidiennement à minuit) pour fermer le fichier CSV actuel et en démarrer un nouveau. Cela garantit que les fichiers sont d'une taille gérable pour le téléchargement.
Relecture des données historiques (facultatif) : Si des données historiques sont requises, utilisez l'outil « Message Browser » ou « 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 pour éviter les retards.
Récupérer et formater : Accédez au répertoire de sortie, récupérez les fichiers CSV générés et vérifiez que les en-têtes correspondent aux exigences. Combinez les fichiers quotidiens si nécessaire.
Télécharger sur ProcessMind : Importez l'ensemble de données final dans ProcessMind, en mappant « PatientEpisodeId » comme ID de cas, « (ActivityName) » comme activité et « EventDateTime » comme horodatage.

Configuration

Channel Type: Écriture de fichier / Sortie système de fichiers
Trigger Events: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
File Encoding: UTF-8 (Primordial pour les caractères spéciaux dans les noms/diagnostics)
Delimiter: Virgule (,) ou Barre verticale (|)
Date Format: ISO 8601 (YYYY-MM-DDTHH:MM:SS) recommandé pour la conversion des horodatages HL7
Log Rotation: Quotidien ou lorsque la taille du fichier dépasse 100 Mo
Write Mode: Ajouter (Ne pas écraser)
Performance: Assurez-vous que le script de transformation est léger pour éviter l'engorgement/le retard des 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 : Assurez-vous de disposer de justificatifs valides pour l'API Unity de Veradigm (Allscripts). Vous aurez besoin d'un Appname (Nom de l'application) autorisé pour votre organisation, ainsi que d'un UserID et d'un Password (ou d'un jeton) valides pour l'authentification. Vérifiez que le compte utilisateur dispose des autorisations nécessaires pour accéder aux domaines cliniques (rencontres, commandes, résultats, signes vitaux, problèmes).
Configuration de l'environnement : Installez Python 3.8 ou une version ultérieure. Installez les bibliothèques nécessaires à l'aide de pip : pip install requests pandas. Celles-ci seront utilisées pour effectuer des requêtes HTTP vers l'API Unity et manipuler les données résultantes.
Configuration : Ouvrez le script Python fourni. Localisez la section CONFIGURATION en haut. Mettez à jour l'API_URL pour qu'elle pointe vers le point de terminaison de votre environnement Unity spécifique (par exemple, unity.veradigm.com ou une passerelle interne). Remplacez les identifiants de l'espace réservé ([YourAppName], [YourUserID], etc.) par vos identifiants réels. Définissez START_DATE et END_DATE pour la fenêtre d'analyse souhaitée.
Aperçu de la logique du script : Le script fonctionne en s'authentifiant d'abord auprès de l'API pour obtenir un jeton de sécurité. Il appelle ensuite GetEncounterInfo pour récupérer tous les épisodes patients dans la plage de dates spécifiée. Cette liste de rencontres sert d'itérateur central pour 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 trouver les tests et procédures diagnostiques. Il appelle GetResults pour identifier les tests terminés. Il appelle GetVitals pour les enregistrements des signes vitaux. Il appelle GetPatientProblems pour les diagnostics confirmés. Il itère à travers les notes cliniques pour trouver les évaluations et les plans de traitement.
Transformation des données : Lorsque les données JSON brutes sont renvoyées par l'API, le script analyse des champs spécifiques pour les mapper au schéma ProcessMind. Par exemple, OrderDateTime est associé à EventDateTime pour l'activité « Diagnostic Test Ordered ». Le script garantit que le PatientEpisodeId (ID de rencontre) est appliqué de manière cohérente à tous les enregistrements enfants.
Gestion des ADT et des transferts : La logique du script inclut une vérification par rapport à l'historique de localisation de la rencontre (si disponible via des sous-appels d'audit ou ADT spécifiques) ou infère les transferts basés sur les changements de département dans la documentationumentation clinique pour générer des événements « Transfert vers le département ».
Logique de suivi : Après avoir traité la rencontre, le script interroge GetSchedule pour le même PatientID à la recherche de dates de rendez-vous qui se produisent après la DischargeDate pour générer l'activité « Follow-up Scheduled ».
Validation : Le script inclut une étape de validation locale qui imprime le nombre de lignes par type d'activité dans la console. Examinez cette sortie pour vous assurer qu'aucun type d'activité n'a zéro enregistrement (sauf si cela est prévu).
Exportation : L'ensemble de données final est agrégé dans un DataFrame Pandas. Le script calcule des attributs dérivés comme LengthOfStay et IsReadmission en triant les données par Patient et Heure. Enfin, il exporte le journal d'événements propre vers un fichier CSV nommé veradigm_patient_journey_log.csv.
Examen final : Ouvrez le fichier CSV généré. Vérifiez que les formats de date sont ISO 8601 (AAAA-MM-JJ HH:MM:SS) et que les champs de texte comme (ActivityName) ne contiennent pas de caractères délimiteurs.
Téléchargement : Importez le fichier CSV dans ProcessMind. Mappez PatientEpisodeId à l'ID de cas, (ActivityName) à l'activité et EventDateTime à l'horodatage.

Configuration

API_URL: L'URL de base des services API Unity. Cela varie selon l'installation du client (par ex., sur site ou dans le cloud). Assurez-vous que le protocole (https) est correct.
Appname: L'identifiant unique de l'application enregistré auprès de Veradigm/Allscripts. Cela contrôle la portée de l'accès aux données.
Date Range: La fenêtre d'extraction recommandée est de 3 à 6 mois. Les grandes plages peuvent entraîner des dépassements de délai ; envisagez un découpage par mois si le volume est élevé.
Timeout Settings: Le script utilise un délai d'attente par défaut de 30 secondes pour les appels API. Augmentez-le si le système DSE est fortement sollicité.
Batching: Le script itère par rencontre. Pour les systèmes à volume élevé, il peut être nécessaire de modifier le script pour récupérer les données en masse (si les points de terminaison le permettent) ou d'exécuter des threads parallèles.
Mapping Logic: Le script mappe « OrderType » aux activités. Assurez-vous que les codes de type de commande spécifiques de votre système (par ex., « Lab », « Rad ») sont alignés avec 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()

Votre modèle de données du Parcours Patient

Votre modèle de données du Parcours Patient

Attributs du parcours patient

Activités du parcours patient

Guides d'extraction

Exportation du journal d'événements d'Allscripts Interface Engine

Étapes

Configuration

a Exemple de requête config

Extraction API Veradigm Unity via Python

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez les parcours patient dans Veradigm dès aujourd'hui

Votre modèle de données du Parcours Patient

Votre modèle de données du Parcours Patient

Attributs du parcours patient

Activités du parcours patient

Guides d'extraction

Exportation du journal d'événements d'Allscripts Interface Engine

Étapes

Configuration

a Exemple de requête config

Extraction API Veradigm Unity via Python

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez les parcours patient dans Veradigm dès aujourd'hui