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

Il Suo Template dei dati sul percorso del paziente

Veradigm (Allscripts)

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

Il Suo Template dei dati sul percorso del paziente

Questo Template offre un approccio strutturato alla raccolta dei dati necessari per analizzare il processo relativo al percorso del paziente. Descrive gli attributi e le attività essenziali da monitorare, insieme a indicazioni pratiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per preparare i dati a un'analisi completa tramite Process Mining.

Attributi consigliati da raccogliere per un'analisi completa
Attività chiave da monitorare per una corretta individuazione del processo
Indicazioni pratiche per estrarre i dati dal Suo sistema

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

Scarica il Template

Attributi del percorso del paziente

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo relativo al percorso del paziente.

3 Obbligatorio 8 Consigliato 8 Facoltativo

	Nome	Descrizione
	Episodio del paziente PatientEpisodeId	Identificativo univoco della specifica visita o dell’incontro con il paziente.
Descrizione Il Patient Episode funge da identificativo principale del caso e raggruppa tutti gli eventi relativi allo specifico percorso sanitario del paziente per una determinata condizione o un determinato periodo di assistenza. Consente di ottenere una visione integrata delle fasi di diagnosi, trattamento e recupero, collegando le interazioni con i diversi reparti in un quadro coerente. Nei sistemi Veradigm (Allscripts), come Sunrise o Paragon, corrisponde generalmente al Visit ID o all’Encounter Number. Perché è importante È la chiave fondamentale per il Process Mining, poiché consente di ricostruire il Patient Journey end-to-end. Dove reperirlo Probabilmente si trova nell’intestazione delle tabelle Visit o Encounter, ad esempio VISIT_ID o ENCOUNTER_ID. Consultare la documentazione di Veradigm (Allscripts). Esempi EP-2023-998877VIS-10029384100029384ENC-554433
	Nome dell’attività ActivityName	Lo specifico evento clinico o amministrativo eseguito.
Descrizione Descrive la fase eseguita nel processo, come “Patient Registered”, “Medication Administered” o “Discharge Planning Initiated”. Questo attributo distingue le diverse fasi del Patient Journey ed è essenziale per la process discovery e l’analisi delle varianti. Perché è importante Definisce i nodi della process map; senza questo elemento non è possibile visualizzare alcun flusso di processo. Dove reperirlo Derivato da diverse tabelle transazionali: eventi ADT, ordini, risultati e tabelle di documentazione clinica. Esempi Paziente registratoEsame diagnostico richiestoFarmaco somministratoPaziente dimesso
	Timestamp dell’evento EventDateTime	La data e l’ora esatte in cui si è verificata l’attività.
Descrizione Registra il momento cronologico dell’attività. È fondamentale per calcolare tempi di ciclo e durate e per ordinare correttamente la sequenza degli eventi. Nei dati sanitari, una precisione al minuto è essenziale per un’analisi accurata del transito dei pazienti. Perché è importante Consente di calcolare tutti i KPI basati sul tempo, inclusi il tempo medio del ciclo del Patient Journey e i tempi di attesa. Dove reperirlo Timestamp delle transazioni nelle tabelle di origine, ad esempio ADT_DATE, ORDER_DATE e RESULT_DATE. Esempi 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Codice della diagnosi primaria PrimaryDiagnosisCode	Il codice ICD-10 o SNOMED che rappresenta la condizione principale.
Descrizione Il motivo codificato della visita del paziente. Questo attributo costituisce il filtro per il “Treatment Pathway Variation Explorer” e consente agli analisti di confrontare il modo in cui condizioni diverse, come polmonite e insufficienza cardiaca, attraversano il sistema. Perché è importante Necessario per segmentare i processi in base alla condizione clinica e verificare l’aderenza ai protocolli. Dove reperirlo Tabelle delle diagnosi o dell’elenco dei problemi, generalmente con colonne ICD-10. Consultare la documentazione di Veradigm (Allscripts). Esempi I50.9J18.9E11.9
	Data di dimissione DischargeDate	La data e l’ora in cui il paziente è stato dimesso.
