> Miglioramento continuo dei processi > Percorso del paziente > Veradigm (Allscripts) > Template dei dati

Il template dei dati per il percorso assistenziale dei pazienti

Veradigm (Allscripts)

Attributi del percorso assistenziale del paziente(19) Attività del percorso assistenziale del paziente(13) Guide all’estrazione(2)

Il template dei dati per il percorso assistenziale dei pazienti

Questo template offre un metodo strutturato per raccogliere i dati necessari ad analizzare il percorso assistenziale dei pazienti. Indica gli attributi e le attività essenziali da monitorare e fornisce indicazioni pratiche su come estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per preparare i dati per un’analisi completa con il Process Mining.

Attributi consigliati da raccogliere per un’analisi completa
Attività chiave da monitorare per individuare correttamente i processi
Indicazioni pratiche per estrarre i dati dal sistema

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi del percorso assistenziale del paziente

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il percorso assistenziale dei pazienti.

3 Obbligatorio 8 Consigliato 8 Facoltativo

	Nome	Descrizione
	Data e ora dell’evento EventDateTime	La data e l’ora esatte in cui si è verificata l’attività.
Descrizione Registra il momento in cui si è verificata l’attività. È un dato fondamentale per calcolare i tempi di ciclo e le durate e per ordinare correttamente la sequenza degli eventi. Nei dati sanitari, la precisione al minuto è essenziale per analizzare accuratamente il flusso dei pazienti. Perché è importante Consente di calcolare tutti i KPI basati sul tempo, compresi il tempo di ciclo medio del percorso del paziente e i tempi di attesa. Dove reperirli Date e orari delle transazioni nelle tabelle di origine (ad esempio, ADT_DATE, ORDER_DATE, RESULT_DATE). Esempi 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Episodio del paziente PatientEpisodeId	Identificativo univoco della visita o dell’accesso specifico del paziente.
Descrizione L’episodio del paziente è l’identificativo principale del caso e raggruppa tutti gli eventi relativi al percorso sanitario del paziente per una determinata condizione o un periodo di cura. Consente di avere una visione integrata delle fasi di diagnosi, trattamento e recupero, collegando in un quadro coerente le interazioni con i diversi reparti. Nei sistemi Veradigm (Allscripts), come Sunrise o Paragon, corrisponde in genere all’ID della visita o al numero dell’accesso. Perché è importante È la chiave fondamentale per il Process Mining, perché consente di ricostruire il percorso del paziente dall’inizio alla fine. Dove reperirli Probabilmente si trova nell’intestazione delle tabelle Visit o Encounter (ad esempio, VISIT_ID, ENCOUNTER_ID). Consulti la documentazione di Veradigm (Allscripts). Esempi EP-2023-998877VIS-10029384100029384ENC-554433
	Nome dell’attività ActivityName	L’evento clinico o amministrativo specifico che si è verificato.
Descrizione Descrive la fase del processo, ad esempio «Paziente registrato», «Farmaco somministrato» o «Pianificazione della dimissione avviata». Questo attributo distingue le diverse fasi del percorso del paziente ed è essenziale per l’individuazione dei processi e l’analisi delle varianti. Perché è importante Definisce i nodi della mappa del processo; senza questo dato non è possibile visualizzare il flusso del processo. Dove reperirli Ricavato da diverse tabelle transazionali: eventi ADT, ordini, risultati e tabelle della documentazione clinica. Esempi Paziente registratoEsame diagnostico richiestoFarmaco somministratoPaziente dimesso
	Codice della diagnosi principale PrimaryDiagnosisCode	Il codice ICD-10 o SNOMED che rappresenta la condizione principale.
Descrizione La motivazione codificata della visita del paziente. Questo attributo consente di filtrare l’esplorazione delle varianti dei percorsi terapeutici e di confrontare il flusso nel sistema per condizioni diverse, ad esempio polmonite e insufficienza cardiaca. Perché è importante Necessario per segmentare i processi in base alla condizione clinica e verificare il rispetto dei protocolli. Dove reperirli Tabelle delle diagnosi o dell’elenco dei problemi (in genere, colonne ICD-10). Consulti la documentazione di Veradigm (Allscripts). Esempi I50.9J18.9E11.9
	Data di dimissione DischargeDate	La data e l’ora della dimissione del paziente.