Descrizione Il timestamp che segna la fine dell’episodio. Viene utilizzato per chiudere il caso nel Process Mining ed è essenziale per i calcoli relativi ad ALOS e riammissioni. Perché è importante Definisce la fine del ciclo di processo ed è fondamentale per l’analisi del transito dei pazienti. Dove reperirlo Tabella di intestazione Visit/Encounter, ad esempio 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 in cui il paziente è stato formalmente ricoverato.
Descrizione Il timestamp che segna l’inizio della degenza ospedaliera. Viene utilizzato insieme alla data di dimissione per calcolare la durata della degenza (ALOS). Perché è importante Punto di riferimento fondamentale per il calcolo dell’ALOS e la misurazione dei ritardi nel ricovero. Dove reperirlo Tabella di intestazione Visit/Encounter, ad esempio ADMIT_DATE. Consultare la documentazione di Veradigm (Allscripts). Esempi 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Destinazione alla dimissione DischargeDisposition	Lo stato o la destinazione del paziente al momento della dimissione.
Descrizione Indica dove si è recato il paziente dopo la degenza ospedaliera, ad esempio “Home”, “Skilled Nursing Facility”, “Expired” o “Transfer”. È importante per analizzare i rischi di riammissione, poiché destinazioni diverse comportano profili di rischio differenti. Perché è importante Fornisce il contesto per la Dashboard “Discharge Planning” e aiuta a spiegare le variazioni dell’ALOS. Dove reperirlo Tabella di intestazione Visit/Encounter, ad esempio DISCH_DISP. Consultare la documentazione di Veradigm (Allscripts). Esempi DomicilioTrasferito in struttura infermieristica qualificataDomicilio con assistenza sanitaria domiciliareDimesso contro il parere medico
	È un nuovo ricovero IsReadmission	Indicatore che segnala se questo episodio costituisce un nuovo ricovero entro 30 giorni.
Descrizione Attributo booleano calcolato. Restituisce true se il paziente ha avuto una dimissione precedente entro 30 giorni dalla data del ricovero corrente. Alimenta il monitor del tasso di riammissioni evitabili. Perché è importante KPI fondamentale per la qualità ospedaliera e i rimborsi, in particolare nell'ambito delle normative CMS. Dove reperirlo Calcolato nel livello ETL/di trasformazione dei dati utilizzando PatientMRN e le date di ricovero e dimissione. Esempi truefalse
	MRN del paziente PatientMrn	Medical Record Number che identifica univocamente il paziente nei diversi episodi.
Descrizione Il Medical Record Number (MRN) o Enterprise Patient ID. A differenza del Patient Episode ID, questo identificativo rimane invariato per il paziente nelle diverse visite. È la chiave fondamentale per collegare episodi distinti e calcolare i tassi di riammissione. Perché è importante Essenziale per il “tasso di riammissione entro 30 giorni” e per identificare i pazienti ricorrenti. Dove reperirlo Indice principale dei pazienti o tabelle demografiche, probabilmente con colonne MRN e PATIENT_ID. Consultare la documentazione di Veradigm (Allscripts). Esempi MRN-884422P-10022399887766
	Nome del reparto DepartmentName	L’unità o il reparto ospedaliero in cui si è svolta l’attività.
Descrizione Indica il contesto della sede, come “Emergency Room”, “Cardiology” o “Radiology”. È fondamentale per l’analisi dei colli di bottiglia nei ricoveri e nei trasferimenti, poiché consente di individuare i punti in cui i pazienti rimangono bloccati durante gli spostamenti tra i reparti. Perché è importante Supporta l’analisi dell’utilizzo delle risorse e l’identificazione dei colli di bottiglia nei reparti. Dove reperirlo Tabelle master delle sedi o dei reparti collegate alla transazione. Consultare la documentazione di Veradigm (Allscripts). Esempi Pronto soccorsoICUChirurgia generaleRadiologia
	Professionista responsabile AttendingProvider	Il medico o professionista sanitario principale responsabile del paziente durante l’evento.
Descrizione Identifica il medico, l’infermiere o lo specialista che esegue l’attività o è responsabile del piano assistenziale. L’analisi di questo attributo aiuta a comprendere l’utilizzo delle risorse cliniche e le variazioni dei percorsi assistenziali in base al medico. Perché è importante Consente di analizzare i colli di bottiglia delle risorse e confrontare le prestazioni del personale clinico. Dove reperirlo Tabelle transazionali, ad esempio ORDERing_PROVIDER e ATTENDING_PHYSICIAN_ID. Consultare la documentazione di Veradigm (Allscripts). Esempi Dott.ssa Sarah SmithNurse Practitioner JonesTecnico di radiologia A
	Centro di costo CostCenter	Codice finanziario associato al reparto o al servizio.
Descrizione Collega l'attività clinica a un'unità finanziaria. Aiuta ad analizzare il 'costo dell'attività' o le prestazioni finanziarie generiche dei diversi reparti. Perché è importante Collega il Process Mining operativo all'impatto finanziario. Dove reperirlo Tabelle dei reparti o del catalogo degli addebiti. Consultare la documentazione di Veradigm (Allscripts). Esempi CC-1020CC-Rad-01Emergency-001
	Conforme al protocollo IsProtocolCompliant	Indicatore che segnala se il caso ha seguito il percorso assistenziale standard.
Descrizione Attributo calcolato che verifica se specifiche attività obbligatorie, ad esempio 'Parametri vitali registrati' prima di 'Farmaco somministrato', si sono svolte nell'ordine corretto. Supporta la Dashboard sull'aderenza al protocollo assistenziale. Perché è importante Automatizza il rilevamento delle non conformità senza dover esaminare manualmente la cartella clinica. Dove reperirlo Calcolato nello strumento di Process Mining o nell'ETL sulla base della sequenza delle attività. Esempi truefalse
	Data dell'appuntamento di follow-up FollowUpAppointmentDate	Data dell'appuntamento di follow-up programmato.
Descrizione Utilizzato per calcolare il tasso di appuntamenti di follow-up programmati. Se questo campo è valorizzato, significa che è stato programmato un follow-up. Se è nullo o vuoto, il follow-up non è stato programmato. Perché è importante Misura direttamente il KPI della conformità alle cure di follow-up. Dove reperirlo Sistema di programmazione o tabella degli appuntamenti futuri collegata al paziente. Consultare la documentazione di Veradigm (Allscripts). Esempi 2023-11-15T14:00:00Znull
	ID dell’ordine OrderId	Identificativo degli ordini specifici, come analisi di laboratorio, farmaci e procedure.
Descrizione Collega l’evento “Order” all’evento “Result” o “Administration”. Ad esempio, collega “Diagnostic Test Ordered” a “Diagnostic Test Completed”. Questo livello di dettaglio è necessario per la Dashboard “Diagnostic Turnaround Time”. Perché è importante Consente di calcolare la durata di specifiche fasi del processo, come il tempo di esecuzione delle analisi di laboratorio. Dove reperirlo Tabelle di inserimento degli ordini, ad esempio ORDER_ID e PLACER_ORDER_NUM. Consultare la documentazione di Veradigm (Allscripts). Esempi ORD-998877LAB-112233RX-445566
	Nome del farmaco MedicationName	Il nome del farmaco richiesto o somministrato.
Descrizione Utilizzato specificamente per la Dashboard “Medication Administration Time Gaps”. Aiuta a individuare eventuali ritardi nella somministrazione di farmaci specifici, come antibiotici o farmaci per la gestione del dolore. Perché è importante Fondamentale per l’analisi della sicurezza clinica e l’ottimizzazione dei processi di farmacia. Dove reperirlo Registro di somministrazione 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, come “Veradigm Sunrise” o “Veradigm TouchWorks”. È particolarmente importante negli ambienti con più ospedali o quando si uniscono dati provenienti da contesti di assistenza per acuti e ambulatoriale. Perché è importante Fornisce tracciabilità e lineage dei dati, elementi utili per il debug dei problemi di qualità dei dati. Dove reperirlo Codificato durante il processo ETL o estratto dalle tabelle dei metadati del sistema. Esempi Veradigm SunriseAllscripts PMVeradigm TouchWorks
	Tempo di esecuzione diagnostica DiagnosticTurnaroundTime	Durata compresa tra la richiesta dell'esame e la disponibilità del risultato.