Descrizione Il timestamp che segna la fine dell’episodio. Serve a chiudere il caso nel Process Mining ed è essenziale per calcolare ALOS e i rientri in ospedale. Perché è importante Definisce la fine del ciclo del processo ed è fondamentale per analizzare il flusso. Dove reperirli Tabella di intestazione della visita/dell’accesso (ad es. DISCH_DATE). Consultare la documentazione di Veradigm (Allscripts). Esempi 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Data di ricovero AdmissionDate	La data e l’ora del ricovero formale del paziente.
Descrizione La data e l’ora che segnano l’inizio della degenza. Utilizzata insieme alla data di dimissione per calcolare la durata della degenza (ALOS). Perché è importante Punto di riferimento fondamentale per calcolare la durata media della degenza e misurare i ritardi nei ricoveri. Dove reperirli Tabella di intestazione Visit/Encounter (ad esempio, ADMIT_DATE). Consulti la documentazione di Veradigm (Allscripts). Esempi 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Destinazione alla dimissione DischargeDisposition	Stato o destinazione del paziente al momento della dimissione.
Descrizione Indica dove si è recato il paziente dopo il ricovero (ad es. «A casa», «Struttura di assistenza infermieristica specializzata», «Deceduto», «Trasferito»). È un dato importante per analizzare il rischio di rientro in ospedale, poiché ogni destinazione comporta un diverso profilo di rischio. Perché è importante Fornisce il contesto per la Dashboard «Pianificazione della dimissione» e aiuta a spiegare le variazioni di ALOS. Dove reperirli Tabella di intestazione della visita/dell’accesso (ad es. DISCH_DISP). Consultare la documentazione di Veradigm (Allscripts). Esempi A casaTrasferito in una struttura di assistenza infermieristica specializzataA casa con assistenza domiciliareDimissione contro il parere medico
	Medico curante AttendingProvider	Il professionista sanitario principalmente responsabile del paziente durante l’evento.
Descrizione Identifica il medico, l’infermiere o lo specialista che svolge l’attività o è responsabile del piano di cura. Analizzare questo attributo aiuta a comprendere l’utilizzo delle risorse cliniche e le differenze nei percorsi di cura in base al medico. Perché è importante Consente di analizzare i colli di bottiglia nell’impiego delle risorse e confrontare le prestazioni del personale clinico. Dove reperirli Tabelle transazionali (ad esempio, ORDERing_PROVIDER, ATTENDING_PHYSICIAN_ID). Consulti la documentazione di Veradigm (Allscripts). Esempi Dott.ssa Sarah SmithInfermiera specializzata JonesTecnico di radiologia A
	Nome del reparto DepartmentName	L’unità o il reparto ospedaliero in cui si è svolta l’attività.
Descrizione Indica il contesto in cui si è svolta l’attività, ad esempio «Pronto soccorso», «Cardiologia» o «Radiologia». È fondamentale per l’analisi dei colli di bottiglia nei ricoveri e nei trasferimenti, perché permette di individuare i reparti in cui i pazienti restano in attesa durante gli spostamenti. Perché è importante Supporta l’analisi dell’utilizzo delle risorse e l’individuazione dei colli di bottiglia nei reparti. Dove reperirli Tabelle principali delle località o dei reparti collegate alla transazione. Consulti la documentazione di Veradigm (Allscripts). Esempi Pronto soccorsoICUChirurgia generaleRadiologia
	Numero di cartella clinica del paziente (MRN) PatientMrn	Numero di cartella clinica che identifica in modo univoco il paziente nei diversi episodi.
Descrizione Il numero di cartella clinica (MRN) o l’ID aziendale del paziente. A differenza dell’ID dell’episodio del paziente, questo identificativo rimane invariato tra le diverse visite. È la chiave fondamentale per collegare episodi distinti e calcolare il tasso di riammissione. Perché è importante Essenziale per calcolare il «tasso di riammissione entro 30 giorni» e individuare i pazienti che tornano. Dove reperirli Indice principale dei pazienti o tabelle anagrafiche (probabili colonne: MRN, PATIENT_ID). Consulti la documentazione di Veradigm (Allscripts). Esempi MRN-884422P-10022399887766
	Rientro in ospedale IsReadmission	Indicatore che segnala se l’episodio corrisponde a un nuovo ricovero entro 30 giorni.
Descrizione Attributo booleano calcolato. Restituisce true se il paziente è stato dimesso nei 30 giorni precedenti la data del ricovero attuale. Questo dato alimenta il «Monitoraggio dei rientri evitabili in ospedale». Perché è importante Indicatore chiave di prestazione fondamentale per la qualità ospedaliera e i rimborsi, in particolare nell’ambito delle normative CMS. Dove reperirli Calcolato nel livello ETL/di trasformazione dei dati utilizzando PatientMRN e le date di ricovero e dimissione. Esempi truefalse
	Centro di costo CostCenter	Codice finanziario associato al reparto o al servizio.