Descrizione Durata calcolata tra 'Esame diagnostico richiesto' e 'Diagnosi confermata' o ricezione del risultato. Utilizzata per la panoramica sui tempi di esecuzione diagnostica. Perché è importante Tempi di esecuzione elevati prolungano la durata della degenza; questa metrica individua i ritardi di laboratorio e radiologia. Dove reperirlo Calcolato come: Timestamp(Risultato) - Timestamp(Richiesta). Esempi 2 ore45 minuti1,5 giorni
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp dell’ultima estrazione o dell’ultimo aggiornamento del record.
Descrizione Indica l’aggiornamento dei dati utilizzati per l’analisi. Questo campo aiuta gli utenti a capire se stanno esaminando dati in tempo reale o un’istantanea relativa a un periodo precedente. Perché è importante Garantisce trasparenza rispetto alla latenza dei dati e supporta le strategie di caricamento incrementale dei dati. Dove reperirlo Timestamp generato dal sistema durante l’esecuzione dell’ETL o dell’estrazione. Esempi 2023-11-01T23:59:59Z2023-11-02T06:00:00Z

Obbligatorio Consigliato Facoltativo

Attività del percorso del paziente

Queste sono le fasi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per una corretta individuazione del processo relativo al percorso del paziente.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Avvio della pianificazione della dimissione	Rappresenta l’avvio formale del processo di pianificazione della dimissione del paziente. Può essere dedotto dalla creazione di un documento relativo al piano di dimissione, dall’inserimento di un ordine di dimissione o dal completamento di una specifica valutazione per la pianificazione della dimissione.
Perché è importante Questa attività costituisce il punto di partenza per misurare l’efficienza del processo di dimissione. L’avvio tempestivo della pianificazione è spesso correlato a tassi di riammissione più bassi. Dove reperirlo Deducibile dal timestamp di creazione di una nota di pianificazione della dimissione, di un set di ordini di dimissione o di uno specifico modulo di valutazione all’interno di Veradigm. Acquisizione Individuare il timestamp in cui viene creato per la prima volta un ordine o un documento specifico per la dimissione relativo all’incontro con il paziente. Tipo di evento inferred
	Diagnosi confermata	Questa attività indica che un medico ha registrato ufficialmente una diagnosi nella cartella del paziente. Può essere acquisita quando un codice diagnostico viene aggiunto all’elenco dei problemi o quando viene firmata una nota clinica contenente la diagnosi.
Perché è importante La conferma della diagnosi è un punto di svolta fondamentale che determina il successivo percorso terapeutico. Consente di analizzare le variazioni dei percorsi di trattamento in base alle diverse diagnosi. Dove reperirlo Si trova nell’elenco dei problemi del paziente, nei record delle diagnosi dell’incontro o nella documentazione clinica. Può essere dedotta dal timestamp in cui il codice della diagnosi primaria viene inserito e finalizzato per l’incontro. Acquisizione Utilizzare il timestamp di creazione o aggiornamento della voce relativa alla diagnosi primaria per lo specifico episodio del paziente. Tipo di evento inferred
	Paziente dimesso	Segna la conclusione ufficiale dell’episodio di degenza, quando il paziente viene formalmente dimesso dalla struttura. È un evento esplicito e fondamentale, acquisito dal sistema ADT, che aggiorna lo stato dell’incontro del paziente a “dimesso”.
Perché è importante Questa è l’attività finale principale per la maggior parte dei Patient Journey. È essenziale per calcolare la durata media della degenza (ALOS) e il tempo complessivo del ciclo di processo. Dove reperirlo Registrato esplicitamente nel modulo ADT. Il record dell’incontro con il paziente presenta un timestamp di dimissione e la relativa destinazione. Acquisizione Utilizzare il timestamp di dimissione del record principale dell’incontro o della visita del paziente. Tipo di evento explicit
	Paziente registrato	Segna l’inizio ufficiale dell’episodio del paziente, quando le informazioni del paziente vengono inserite nel sistema Veradigm. Questo evento viene generalmente acquisito in modo esplicito quando un utente completa il Workflow di registrazione, creando un nuovo record dell’incontro con il paziente dotato di un identificativo univoco e di un timestamp.