Descrizione Associa l’attività clinica a un’unità finanziaria. Aiuta ad analizzare i costi delle attività o i risultati finanziari generici dei diversi reparti. Perché è importante Collega il Process Mining operativo alle ricadute finanziarie. Dove reperirli Tabelle dei reparti o delle tariffe. Consultare la documentazione di Veradigm (Allscripts). Esempi CC-1020CC-Rad-01Emergency-001
	Conformità al protocollo IsProtocolCompliant	Indicatore che segnala se il caso ha seguito il percorso assistenziale standard.
Descrizione Attributo calcolato che verifica se determinate attività obbligatorie, ad esempio «Parametri vitali registrati» prima di «Farmaco somministrato», si sono svolte nell’ordine corretto. Supporta la Dashboard «Aderenza ai protocolli assistenziali». Perché è importante Consente di rilevare automaticamente le mancate conformità, senza dover rivedere manualmente le cartelle cliniche. Dove reperirli Calcolato nello strumento di Process Mining o nel livello ETL in base alla sequenza delle attività. Esempi truefalse
	Data dell’appuntamento di controllo FollowUpAppointmentDate	Data dell’appuntamento di controllo programmato.
Descrizione Utilizzato per calcolare il «Tasso di appuntamenti di controllo programmati». Se il campo contiene un valore, significa che è stato fissato un appuntamento di controllo; se è nullo o vuoto, l’appuntamento non è stato fissato. Perché è importante Misura direttamente l’indicatore chiave di prestazione «Conformità alle cure di controllo». Dove reperirli Sistema di pianificazione degli appuntamenti o tabella degli appuntamenti futuri collegata al paziente. Consultare la documentazione di Veradigm (Allscripts). Esempi 2023-11-15T14:00:00Znull
	ID ordine OrderId	Identificativo degli ordini specifici (analisi di laboratorio, farmaci, procedure).
Descrizione Collega l’evento «Ordine» all’evento «Risultato» o «Somministrazione». Ad esempio, associa «Esame diagnostico ordinato» a «Esame diagnostico completato». Questo livello di dettaglio è necessario per la Dashboard «Tempi di esecuzione degli esami diagnostici». Perché è importante Consente di calcolare la durata di singole fasi del processo (ad es. i tempi di esecuzione delle analisi di laboratorio). Dove reperirli Tabelle di inserimento degli ordini (ad es. ORDER_ID, PLACER_ORDER_NUM). Consultare la documentazione di Veradigm (Allscripts). Esempi ORD-998877LAB-112233RX-445566
	Nome del farmaco MedicationName	Nome del farmaco prescritto o somministrato.
Descrizione Utilizzato in particolare per la Dashboard «Intervalli nei tempi di somministrazione dei farmaci». Aiuta a individuare eventuali ritardi nella somministrazione di farmaci specifici, come antibiotici o analgesici. Perché è importante È fondamentale per analizzare la sicurezza clinica e ottimizzare i processi della farmacia. Dove reperirli Registro delle somministrazioni dei farmaci (MAR) o ordini della farmacia. Consultare la documentazione di Veradigm (Allscripts). Esempi AmoxicillinaEparinaSolfato di morfina
	Sistema di origine SourceSystem	Il nome del sistema da cui provengono i dati.
Descrizione Identifica l’istanza software che fornisce i dati, ad esempio «Veradigm Sunrise» o «Veradigm TouchWorks». È particolarmente importante negli ambienti con più ospedali o quando si uniscono dati provenienti da strutture per acuti e ambulatoriali. Perché è importante Garantisce la tracciabilità e la provenienza dei dati, utili per individuare e risolvere i problemi di qualità dei dati. Dove reperirli Impostato in modo fisso durante il processo ETL oppure estratto dalle tabelle dei metadati di sistema. Esempi Veradigm SunriseAllscripts PMVeradigm TouchWorks
	Tempi di esecuzione degli esami diagnostici DiagnosticTurnaroundTime	Tempo che intercorre tra l’ordine di un esame e la disponibilità del risultato.
Descrizione Durata calcolata tra «Esame diagnostico ordinato» e «Diagnosi confermata» (o ricezione del risultato). Utilizzata per la «Panoramica sui tempi di esecuzione degli esami diagnostici». Perché è importante Tempi di esecuzione elevati prolungano la degenza; questa metrica individua i ritardi nei laboratori e in radiologia. Dove reperirli Calcolo: Timestamp(Risultato) - Timestamp(Ordine). Esempi 2 ore45 minuti1,5 giorni
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultima estrazione o dell’ultimo aggiornamento del record.
Descrizione Indica quanto sono aggiornati i dati utilizzati per l’analisi. Questo campo aiuta a capire se si stanno consultando dati in tempo reale o un’istantanea relativa a un periodo precedente. Perché è importante Garantisce trasparenza sui ritardi di aggiornamento dei dati e agevola le strategie di caricamento incrementale. Dove reperirli Data e ora generate dal sistema durante l’esecuzione del processo ETL o di estrazione. Esempi 2023-11-01T23:59:59Z2023-11-02T06:00:00Z

Obbligatorio Consigliato Facoltativo

Attività del percorso assistenziale del paziente

Queste sono le fasi e le tappe fondamentali da registrare nell’Event Log per individuare correttamente il processo di assistenza del paziente.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Diagnosi confermata	Questa attività indica che un medico ha registrato ufficialmente una diagnosi nella cartella del paziente. Può essere rilevata quando viene aggiunto un codice diagnostico all’elenco dei problemi o quando viene firmata una nota clinica che riporta la diagnosi.
Perché è importante La conferma della diagnosi è un passaggio decisivo, perché determina il successivo percorso terapeutico. Consente di analizzare le differenze nei percorsi di cura in base alle diverse diagnosi. Dove reperirli L’informazione si trova nell’elenco dei problemi del paziente, nei record delle diagnosi associate all’accesso o nella documentazione clinica. Può essere dedotta dalla data e dall’ora in cui il codice della diagnosi principale viene inserito e finalizzato per l’accesso. Acquisizione Utilizzi la data e l’ora di creazione o aggiornamento della diagnosi principale relativa allo specifico episodio del paziente. Tipo di evento inferred
	Paziente dimesso	Segna la fine ufficiale dell’episodio di ricovero, quando il paziente viene formalmente dimesso dalla struttura. È un evento chiave esplicito, registrato dal sistema ADT, che aggiorna lo stato dell’accesso del paziente a «dimesso».
Perché è importante È la principale attività conclusiva della maggior parte dei percorsi dei pazienti. È fondamentale per calcolare la durata media della degenza (ALOS) e il tempo di ciclo complessivo del processo. Dove reperirli L’evento è registrato esplicitamente nel modulo ADT. Il record dell’accesso del paziente riporta la data e l’ora della dimissione e la destinazione. Acquisizione Utilizzi la data e l’ora della dimissione riportate nel record principale dell’accesso o della visita del paziente. Tipo di evento explicit
	Paziente registrato	Segna l’inizio ufficiale dell’episodio del paziente, quando le sue informazioni vengono inserite nel sistema Veradigm. In genere, l’evento viene registrato esplicitamente al termine del flusso di lavoro di registrazione, quando un utente crea una nuova scheda di accesso del paziente con un identificativo univoco e una data e un’ora.
Perché è importante È la principale attività iniziale del percorso del paziente. È essenziale per calcolare il tempo di ciclo complessivo del processo, la durata della degenza e il tasso di pazienti assistiti. Dove reperirli L’evento viene registrato nel modulo di registrazione del paziente o nel modulo ADT (Admission, Discharge, Transfer). Cerchi la data e l’ora di creazione della scheda di accesso o della visita del paziente. Acquisizione Data e ora della creazione della scheda di accesso del paziente o della registrazione, ricavate dalla relativa tabella. Tipo di evento explicit
	Pianificazione della dimissione avviata	Indica l’avvio formale della pianificazione della dimissione del paziente. Può essere dedotto dalla creazione di un documento di pianificazione della dimissione, dall’inserimento di un ordine di dimissione o dal completamento di una specifica valutazione per la pianificazione della dimissione.
Perché è importante Questa attività è il punto di partenza per misurare l’efficienza del processo di dimissione. Avviare la pianificazione per tempo è spesso associato a un minor tasso di riammissioni. Dove reperirli Si ricava dalla data e dall’ora di creazione di una nota di pianificazione della dimissione, di un insieme di ordini di dimissione o di un modulo di valutazione specifico in Veradigm. Acquisizione Individui la data e l’ora in cui viene creato per la prima volta un ordine o un documento relativo alla dimissione per l’accesso del paziente. Tipo di evento inferred
	Piano terapeutico creato	Indica la formalizzazione del piano terapeutico del paziente da parte dell’équipe clinica. Spesso viene registrato quando nella cartella clinica elettronica viene creato e firmato un documento specifico, come il «Piano di assistenza», o un insieme iniziale di ordini terapeutici.