Perché è importante Questa è l’attività iniziale principale del Patient Journey. È essenziale per calcolare il tempo complessivo del ciclo di processo, la durata della degenza e i tassi di transito dei pazienti. Dove reperirlo Questo evento viene registrato nel modulo di registrazione dei pazienti o nel modulo ADT (Admission, Discharge, Transfer). Occorre individuare il timestamp di creazione del record dell’incontro o della visita del paziente. Acquisizione Timestamp della tabella dell’incontro o della registrazione del paziente al momento della creazione del record. Tipo di evento explicit
	Piano di trattamento creato	Rappresenta la formalizzazione del piano di trattamento del paziente da parte del team clinico. Spesso viene acquisita quando nell’EHR viene creato e firmato uno specifico documento “Plan of Care” o un insieme iniziale di ordini terapeutici.
Perché è importante Questa tappa avvia la fase di trattamento attivo. Costituisce il riferimento per misurare l’aderenza ai protocolli assistenziali e il tempo che intercorre fino alla prima azione terapeutica, come la somministrazione di un farmaco. Dove reperirlo Deducibile dal timestamp della firma su un modulo “Plan of Care” o dal timestamp di creazione del primo insieme significativo di ordini terapeutici successivi alla diagnosi. Acquisizione Individuare il timestamp in cui il documento “Plan of Care” viene finalizzato o firmato dal medico responsabile. Tipo di evento inferred
	Valutazione iniziale completata	Rappresenta il completamento della prima valutazione clinica da parte di un infermiere o di un medico, ad esempio il triage o la valutazione iniziale. Spesso viene acquisito quando uno specifico modulo o documento clinico, come una “Nursing Initial Assessment”, viene firmato e finalizzato nell’EHR.
Perché è importante Questa attività rappresenta una tappa iniziale fondamentale. Il tempo che intercorre tra la registrazione e questa valutazione evidenzia eventuali ritardi nell’accettazione del paziente e nell’avvio dell’assistenza. Dove reperirlo Deducibile dal timestamp di finalizzazione o firma dei moduli di valutazione iniziale o dei documenti clinici nei moduli di documentazione clinica di Veradigm. Acquisizione Individuare il timestamp in cui lo stato della nota o del modulo di valutazione iniziale passa a “completato” o “firmato”. Tipo di evento inferred
	Esame diagnostico completato	Rappresenta il momento in cui i risultati di un esame diagnostico vengono finalizzati e resi disponibili nel record del paziente. Generalmente viene dedotto 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 di esecuzione degli esami diagnostici. I ritardi tra la richiesta e il completamento possono incidere significativamente sul tempo necessario per formulare la diagnosi. Dove reperirlo Deducibile dal campo relativo allo stato dell’ordine nel modulo degli ordini o dai timestamp del modulo dei risultati corrispondente, come LIS o RIS. Acquisizione Individuare il timestamp in cui lo stato dell’ordine passa a uno stato terminale come “Completato” o “Con risultato”. Tipo di evento inferred
	Esame diagnostico richiesto	Questo evento si verifica quando un medico inserisce la richiesta di un esame diagnostico, come un’analisi di laboratorio o un esame di imaging. Viene acquisito esplicitamente tramite il sistema Computerized Physician Order Entry (CPOE) all’interno di Veradigm.
Perché è importante Segna l’inizio del sottoprocesso diagnostico. Costituisce il punto di partenza per misurare i tempi di esecuzione degli esami diagnostici e individuare i ritardi nelle procedure di richiesta. Dove reperirlo Registrato nei log del modulo degli ordini o del sistema CPOE. Ogni ordine presenta un timestamp che indica quando è stato inserito. Acquisizione Estrarre il timestamp di creazione dai record degli ordini relativi agli esami diagnostici pertinenti. Tipo di evento explicit
	Farmaco somministrato	Questo evento viene registrato quando un infermiere o un medico documenta la somministrazione di un farmaco al paziente. L’informazione viene acquisita nel Medication Administration Record (MAR) o nel modulo 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 richiesta e la somministrazione aiuta a individuare i ritardi nel processo di distribuzione dei farmaci. Dove reperirlo Registrato esplicitamente nel modulo eMAR (electronic Medication Administration Record). Ogni evento di somministrazione presenta un timestamp specifico, il farmaco e il dosaggio. Acquisizione Estrarre i timestamp dalla tabella eMAR per ogni evento di somministrazione del farmaco collegato all’incontro con il paziente. Tipo di evento explicit
	Follow-up programmato	Questa attività rappresenta la programmazione di un appuntamento di follow-up per il paziente dopo la dimissione. L’evento viene acquisito nel modulo di programmazione quando viene prenotato un appuntamento collegato all’incontro concluso con la dimissione.
Perché è importante Garantire la programmazione dell’assistenza di follow-up è fondamentale per la continuità assistenziale e la riduzione delle riammissioni. Questa attività aiuta a misurare la conformità ai protocolli successivi alla dimissione. Dove reperirlo Registrato nel modulo di programmazione degli appuntamenti. Occorre individuare il timestamp di creazione di un nuovo appuntamento per il paziente successivo alla data di dimissione. Acquisizione Individuare il timestamp di creazione di un record di appuntamento nel sistema di programmazione collegato al paziente. Tipo di evento explicit
	Parametri vitali registrati	Questa attività si verifica ogni volta che vengono registrati i parametri vitali del paziente, come frequenza cardiaca, pressione arteriosa e temperatura. Si tratta di un evento esplicito acquisito nella documentazione clinica o nella sezione flowsheet dell’EHR dedicata ai parametri vitali.
Perché è importante La registrazione frequente dei parametri vitali indica un monitoraggio attivo del paziente. Frequenza e tempistica possono essere analizzate per verificare la conformità ai protocolli di monitoraggio. Dove reperirlo Registrato nel repository dei dati clinici o nelle tabelle flowsheet in cui vengono archiviati i parametri vitali. Ogni voce presenta un timestamp. Acquisizione Estrarre i timestamp dai dati flowsheet dei parametri vitali relativi all’incontro con il paziente. Tipo di evento explicit
	Procedura eseguita	Rappresenta il completamento di una procedura clinica o chirurgica. Generalmente viene acquisita quando un medico firma la nota della procedura o quando lo stato dell’ordine relativo alla procedura viene aggiornato a “completato” nel sistema.
Perché è importante Le procedure rappresentano tappe significative in molti Patient Journey. Analizzarne la tempistica aiuta a comprendere l’utilizzo delle risorse e l’efficienza della pianificazione. Dove reperirlo Deducibile dal timestamp della firma della nota della procedura nel modulo di documentazione clinica o dal timestamp di completamento nel modulo degli ordini relativo alla procedura. Acquisizione Utilizzare il timestamp di completamento dell’ordine relativo alla procedura o il timestamp della firma della documentazione associata. Tipo di evento inferred
	Trasferimento a un reparto	Questo evento segna il trasferimento fisico del paziente da un reparto o un’unità assistenziale a un’altra, ad esempio dal pronto soccorso a un reparto di degenza. Viene acquisito dal sistema ADT (Admission, Discharge, Transfer) di Veradigm.
Perché è importante I trasferimenti dei pazienti sono punti in cui si verificano frequentemente colli di bottiglia e ritardi. Analizzare durata e frequenza dei trasferimenti aiuta a ottimizzare il flusso dei pazienti e l’allocazione delle risorse tra i reparti. Dove reperirlo Registrato esplicitamente nel modulo ADT. Ogni evento di trasferimento include il paziente, le ubicazioni di provenienza e destinazione e un timestamp. Acquisizione Estrarre gli Event Log dal sistema ADT relativi agli spostamenti dei pazienti. Tipo di evento explicit

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da Veradigm (Allscripts)

Passaggi