Perché è importante Questa tappa segna l’inizio della fase di trattamento attivo. Costituisce la base di riferimento per misurare l’aderenza ai protocolli di cura e il tempo che precede il primo intervento terapeutico, ad esempio la somministrazione di un farmaco. Dove reperirli Si ricava dalla data e dall’ora della firma del modulo «Piano di assistenza» o dalla data e dall’ora di creazione del primo insieme significativo di ordini terapeutici successivi alla diagnosi. Acquisizione Individui la data e l’ora in cui il documento «Piano di assistenza» viene finalizzato o firmato dal medico curante. Tipo di evento inferred
	Valutazione iniziale completata	Indica il completamento della prima valutazione clinica da parte di un infermiere o di un medico, ad esempio il triage o la valutazione iniziale all’accettazione. Spesso viene registrato quando un modulo o una nota clinica specifica, come «Valutazione infermieristica iniziale», viene firmata e finalizzata nella cartella clinica elettronica.
Perché è importante Questa attività è una tappa iniziale fondamentale. Il tempo che intercorre tra la registrazione e la valutazione evidenzia possibili ritardi nell’accettazione del paziente e nelle prime cure. Dove reperirli Si ricava dalla data e dall’ora di finalizzazione o firma dei moduli di valutazione iniziale o delle note cliniche nei moduli di documentazione clinica di Veradigm. Acquisizione Individui la data e l’ora in cui lo stato della nota o del modulo di valutazione iniziale passa a «completato» o «firmato». Tipo di evento inferred
	Controllo successivo programmato	Questa attività indica la programmazione di un appuntamento di controllo per il paziente dopo la dimissione. L’evento viene registrato nel modulo di pianificazione degli appuntamenti quando si prenota un appuntamento associato all’accesso concluso con la dimissione.
Perché è importante Programmare le cure successive è fondamentale per garantire la continuità assistenziale e ridurre le riammissioni. Questa attività consente di misurare il rispetto dei protocolli successivi alla dimissione. Dove reperirli L’evento è registrato nel modulo di pianificazione degli appuntamenti. Cerchi la data e l’ora di creazione di un nuovo appuntamento per il paziente, successivo alla data di dimissione. Acquisizione Individui la data e l’ora di creazione di un appuntamento nel sistema di pianificazione, associato al paziente. Tipo di evento explicit
	Esame diagnostico completato	Indica il momento in cui i risultati di un esame diagnostico vengono finalizzati e resi disponibili nella cartella del paziente. In genere, si deduce dal passaggio dello stato dell’ordine originale da «attivo» o «in corso» a «completato» o «con risultato».
Perché è importante Questa attività è una tappa fondamentale per misurare i tempi degli esami diagnostici. I ritardi tra la richiesta e il completamento possono allungare notevolmente i tempi per arrivare alla diagnosi. Dove reperirli Si ricava dal campo dello stato dell’ordine nel modulo degli ordini o dalle date e dagli orari registrati nel modulo dei risultati corrispondente, ad esempio LIS o RIS. Acquisizione Individui la data e l’ora in cui lo stato dell’ordine passa a uno stato finale, come «Completato» o «Con risultato». Tipo di evento inferred
	Esame diagnostico richiesto	L’evento si verifica quando un medico richiede un esame diagnostico, ad esempio un’analisi di laboratorio o un esame di diagnostica per immagini. Viene registrato esplicitamente tramite il sistema Computerized Physician Order Entry (CPOE) di Veradigm.
Perché è importante Segna l’inizio del sottoprocesso diagnostico. È il punto di partenza per misurare i tempi degli esami diagnostici e individuare i ritardi nelle richieste. Dove reperirli L’evento è registrato nel modulo degli ordini o nei log del sistema CPOE. Ogni ordine riporta la data e l’ora in cui è stato inserito. Acquisizione Estragga la data e l’ora di creazione dai record degli ordini relativi agli esami diagnostici pertinenti. Tipo di evento explicit
	Farmaco somministrato	L’evento viene registrato quando un infermiere o un medico documenta la somministrazione di un farmaco al paziente. L’informazione è acquisita nel modulo Medication Administration Record (MAR) o eMAR, che registra l’ora esatta della somministrazione.