Identifichi il canale di interfaccia di destinazione: acceda alla console di gestione dell'Allscripts Interface Engine (AIE). Individui il canale di interfaccia principale che elabora i messaggi in ingresso dall'EHR, generalmente denominato 'EHR_Inbound' o con un nome simile. Verifichi che questo canale gestisca i tipi di messaggio ADT, SIU, ORM, ORU, RAS e DFT, così da acquisire l'intero percorso delle attività del paziente.
Crei un nuovo canale Passthrough/Export: crei un nuovo canale di destinazione denominato 'ProcessMining_Export'. Imposti il tipo di output su 'File Writer'. Questo canale riceverà una copia dei messaggi dal canale di origine e li trasformerà in un formato flat file (CSV) per ProcessMind.
Configuri l'instradamento dei messaggi: nelle regole di routing dell'AIE, configuri una regola di copia/instradamento per inviare i messaggi dal canale EHR principale al nuovo canale 'ProcessMining_Export'. Filtri l'instradamento includendo solo i tipi di messaggio necessari: ADT (registrazione/trasferimento), SIU (programmazione), 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. Deve implementare uno script di analisi, descritto nella sezione 'query' seguente, che legga i segmenti HL7 e associ specifici Trigger Events e codici di stato ai nomi standard delle attività richiesti, ad esempio associando 'ADT^A01' a 'Paziente registrato'.
Mappi gli attributi ai campi HL7: verifichi che lo script estragga 'PatientEpisodeId' dal segmento PV1-19 (Visit Number) e 'PatientMrn' da PID-3. Mappi '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. Definisca la convenzione di denominazione dei file, ad esempio EventLog_YYYYMMDD_HH.csv. Imposti la modalità del file su 'Append' per aggiungere continuamente righe all'Event Log.
Gestisca delimitatori ed escaping: nello script, verifichi che i campi di testo, come Diagnosis o Department Name, vengano sanificati rimuovendo virgole o interruzioni di riga, così da evitare di compromettere la struttura CSV.
Attivi e testi: avvii il canale 'ProcessMining_Export'. Generi un evento di test nell'ambiente di test Veradigm, ad esempio registrando un paziente di prova. Verifichi che nel file CSV compaia una nuova riga con il nome dell'attività e il timestamp corretti.
Configuri la rotazione dei log: imposti una pianificazione della rotazione, ad esempio ogni giorno a mezzanotte, per chiudere il file CSV corrente e avviarne uno nuovo. In questo modo i file resteranno di dimensioni gestibili per il caricamento.
Riproduca i dati storici, se necessario: utilizzi lo strumento AIE 'Message Browser' o 'Log Replay' per reinviare i log HL7 archiviati degli ultimi 3-6 mesi attraverso il canale 'ProcessMining_Export'. Monitori 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 dataset finale in ProcessMind, associando 'PatientEpisodeId' al Case ID, 'ActivityName' all'Activity e 'EventDateTime' al Timestamp.

Configurazione

Tipo di canale: File Writer / output del file system
Trigger Events: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Codifica del file: UTF-8, fondamentale per i caratteri speciali presenti nei nomi e nelle diagnosi
Delimitatore: virgola (,) o barra verticale (|)
Formato della data: ISO 8601 (YYYY-MM-DDTHH:MM:SS), consigliato per la conversione dei timestamp HL7
Rotazione dei log: giornaliera o al superamento di 100 MB
Modalità di scrittura: Append, senza sovrascrivere
Prestazioni: verifichi che lo script di trasformazione sia leggero, così da evitare l'accodamento dei messaggi o arretrati nel motore.