Perché è importante Monitorare la somministrazione dei farmaci è essenziale per analizzare la tempestività e l’aderenza al trattamento. L’intervallo tra la prescrizione e la somministrazione aiuta a individuare i ritardi nel processo di somministrazione dei farmaci. Dove reperirli L’evento è registrato esplicitamente nel modulo eMAR (electronic Medication Administration Record). Ogni somministrazione riporta una data e un’ora specifiche, il farmaco e il dosaggio. Acquisizione Estragga dalla tabella eMAR le date e gli orari di ogni somministrazione di farmaci associata all’accesso del paziente. Tipo di evento explicit
	Parametri vitali registrati	L’attività si verifica ogni volta che vengono registrati i parametri vitali del paziente, come frequenza cardiaca, pressione arteriosa e temperatura. È un evento esplicito, acquisito nella documentazione clinica o nella sezione del diario clinico elettronico dedicata ai parametri vitali.
Perché è importante La registrazione frequente dei parametri vitali indica che il paziente è sottoposto a monitoraggio attivo. È possibile analizzarne la frequenza e i tempi per verificare il rispetto dei protocolli di monitoraggio. Dove reperirli L’evento è registrato nel repository dei dati clinici o nelle tabelle del diario clinico elettronico in cui sono archiviati i parametri vitali. Ogni registrazione riporta una data e un’ora. Acquisizione Estragga le date e gli orari dai dati del diario clinico elettronico relativi ai parametri vitali dell’accesso del paziente. Tipo di evento explicit
	Procedura eseguita	Indica il completamento di una procedura clinica o chirurgica. In genere, viene registrato quando un medico firma la nota della procedura o quando il relativo ordine viene contrassegnato come «completato» nel sistema.
Perché è importante Le procedure rappresentano tappe importanti in molti percorsi dei pazienti. Analizzarne i tempi aiuta a comprendere l’utilizzo delle risorse e l’efficienza della pianificazione. Dove reperirli Si ricava dalla data e dall’ora della firma della nota relativa alla procedura nel modulo di documentazione clinica o dalla data e dall’ora di completamento dell’ordine corrispondente nel modulo degli ordini. Acquisizione Utilizzi la data e l’ora di completamento dell’ordine della procedura oppure la data e l’ora della firma della relativa documentazione. Tipo di evento inferred
	Trasferimento a un reparto	L’evento segna il trasferimento fisico del paziente da un reparto o un’unità di cura a un altro, ad esempio dal pronto soccorso a un reparto di degenza. Viene registrato dal sistema ADT (Admission, Discharge, Transfer) di Veradigm.
Perché è importante I trasferimenti dei pazienti sono momenti in cui si verificano spesso colli di bottiglia e ritardi. Analizzarne la durata e la frequenza aiuta a ottimizzare il flusso dei pazienti e l’allocazione delle risorse tra i reparti. Dove reperirli L’evento è registrato esplicitamente nel modulo ADT. Ogni trasferimento riporta il paziente, la località di provenienza e quella di destinazione, oltre alla data e all’ora. Acquisizione Estragga dal sistema ADT gli Event Log relativi agli spostamenti dei pazienti. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Veradigm (Allscripts)

Passaggi

Individui il canale dell’interfaccia di destinazione: acceda alla console di gestione di Allscripts Interface Engine (AIE). Individui il canale di interfaccia principale che elabora i messaggi in ingresso dall’EHR, in genere denominato 'EHR_Inbound' o in modo simile. Verifichi che gestisca i tipi di messaggio ADT, SIU, ORM, ORU, RAS e DFT, così da acquisire tutte le attività del percorso del paziente.
Crei un nuovo canale di inoltro/esportazione: crei un nuovo canale di destinazione denominato 'ProcessMining_Export'. Imposti il tipo di output su 'File Writer'. Il canale riceverà una copia dei messaggi dal canale di origine e li convertirà in un file semplice (CSV) per ProcessMind.
Configuri l’instradamento dei messaggi: nelle regole di instradamento di AIE, configuri una regola di copia/instradamento per inviare i messaggi dal canale EHR principale al nuovo canale 'ProcessMining_Export'. Imposti un filtro che includa solo i tipi di messaggio necessari: ADT (registrazione/trasferimento), SIU (pianificazione), ORM (Ordini), ORU (risultati/parametri vitali), RAS (farmaci) e DFT (fatturazione/procedure).
Definisca la logica di trasformazione: nel canale 'ProcessMining_Export', apra l’editor Transformation/Script. Dovrà implementare uno script di analisi (vedere la sezione 'query' qui sotto) che legga i segmenti HL7 grezzi e associ specifici eventi trigger e codici di stato ai nomi delle attività standard richiesti, ad esempio associando 'ADT^A01' a 'Paziente registrato'.
Associ gli attributi ai campi HL7: verifichi che lo script estragga 'PatientEpisodeId' dal segmento PV1-19 (numero di visita) e 'PatientMrn' da PID-3. Associ 'EventDateTime' a MSH-7 o EVN-2. Estragga i dettagli clinici, come 'DepartmentName' da PV1-3 e 'AttendingProvider' da PV1-7.
Imposti i parametri del file di output: configuri le impostazioni di File Writer. Imposti la directory di output su un percorso di rete sicuro e definisca la convenzione per i nomi dei file, ad esempio EventLog_YYYYMMDD_HH.csv. Imposti la modalità file su 'Append' per aggiungere continuamente righe al registro.
Gestisca delimitatori e caratteri di escape: nello script, verifichi che i campi di testo, come diagnosi o nome del reparto, siano ripuliti da virgole e a capo, così da non compromettere la struttura CSV.
Attivi e verifichi il canale: avvii il canale 'ProcessMining_Export'. Generi un evento di prova nell’ambiente di test di Veradigm, ad esempio registrando un paziente di prova. Verifichi che nel file CSV compaia una nuova riga con il nome dell’attività e la data e ora corretti.
Configuri la rotazione dei registri: imposti una rotazione, ad esempio ogni giorno a mezzanotte, per chiudere il file CSV corrente e avviarne uno nuovo. In questo modo i file manterranno dimensioni gestibili per il caricamento.
Riproduca i dati storici (facoltativo): se servono dati storici, utilizzi lo strumento 'Message Browser' o 'Log Replay' di AIE per reinviare i registri HL7 archiviati degli ultimi 3-6 mesi attraverso il canale 'ProcessMining_Export'. Tenga sotto controllo le prestazioni del sistema per evitare rallentamenti.
Recuperi e formatti i dati: acceda alla directory di output, recuperi i file CSV generati e verifichi che le intestazioni corrispondano ai requisiti. Se necessario, unisca i file giornalieri.
Carichi i dati in ProcessMind: importi il set di dati finale in ProcessMind, associando 'PatientEpisodeId' a ID del caso, 'ActivityName' ad Attività e 'EventDateTime' alla data e ora.

Configurazione

Tipo di canale: File Writer / output del file system
Eventi trigger: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Codifica file: UTF-8 (fondamentale per i caratteri speciali nei nomi e nelle diagnosi)
Delimitatore: virgola (,) o barra verticale (|)
Formato data: si consiglia ISO 8601 (YYYY-MM-DDTHH:MM:SS) per la conversione delle date e ore HL7
Rotazione dei registri: giornaliera o al superamento di 100 MB
Modalità di scrittura: Append (non sovrascrivere)
Prestazioni: verifichi che lo script di trasformazione sia leggero, per evitare l’accumulo di messaggi in coda nel motore.

Query di esempio 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);
}

Passaggi