a 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 Unity di Veradigm (Allscripts). Avrà bisogno di un Appname (Application Name) autorizzato per la Sua organizzazione e di un UserID e una Password validi, oppure di un token, per l'autenticazione. Verifichi che l'account utente disponga delle autorizzazioni per accedere ai domini clinici, tra cui Encounters, Orders, Results, Vitals e Problems.
Configurazione dell'ambiente: installi Python 3.8 o una versione successiva. Installi le librerie necessarie utilizzando pip: pip install requests pandas. Serviranno per effettuare richieste HTTP all'API Unity e manipolare i dati risultanti.
Configurazione: apra lo script Python fornito. Individui la sezione CONFIGURATION all'inizio e aggiorni API_URL affinché punti all'endpoint dell'ambiente Unity specifico, ad esempio unity.veradigm.com o un gateway interno. Sostituisca le credenziali segnaposto, come [YourAppName] e [YourUserID], con le credenziali effettive. Imposti START_DATE ed END_DATE in base all'intervallo di analisi desiderato.
Panoramica della logica dello script: lo script esegue innanzitutto l'autenticazione con l'API per ottenere un token di sicurezza. Chiama quindi GetEncounterInfo per recuperare tutti gli episodi dei pazienti nell'intervallo di date specificato. Questo elenco di encounter costituisce l'iteratore centrale dell'estrazione.
Ciclo di estrazione delle attività: per ogni EncounterID identificato, lo script esegue chiamate API secondarie a endpoint specializzati. Chiama GetOrders per individuare esami diagnostici e procedure, GetResults per identificare gli esami completati e GetVitals per recuperare le registrazioni dei parametri vitali. Chiama GetPatientProblems per le diagnosi confermate e analizza le note cliniche per individuare valutazioni e piani di trattamento.
Trasformazione dei dati: quando l'API restituisce dati JSON grezzi, lo script analizza campi specifici per associarli allo schema di ProcessMind. Ad esempio, OrderDateTime viene associato a EventDateTime per l'attività 'Esame diagnostico richiesto'. Lo script applica in modo coerente PatientEpisodeId (Encounter ID) a tutti i record secondari.
Gestione di ADT e trasferimenti: la logica dello script verifica la cronologia delle ubicazioni dell'encounter, se disponibile tramite specifiche chiamate secondarie Audit o ADT, oppure deduce i trasferimenti sulla base dei cambiamenti di reparto nella documentazione clinica, per generare gli eventi 'Trasferimento al reparto'.
Logica del follow-up: dopo aver elaborato l'encounter, lo script interroga GetSchedule per lo stesso PatientID, cercando date di appuntamento successive a DischargeDate, così da generare l'attività 'Follow-up programmato'.
Convalida: lo script include un passaggio di convalida locale che stampa nella console il numero di righe per tipo di attività. Esamini questo output per verificare che nessun tipo di attività abbia zero record, salvo quando previsto.
Esportazione: il dataset finale viene aggregato in un DataFrame Pandas. Lo script calcola attributi derivati come LengthOfStay e IsReadmission, ordinando i dati per paziente e orario. Infine, esporta l'Event Log pulito in un file CSV denominato veradigm_patient_journey_log.csv.
Revisione finale: apra il file CSV generato. Verifichi che i formati delle date siano ISO 8601 (YYYY-MM-DD HH:MM:SS) e che i campi di testo come ActivityName non contengano caratteri delimitatori.
Caricamento: importi il file CSV in ProcessMind. Associ PatientEpisodeId al Case ID, ActivityName all'Activity ed EventDateTime al Timestamp.

Configurazione

API_URL: URL di base dei servizi API Unity. Varia in base all'installazione del cliente, ad esempio on-premise o cloud. Verifichi che il protocollo, https, sia corretto.
Appname: identificativo univoco dell'applicazione registrata presso Veradigm/Allscripts. Controlla l'ambito di accesso ai dati.
Intervallo di date: si consiglia un periodo di estrazione compreso tra 3 e 6 mesi. Intervalli più ampi possono causare timeout; se il volume è elevato, valuti di suddividere l'estrazione per mese.
Impostazioni di timeout: lo script utilizza un timeout predefinito di 30 secondi per le chiamate API. Lo aumenti se il sistema EHR è sottoposto a un carico elevato.
Elaborazione in batch: lo script esegue l'iterazione per encounter. Nei sistemi ad alto volume potrebbe essere necessario modificarlo per recuperare i dati in blocco, se gli endpoint lo consentono, oppure eseguire thread paralleli.
Logica di mappatura: lo script associa OrderType alle attività. Verifichi che i codici specifici dei tipi di ordine del Suo sistema, ad esempio 'Lab' e 'Rad', siano coerenti con la logica della funzione process_orders.

a 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 per iniziare?

Intraprenda oggi il percorso verso l'ottimizzazione dell'esperienza dei pazienti e dell'efficienza operativa. I Suoi dati contengono le informazioni necessarie per individuare insight preziosi e promuovere miglioramenti significativi.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi oggi i percorsi dei pazienti in Veradigm

Ottenga tempi di ciclo dei pazienti più rapidi del 30% e risultati assistenziali superiori.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi subito.

Il Suo Template dei dati sul percorso del paziente

Il Suo Template dei dati sul percorso del paziente

Attributi del percorso del paziente

Attività del percorso del paziente

Guide all'estrazione

Esportazione dell'Event Log dal motore di interfaccia Allscripts

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite API Unity di Veradigm con Python

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Ottimizzi oggi i percorsi dei pazienti in Veradigm

Il Suo Template dei dati sul percorso del paziente

Il Suo Template dei dati sul percorso del paziente

Attributi del percorso del paziente

Attività del percorso del paziente

Guide all'estrazione

Esportazione dell'Event Log dal motore di interfaccia Allscripts

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite API Unity di Veradigm con Python

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Ottimizzi oggi i percorsi dei pazienti in Veradigm

La Sua privacy è importante