Prerequisiti e accesso: verifichi di disporre di credenziali valide per l’API Veradigm (Allscripts) Unity. Le servirà un Appname (nome dell’applicazione) autorizzato per l’organizzazione, oltre a un UserID e una Password validi (o un token) per l’autenticazione. Verifichi che l’account utente possa accedere ai domini clinici (incontri, Ordini, risultati, parametri vitali, problemi).
Configurazione dell’ambiente: installi Python 3.8 o versione successiva. Installi le librerie necessarie con pip: pip install requests pandas. Serviranno per inviare richieste HTTP all’API Unity e manipolare i dati ottenuti.
Configurazione: apra lo script Python fornito e individui la sezione CONFIGURATION all’inizio. Aggiorni API_URL con l’endpoint dell’ambiente Unity in uso, ad esempio unity.veradigm.com o un gateway interno. Sostituisca le credenziali segnaposto ([YourAppName], [YourUserID] e così via) con quelle effettive. Imposti START_DATE e END_DATE per definire il periodo di analisi desiderato.
Panoramica della logica dello script: lo script si autentica prima presso l’API per ottenere un token di sicurezza. Chiama quindi GetEncounterInfo per recuperare tutti gli episodi dei pazienti compresi nell’intervallo di date specificato. L’elenco degli incontri costituisce il punto di partenza dell’estrazione.
Ciclo di estrazione delle attività: per ogni EncounterID individuato, lo script effettua chiamate API secondarie a endpoint specifici. Chiama GetOrders per individuare esami diagnostici e procedure, GetResults per identificare gli esami completati, GetVitals per recuperare le registrazioni dei parametri vitali e GetPatientProblems per le diagnosi confermate. Scorre inoltre le note cliniche per individuare valutazioni e piani terapeutici.
Trasformazione dei dati: quando l’API restituisce dati JSON grezzi, lo script analizza campi specifici e li associa allo schema di ProcessMind. Ad esempio, OrderDateTime viene associato a EventDateTime per l’attività 'Esame diagnostico prescritto'. Lo script applica in modo uniforme PatientEpisodeId (ID dell’incontro) a tutti i record correlati.
Gestione di ADT e trasferimenti: la logica dello script controlla lo storico delle ubicazioni dell’incontro, se disponibile tramite specifiche chiamate secondarie Audit o ADT, oppure deduce i trasferimenti dai cambi di reparto riportati nella documentazione clinica, per generare eventi 'Trasferimento al reparto'.
Logica dei controlli successivi: dopo aver elaborato l’incontro, lo script interroga GetSchedule per lo stesso PatientID e cerca date di appuntamento successive a DischargeDate, così da generare l’attività 'Controllo successivo pianificato'.
Convalida: lo script include una fase di convalida locale che stampa nella console il numero di righe per tipo di attività. Riveda i risultati e verifichi che nessun tipo di attività abbia zero record, salvo i casi previsti.
Esportazione: il set di dati finale viene aggregato in un DataFrame Pandas. Lo script calcola attributi derivati, come LengthOfStay e IsReadmission, ordinando i dati per paziente e data e ora. Infine, esporta l’Event Log ripulito in un file CSV denominato veradigm_patient_journey_log.csv.
Revisione finale: apra il file CSV generato. Verifichi che le date siano nel formato ISO 8601 (YYYY-MM-DD HH:MM:SS) e che i campi di testo, come ActivityName, non contengano caratteri usati come delimitatori.
Caricamento: importi il file CSV in ProcessMind. Associ PatientEpisodeId a ID del caso, ActivityName ad Attività e EventDateTime alla data e ora.

Configurazione

API_URL: URL di base dei servizi API Unity. Varia a seconda dell’installazione del cliente, ad esempio locale o cloud. Verifichi che il protocollo https sia corretto.
Appname: identificativo univoco dell’applicazione registrata presso Veradigm/Allscripts. Determina l’ambito di accesso ai dati.
Intervallo di date: si consiglia un periodo di estrazione di 3-6 mesi. Gli intervalli più ampi potrebbero causare timeout; se il volume è elevato, valuti di suddividere l’estrazione per mese.
Impostazioni di timeout: lo script imposta per impostazione predefinita un timeout di 30 secondi per le chiamate API. Lo aumenti se il sistema EHR è sottoposto a un carico elevato.
Elaborazione in batch: lo script scorre gli incontri uno per uno. Nei sistemi con volumi elevati potrebbe essere necessario modificarlo per recuperare i dati in blocco, se gli endpoint lo consentono, oppure eseguire thread paralleli.
Logica di associazione: lo script associa OrderType alle attività. Verifichi che i codici specifici dei tipi di Ordini del sistema, ad esempio 'Laboratorio' e 'Radiologia', siano coerenti con la logica della funzione process_orders.

Query di esempio 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()

È pronto a iniziare?

Inizi oggi a migliorare l’esperienza dei pazienti e l’efficienza operativa. I dati a Sua disposizione possono rivelare informazioni preziose e aiutarLa a ottenere miglioramenti significativi.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi oggi i percorsi dei pazienti in Veradigm

Riduca del 30% i tempi di ciclo dei pazienti e migliori gli esiti delle cure.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi subito.

Il template dei dati per il percorso assistenziale dei pazienti

Il template dei dati per il percorso assistenziale dei pazienti

Attributi del percorso assistenziale del paziente

Attività del percorso assistenziale del paziente

Guide all’estrazione

Esportazione dell’Event Log dall’Interface Engine di Allscripts

Passaggi

Configurazione

Query di esempio config

Estrazione tramite Python dall’API Veradigm Unity

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Ottimizzi oggi i percorsi dei pazienti in Veradigm