Il Suo Template dei dati del percorso del paziente
Il Suo Template dei dati del percorso del paziente
- Attributi consigliati per il contesto clinico
- Principali tappe del processo da monitorare
- Indicazioni specifiche per l'estrazione da Epic EHR
Attributi del percorso del paziente
| Nome | Descrizione | ||
|---|---|---|---|
| Episodio del paziente PatientEpisodeId | L'identificativo univoco dello specifico incontro con il paziente o episodio di cura. | ||
| Descrizione Il Patient Episode funge da identificativo principale del caso per il Process Mining. Raggruppa tutti gli eventi clinici, amministrativi e logistici relativi a un singolo periodo continuativo di cura, come una degenza ospedaliera o una visita al pronto soccorso. In Epic Clarity, corrisponde in genere al Contact Serial Number (CSN) o all'Encounter ID. L'analisi di questo attributo consente di ricostruire il percorso completo del paziente. Permette di associare le attività di triage, diagnosi, trattamento e dimissione in un'unica istanza di processo coerente. Perché è importante È la chiave fondamentale per collegare eventi distinti in un unico caso di processo. Dove reperirlo Tabella Epic Clarity: PAT_ENC, colonna: PAT_ENC_CSN_ID Esempi 200459112200459113200459114200459115 | |||
| Nome dell'attività ActivityName | L'azione clinica o amministrativa specifica eseguita. | ||
| Descrizione Questo attributo acquisisce il nome dell'evento che si verifica nel percorso del paziente, ad esempio 'Paziente registrato', 'Farmaco somministrato' o 'Ordine di dimissione firmato'. È l'elemento centrale per definire il flusso del processo. Nell'analisi, questo campo costituisce i nodi della process map. Deriva da diversi codici di transazione e stati degli ordini presenti nell'EHR, così da creare un Event Log leggibile. Perché è importante Definisce le fasi del processo e consente di visualizzare il Workflow. Dove reperirlo Derivato dalle tabelle CLARITY_ADT, ORDER_PROC e ORDER_MED. Esempi Triage completatoEsame diagnostico ordinatoPaziente dimessoFarmaco somministrato | |||
| Timestamp dell'evento EventTimestamp | La data e l'ora esatte in cui si è verificata l'attività. | ||
| Descrizione Questo attributo registra il momento preciso in cui un evento è stato acquisito nel sistema Epic. Viene utilizzato per ordinare le attività e calcolare tutte le metriche basate sulla durata, come la durata della degenza e i tempi di ciclo. La precisione di questo campo è fondamentale per identificare i colli di bottiglia. Supporta i Dashboard Triage Throughput e Time to Definitive Diagnosis, fornendo i riferimenti temporali per i punti di inizio e di fine. Perché è importante Consente di calcolare i tempi di ciclo, i tempi di attraversamento e l'ordine del processo. Dove reperirlo Diverse colonne timestamp, ad esempio EFFECTIVE_TIME e ORDER_TIME, a seconda della tabella di origine. Esempi 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z | |||
| Sistema di origine SourceSystem | Il sistema di riferimento dei dati, generalmente l'EHR Epic. | ||
| Descrizione Questo attributo identifica l'origine dei dati. Sebbene in questa vista sia principalmente 'Epic EHR', è utile quando i dati vengono combinati con altri sistemi, come un LIS (Laboratory Information System) separato o un sistema di fatturazione. Nell'analisi, garantisce la tracciabilità dei dati e facilita la risoluzione dei problemi quando determinati eventi risultano mancanti o non corretti rispetto alla fonte. Perché è importante Fornisce tracciabilità e contesto sull'origine dei dati. Dove reperirlo Codificato direttamente o derivato dalla configurazione della stringa di connessione. Esempi Epic EHREpic ClarityEpic Caboodle | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp in cui i dati sono stati estratti o aggiornati per l'ultima volta. | ||
| Descrizione Questo attributo indica quando il record è stato elaborato l'ultima volta dalla pipeline ETL. È distinto dal timestamp dell'evento e contribuisce a monitorare l'aggiornamento dei dati. Gli analisti lo utilizzano per determinare se il Dashboard riflette la situazione in tempo reale o se un problema di latenza dei dati influisce sull'accuratezza di KPI come Triage Wait Times. Perché è importante Aiuta a valutare l'aggiornamento e l'affidabilità dei dati di Process Mining. Dove reperirlo Timestamp del sistema ETL. Esempi 2023-10-27T23:59:59Z2023-10-28T06:00:00Z | |||
| Codice della diagnosi principale PrimaryDiagnosisCode | Il codice ICD-10 o il codice interno che rappresenta la diagnosi principale. | ||
| Descrizione Questo attributo registra la condizione medica confermata del paziente. Generalmente viene valorizzato durante l'attività 'Diagnosi confermata'. Viene utilizzato per raggruppare i casi in base alla condizione clinica nella Clinical Protocol Compliance View. La mappatura su 'Product' consente agli analisti di osservare come la 'produzione' dell'assistenza varia in funzione della condizione medica. Perché è importante Raggruppa i casi per similitudine clinica ai fini dell'analisi dei protocolli. Dove reperirlo Tabella Epic Clarity: PAT_ENC_DX, colonna: DX_ID Esempi J18.9I21.9E11.9 | |||
| Destinazione alla dimissione DischargeDisposition | La destinazione del paziente al momento della dimissione (casa, SNF, deceduto). | ||
| Descrizione Questo attributo registra la destinazione del paziente dopo l'uscita dall'ospedale. Viene acquisito durante l'attività 'Paziente dimesso'. È fondamentale per il Dashboard Readmission Risk, poiché i pazienti dimessi verso strutture di assistenza infermieristica qualificata (SNF) presentano profili di riammissione diversi da quelli dimessi a domicilio. Perché è importante Fornisce il contesto dell'esito del processo di cura. Dove reperirlo Tabella Epic Clarity: PAT_ENC, colonna: DISCH_DISP_C Esempi DomicilioStruttura infermieristica qualificataAssistenza sanitaria domiciliare | |||
| Flag di riammissione ReadmissionFlag | Indica se il paziente è tornato inaspettatamente entro 30 giorni. | ||
| Descrizione Questo attributo booleano identifica se allo specifico episodio è seguito un altro ricovero non programmato dello stesso paziente entro una finestra di 30 giorni. È alla base del KPI 30-Day Unplanned Readmission Rate. Nell'analisi, funge da variabile di esito principale. I percorsi di processo che portano a un flag 'True' vengono analizzati per individuare le cause alla radice nella fase di pianificazione della dimissione. Perché è importante Identifica i processi di dimissione non riusciti e i problemi relativi alla qualità dell'assistenza. Dove reperirlo Calcolato tramite SQL, esaminando gli incontri successivi dello stesso MRN. Esempi truefalse | |||
| ID del provider ProviderId | L'identificativo dell'utente o del professionista sanitario che ha eseguito l'attività. | ||
| Descrizione Questo attributo acquisisce l'ID univoco del membro del personale responsabile dell'evento, ad esempio l'infermiere che somministra un farmaco o il medico che firma gli ordini di dimissione. È mappato sull'attributo Generico 'User' per analizzare la variabilità delle risorse e il carico di lavoro. Per le attività automatizzate, può corrispondere all'ID di un utente di sistema. Perché è importante Consente di analizzare la variabilità delle prestazioni e del carico di lavoro tra i membri del personale. Dove reperirlo Tabella Epic Clarity: CLARITY_EMP, colonna: USER_ID Esempi EMP10023DOC5592SYSTEM | |||
| Livello di acuità del triage TriageAcuityLevel | Il punteggio di gravità assegnato al paziente durante il triage. | ||
| Descrizione Questo attributo indica l'urgenza della condizione del paziente, generalmente su una scala, ad esempio i livelli ESI da 1 a 5. Viene acquisito durante l'attività 'Triage completato'. Consente la segmentazione nel Dashboard Resource Intensity by Severity Score. I pazienti con elevata acuità seguono percorsi di processo diversi rispetto a quelli con bassa acuità, e questo campo aiuta a distinguere tali varianti. Perché è importante Segmenta il processo in base all'urgenza e al consumo previsto di risorse. Dove reperirlo Consultare la documentazione di Epic EHR per il campo Acuity nei log del pronto soccorso. Esempi 1 - Rianimazione2 - Emergenza3 - Urgenza | |||
| MRN del paziente PatientMrn | Il Medical Record Number che identifica il paziente. | ||
| Descrizione L'MRN è l'identificativo univoco del paziente all'interno del sistema sanitario ed è distinto dall'ID dell'episodio. Consente di seguire la storia del paziente attraverso più visite. Questo attributo viene utilizzato per rilevare le riammissioni e collegare episodi distinti nel Dashboard Readmission Risk. Nel modello Generico è mappato su 'Customer'. Perché è importante È essenziale per identificare le visite ripetute e analizzare la storia del paziente. Dove reperirlo Tabella Epic Clarity: PATIENT, colonna: PAT_ID o PAT_MRN_ID Esempi MRN-882910MRN-112003MRN-554211 | |||
| Nome del reparto DepartmentName | L'unità o il reparto ospedaliero in cui si è svolta l'attività. | ||
| Descrizione Questo attributo identifica la sede funzionale dell'evento, ad esempio 'Pronto soccorso', 'Radiologia' o 'Reparto di chirurgia generale'. È fondamentale per l'Internal Ward Transfer Analysis. I dati vengono utilizzati per segmentare la process map per reparto, consentendo ai responsabili di isolare i colli di bottiglia specifici della propria unità rispetto ai problemi sistemici dell'intero ospedale. Perché è importante Consente di applicare filtri organizzativi e analizzare i passaggi di consegne. Dove reperirlo Tabella Epic Clarity: CLARITY_DEP, colonna: DEPARTMENT_NAME Esempi Pronto soccorsoRadiologiaICUPediatria | |||
| Ora di fine dell'evento EventEndTime | Il timestamp in cui l'attività è stata completata. | ||
| Descrizione Sebbene molti eventi siano istantanei, alcune attività, come 'Test diagnostico eseguito' o 'Consulto completato', hanno una durata. Questo attributo registra l'ora di completamento. Consente di calcolare il tempo di elaborazione effettivo rispetto al tempo di attesa. È particolarmente rilevante per il Dashboard Diagnostic Service Cycle Times. Perché è importante Consente di calcolare la durata delle attività e l'utilizzo delle risorse. Dove reperirlo Consultare la documentazione di Epic EHR per le colonne specifiche dell'ora di fine in ORDER_PROC. Esempi 2023-10-15T09:45:00Z2023-10-16T15:00:00Z | |||
| Tipo di incontro EncounterType | La classificazione della visita del paziente, ad esempio ricovero o emergenza. | ||
| Descrizione Questo attributo classifica la natura dell'episodio del paziente. I valori più comuni includono 'Emergenza', 'Ricovero', 'Ambulatoriale' o 'Virtuale'. Mappato su 'CaseType', questo campo è fondamentale per filtrare l'analisi. Ad esempio, il Dashboard Discharge Planning è principalmente rilevante per gli incontri di ricovero, mentre il triage è specifico per le emergenze. Perché è importante Fornisce il contesto generale dell'istanza di processo. Dove reperirlo Tabella Epic Clarity: PAT_ENC, colonna: ENC_TYPE_C Esempi EmergenzaPaziente ambulatoriale ospedalieroPaziente ricoverato | |||
| Costo dell'ordine diagnostico DiagnosticOrderCost | Il costo interno associato a un esame o a una procedura diagnostica. | ||
| Descrizione Questo attributo assegna un valore economico alle attività 'Test diagnostico eseguito'. Consente di sovrapporre una dimensione finanziaria alla process map. Sebbene non sia una metrica clinica primaria, aiuta l'amministrazione a comprendere il peso economico delle diverse varianti di processo, in particolare di quelle che richiedono punteggi di gravità con elevato consumo di risorse. Perché è importante Aggiunge una dimensione finanziaria all'analisi dell'efficienza del processo. Dove reperirlo Tabelle di fatturazione o di contabilità dei costi collegate alla procedura. Esempi 150.001200.0045.00 | |||
| Durata dell'attesa per il trasferimento TransferWaitDuration | Il tempo trascorso tra l'ordine di trasferimento e il trasferimento effettivo. | ||
| Descrizione Questa metrica misura l'intervallo tra 'Trasferimento ordinato' e 'Paziente trasferito'. È il principale punto dati per l'Internal Ward Transfer Analysis. Valori elevati indicano il fenomeno del boarding, ovvero pazienti in attesa di un posto letto, che ostacola il flusso a monte dal pronto soccorso. Perché è importante Evidenzia i colli di bottiglia logistici e di capacità nel flusso dei pazienti. Dove reperirlo Differenza tra i timestamp dell'ordine e degli eventi di trasferimento. Esempi 2 ore e 30 minuti45 minuti12 ore | |||
| Metodo di programmazione SchedulingMethod | Indica come è stato prenotato l'appuntamento di follow-up. | ||
| Descrizione Questo attributo acquisisce il canale utilizzato per prenotare gli appuntamenti, ad esempio 'MyChart', 'Cadence Auto' o 'Front Desk'. È fondamentale per il Dashboard Outpatient Follow Up Automation Status. Se il valore indica un canale digitale gestito dal sistema o dal paziente, il flag 'IsAutomated' può essere impostato su true. In questo modo evidenzia il successo delle iniziative di trasformazione digitale. Perché è importante Monitora l'adozione di strumenti automatizzati o self-service. Dove reperirlo Consultare la documentazione di Epic EHR per l'origine della creazione dell'appuntamento. Esempi MyChartCadenceTelefonoIn presenza | |||
| Nome della regione RegionName | La regione geografica o il campus ospedaliero. | ||
| Descrizione Per i sistemi sanitari con più campus, questo attributo identifica la sede della struttura. Consente di confrontare le prestazioni tra diversi ospedali. La mappatura su 'Region' permette il benchmarking tra più sedi, per verificare se un ospedale gestisce il Triage Throughput meglio di un altro. Perché è importante Consente di effettuare benchmarking tra diverse strutture di una rete sanitaria. Dove reperirlo Derivato dai dati anagrafici del reparto o della struttura. Esempi Campus nordCentro cittàAla ovest | |||
| Programmazione automatizzata IsAutomatedScheduling | Flag che indica se la programmazione è stata eseguita senza l'intervento del personale. | ||
| Descrizione Questo attributo booleano deriva dal metodo di programmazione. Se l'appuntamento è stato fissato tramite MyChart o un Workflow Cadence automatizzato, il valore è True. Supporta direttamente il KPI Follow-up Scheduling Automation Rate. Aiuta i responsabili operativi a comprendere in quale misura la tecnologia sta riducendo il carico amministrativo. Perché è importante Misura il successo dell'automazione del processo. Dove reperirlo Derivato da SchedulingMethod. Esempi truefalse | |||
| Specializzazione del provider richiedente OrderingProviderSpecialty | La specializzazione medica del medico che richiede un consulto o un esame. | ||
| Descrizione Questo attributo acquisisce il reparto o la specializzazione, ad esempio 'Cardiologia' o 'Oncologia', del provider richiedente. Viene utilizzato nel Dashboard Specialist Consultation Latency. Aiuta ad analizzare se alcune specializzazioni devono affrontare tempi di attesa più lunghi per i servizi interni rispetto ad altre, evidenziando possibili disparità o carenze di risorse in specifiche linee di servizio. Perché è importante Segmenta la domanda di servizi diagnostici e di consulto. Dove reperirlo Consultare la documentazione di Epic EHR per i dati anagrafici dei provider. Esempi CardiologiaMedicina internaOrtopedia | |||
| Stato di aderenza al protocollo ProtocolAdherenceStatus | Stato che indica se il caso ha seguito il percorso clinico standard. | ||
| Descrizione Questo attributo confronta la sequenza delle attività del caso con un modello di riferimento definito (Standard Operating Procedure). Supporta la Clinical Protocol Compliance View. I valori possono includere 'Conforme', 'Passaggio saltato' o 'Fuori sequenza'. In questo modo i responsabili clinici possono filtrare rapidamente i casi non conformi senza esaminare manualmente ogni process map. Perché è importante Identifica rapidamente le deviazioni dagli standard di cura basati sulle evidenze. Dove reperirlo Calcolato nello strumento di Process Mining o pre-elaborato in SQL. Esempi ConformeDevianteIncompleto | |||
Attività del percorso del paziente
| Attività | Descrizione | ||
|---|---|---|---|
| Diagnosi confermata | L'inserimento di una diagnosi confermata nell'elenco dei problemi del paziente o nel campo della diagnosi dell'incontro. Rappresenta la conclusione della fase di accertamento. | ||
| Perché è importante Necessario per il KPI 'Time to Definitive Diagnosis'. Segna il passaggio dalla valutazione al trattamento mirato. Dove reperirlo Tabella PAT_ENC_DX o aggiornamento di PROBLEM_LIST collegato all'incontro. Acquisizione Registrato quando il medico aggiunge una voce all'attività Encounter Diagnosis Tipo di evento explicit | |||
| Paziente dimesso | La chiusura ufficiale dell'incontro di degenza. Viene acquisita quando il paziente viene dimesso virtualmente dal Census. | ||
| Perché è importante La conclusione formale dell'episodio per i calcoli della 'Length of Stay'. È essenziale per la 'Patient Flow Variant Discovery'. Dove reperirlo ADT Feed (evento A03) oppure PAT_ENC_HSP.DISCH_TIME. Acquisizione Registrato quando il personale amministrativo completa il Workflow di dimissione Tipo di evento explicit | |||
| Paziente registrato | La creazione iniziale nel sistema della registrazione dell'incontro con il paziente, che segna l'inizio dell'episodio assistenziale. Questo evento viene acquisito esplicitamente quando il paziente arriva allo sportello di registrazione o al pronto soccorso e viene registrato nell'Epic. | ||
| Perché è importante Stabilisce il punto di ancoraggio per l'intero Patient Journey e consente di calcolare la durata complessiva della degenza. È essenziale per il Dashboard 'Triage Throughput and Wait Times'. Dove reperirlo ADT Feed (evento A04 o A01) oppure tabella Clarity PAT_ENC (creazione di HSP_ACCOUNT_ID). Acquisizione Registrato quando viene eseguita la transazione 'Check In' o 'Admit' Tipo di evento explicit | |||
| Triage completato | Il completamento della valutazione infermieristica iniziale o della valutazione di triage. In genere viene acquisito quando il flowsheet del triage viene archiviato o lo stato del triage passa a 'Complete'. | ||
| Perché è importante È fondamentale per il Dashboard 'Triage Throughput and Wait Times', che misura l'efficienza della fase iniziale. I ritardi in questo punto si ripercuotono sull'intero percorso assistenziale. Dove reperirlo PAT_ENC_HSP.TRIAGE_END_TIME oppure timestamp dell'archiviazione di una specifica riga del Flowsheet (FLO_MEASUREMENT). Acquisizione Registrato quando la documentazione del triage viene firmata o il campo di stato viene aggiornato Tipo di evento explicit | |||
| Appuntamento di follow-up fissato | La prenotazione di una futura visita ambulatoriale per il paziente. Viene acquisita nel modulo di pianificazione Cadence, collegato alla cartella del paziente. | ||
| Perché è importante Supporta il 'Follow-up Scheduling Automation Rate'. Garantisce la continuità assistenziale e contribuisce a prevenire le riammissioni. Dove reperirlo PAT_ENC_APPT collegato all'ID del paziente, creato in prossimità dell'orario di dimissione. Acquisizione Registrato quando lo slot dell'appuntamento viene confermato in Cadence Tipo di evento explicit | |||
| Consulenza completata | Il completamento della valutazione specialistica, generalmente indicato dalla firma di una Consult Note o dalla chiusura dell'ordine di consulenza. | ||
| Perché è importante Punto finale di 'Specialist Consultation Lead Time'. Indica che il parere specialistico è stato fornito e che il piano assistenziale può procedere. Dove reperirlo HNO_NOTE_TEXT (nota archiviata con tipo Consult) oppure modifica dello stato di ORDER_PROC a Completed. Acquisizione Dedotto dall'orario di creazione della Consult Note o dall'aggiornamento dello stato dell'ordine Tipo di evento inferred | |||
| Consulenza richiesta | Un ordine inserito affinché uno specialista valuti il paziente. Viene acquisito come tipo specifico di ordine procedurale 'Consult' nell'Epic. | ||
| Perché è importante Punto di partenza per il KPI 'Specialist Consultation Lead Time'. Aiuta a individuare carenze in specifiche specialità mediche. Dove reperirlo ORDER_PROC in cui ORDER_CLASS = 'Consult' oppure ordini di invio specifici. Acquisizione Registrato quando l'ordine di consulenza viene firmato Tipo di evento explicit | |||
| Esame diagnostico eseguito | L'esecuzione effettiva dell'esame diagnostico o l'archiviazione del risultato. Per gli esami di laboratorio, corrisponde all'elaborazione del campione; per la diagnostica per immagini, al completamento della scansione. | ||
| Perché è importante Punto finale del KPI 'Mean Diagnostic Test Cycle Time'. È fondamentale per comprendere i ritardi nei servizi di supporto alle decisioni cliniche. Dove reperirlo ORDER_PROC.PROC_END_TIME oppure ORDER_STAT_HISTORY quando lo stato passa a 'Completed' o 'Resulted'. Acquisizione Registrato quando il tecnico completa l'attività o l'interfaccia dei risultati riceve i dati Tipo di evento explicit | |||
| Esame diagnostico ordinato | L'inserimento di un ordine per un esame di diagnostica per immagini (Radiology) o per servizi di laboratorio. Viene acquisito quando un medico inserisce e firma un ordine nel sistema CPOE. | ||
| Perché è importante Punto di partenza per il Dashboard 'Diagnostic Service Cycle Times'. Volumi elevati in questa fase senza risultati corrispondenti indicano la presenza di colli di bottiglia. Dove reperirlo Tabella ORDER_PROC in cui ORDER_TYPE è Lab o Imaging/Radiology. Acquisizione Registrato quando lo stato dell'ordine diventa 'Signed' o 'Active' Tipo di evento explicit | |||
| Farmaco somministrato | L'atto con cui un infermiere o un operatore sanitario somministra un farmaco al paziente. Viene acquisito nel Medication Administration Record (MAR). | ||
| Perché è importante Evento fondamentale per il Dashboard 'Medication Delivery Performance'. Monitora l'aderenza al 'Treatment Plan Developed'. Dove reperirlo Tabella MAR_ADMIN_INFO, in particolare gli eventi con azione 'Given' o 'New Bag'. Acquisizione Registrato quando l'infermiere scansiona il braccialetto del paziente e il farmaco (BCMA) Tipo di evento explicit | |||
| Ordine di dimissione firmato | L'autorizzazione formale del medico affinché il paziente lasci l'ospedale. Si tratta di uno specifico inserimento d'ordine nell'Epic. | ||
| Perché è importante Una tappa fondamentale in 'Discharge Planning and Execution'. L'intervallo tra questo evento e l'uscita effettiva rappresenta il ritardo amministrativo. Dove reperirlo ORDER_PROC in cui il tipo è 'Discharge Patient'. Acquisizione Registrato quando il medico firma l'ordine di dimissione Tipo di evento explicit | |||
| Paziente trasferito | Lo spostamento fisico del paziente verso un nuovo reparto o una nuova unità. Viene acquisito tramite gli eventi di trasferimento ADT. | ||
| Perché è importante Punto finale di 'Average Inter-Ward Transfer Time'. Supporta 'Internal Ward Transfer Analysis' per individuare i colli di bottiglia nella logistica ospedaliera. Dove reperirlo ADT Feed (evento A02) oppure PAT_ENC_HSP_TRANSACTION (Transfer In). Acquisizione Registrato quando l'addetto dell'unità aggiorna la posizione del paziente nel Census Tipo di evento explicit | |||
| Pianificazione della dimissione avviata | L'avvio delle attività di preparazione alla dimissione del paziente. Viene acquisito tramite la documentazione del Case Management o specifici tipi di ordine 'Discharge'. | ||
| Perché è importante È fondamentale per il Dashboard 'Discharge Planning and Execution'. Un avvio tempestivo è correlato a una riduzione della Length of Stay. Dove reperirlo Creazione di HSP_DISCH_PLAN o prima nota del Case Manager/Social Worker. Acquisizione Dedotto dalla prima interazione con il Discharge Navigator o dalla nota di Case Mgmt Tipo di evento inferred | |||
| Piano assistenziale avviato | L'assegnazione al paziente di un percorso clinico o protocollo specifico. Questo evento viene acquisito quando un Order Set o Care Plan standard viene applicato al contesto dell'incontro. | ||
| Perché è importante Supporta la 'Clinical Protocol Compliance View', segnando l'intenzione di seguire uno standard assistenziale. Le deviazioni dai passaggi pianificati successivi possono essere misurate a partire da questo momento. Dove reperirlo ORDER_SET_BKG o tabelle del care plan che indicano il collegamento di un protocollo all'incontro. Acquisizione Registrato quando il medico seleziona e firma un Order Set Tipo di evento explicit | |||
| Trasferimento ordinato | Una richiesta di trasferimento del paziente a un'altra unità o a un diverso livello assistenziale. Viene acquisita nel sistema come 'Bed Request' o 'Transfer Order'. | ||
| Perché è importante Punto di partenza per 'Average Inter-Ward Transfer Time'. Distingue tra la decisione clinica di trasferire il paziente e la disponibilità logistica di un posto letto. Dove reperirlo ADT_TRANSFER_ORDER o ORDER_PROC (Bed Request). Acquisizione Registrato quando il medico inserisce l'ordine di trasferimento Tipo di evento explicit | |||
Guide all'estrazione
Passaggi
- Acceda a Epic Hyperspace e avvii Reporting Workbench (RWB) tramite l’attività Analytics o My Reports.
- Crei un nuovo report selezionando la scheda Library e cercando il template "Encounter Search" o "Patient Encounters". Questo template consente di recuperare i dettagli a livello di contatto identificati dal CSN (Contact Serial Number).
- Configuri i criteri (scheda Settings):
- Imposti l’intervallo di date, ad esempio Discharge Date = Last 90 Days, per acquisire gli episodi completati.
- Filtri per Encounter Type, ad esempio 'Hospital Encounter' o 'Emergency', per escludere le visite ambulatoriali non pertinenti.
- Filtri per Reparto o Facility se è necessario definire un ambito specifico.
- Configuri le colonne visualizzate (scheda Display):
- Questo è il passaggio fondamentale dell’estrazione. Cerchi e aggiunga le colonne specifiche corrispondenti alle marche temporali delle attività richieste.
- Aggiunga gli identificativi del paziente:
CSN(episodio del paziente),MRN(ID paziente). - Aggiunga dati demografici/attributi:
Reparto,Discharge Disposition,Primary Diagnosis Code,Provider. - Aggiunga le colonne delle marche temporali: cerchi colonne come
Admission Time,Triage End Time,Discharge Time,Discharge Order Time,First Med Admin Timee così via. Per la mappatura esatta, consulti la sezione Query/Configuration.
- Esegua il report e verifichi i risultati nella finestra di anteprima.
- Esporti i dati:
- Faccia clic su Toolbar > Export.
- Selezioni il formato CSV o Text (Tab Delimited).
- Verifichi che sia selezionata l’opzione 'Include Column Headers'.
- Salvi il file come
Raw_Epic_Extract.csv.
- Trasformi i dati, passaggio fondamentale:
- L’esportazione RWB produce un dataset "Wide", con una riga per episodio del paziente e più colonne contenenti marche temporali.
- Esegua l’operazione di Unpivot, ristrutturando i dati in modo che ogni colonna temporale diventi una riga distinta nell’Event Log.
- Crei un file finale con le colonne
PatientEpisodeId,ActivityName,EventTimestampe gli attributi mappati.
- Formatti le date: verifichi che
EventTimestampsia nel formato ISO (YYYY-MM-DD HH:MM:SS) compatibile con ProcessMind. - Esegua la convalida finale: controlli che il file contenga le intestazioni
PatientEpisodeId,ActivityName,EventTimestampe lo carichi in ProcessMind.
Configurazione
- Template: utilizzi "Encounter Search" (LBF) o "Find Patients", a seconda della versione di Epic.
- Intervallo di date: inizi limitando l'intervallo a 3-6 mesi per evitare errori di timeout (RWB non è ottimizzato per estrazioni massive).
- Limite di righe: Epic RWB presenta spesso un limite di righe (ad esempio, 25.000 o 50.000 righe). Verifichi che l'intervallo di date non lo superi oppure esegua più batch.
- Autorizzazioni: sono necessari i punti di sicurezza 'Create' e 'Export' di Reporting Workbench.
- Prestazioni: esegua la ricerca nelle ore di minor carico se deve analizzare ampi intervalli storici.
- Granularità: questo metodo fornisce timestamp riepilogativi a livello di incontro (ad esempio, 'First Med Admin'). Non estrae ogni singolo ciclo (ad esempio, ogni compressa somministrata), a meno che non vengano utilizzati Template specifici di "Audit", rari in questo caso d'uso.
a Query di esempio sql
[REPORT CONFIGURATION SPECIFICATION]
# GENERAL SETTINGS
Application: Epic Reporting Workbench
Template_ID: Encounter_Search_LBF
Time_Horizon: Discharge Date between [Start Date] and [End Date]
Filters: Encounter Type IN ('Hospital Encounter', 'Emergency')
# COLUMN SELECTION MAPPING
# Map the following Epic RWB Columns (Display Names) to the Output Activities.
# Note: Column names may vary slightly by Epic customized build.
[MANDATORY ATTRIBUTES]
Column: Contact Serial Number (CSN) -> Target: PatientEpisodeId
Column: Patient MRN -> Target: PatientMrn
Column: Department at Discharge -> Target: DepartmentName
Column: Discharge Disposition -> Target: DischargeDisposition
Column: Primary Diagnosis ICD-10 -> Target: PrimaryDiagnosisCode
Column: Attending Provider -> Target: ProviderId
Column: Current Date -> Target: LastDataUpdate
Column: System Name (Fixed 'Epic') -> Target: SourceSystem
[ACTIVITY TIMESTAMP MAPPING]
# These columns represent the 'EventTimestamp' for the specific 'ActivityName'
1. Activity: Patient Registered
Epic_Column: Hospital Admission Time OR Check-In Time
2. Activity: Triage Completed
Epic_Column: Triage End Time OR Triage Acuity Time
3. Activity: Care Plan Initiated
Epic_Column: Care Plan Start Date
4. Activity: Diagnostic Test Ordered
Epic_Column: First Lab Order Time OR First Imaging Order Time
(Note: Select 'Earliest' if multiple columns exist)
5. Activity: Diagnostic Test Performed
Epic_Column: First Lab Result Time OR First Imaging End Time
6. Activity: Diagnosis Confirmed
Epic_Column: Principal Diagnosis Problem List Date
7. Activity: Consultation Requested
Epic_Column: Consult Order Create Time
8. Activity: Consultation Completed
Epic_Column: Consult Complete Time
9. Activity: Medication Administered
Epic_Column: First Medication Administration Time
10. Activity: Transfer Ordered
Epic_Column: Transfer Order Time
11. Activity: Patient Transferred
Epic_Column: Last Transfer In Time OR ADT Event Time
12. Activity: Discharge Planning Initiated
Epic_Column: Case Management Start Date
13. Activity: Discharge Order Signed
Epic_Column: Discharge Order Time
14. Activity: Patient Discharged
Epic_Column: Hospital Discharge Time
15. Activity: Follow-up Appointment Scheduled
Epic_Column: Discharge Follow-Up Appointment Made Date
# TRANSFORMATION LOGIC (PSEUDO-CODE)
# The export will be 'Wide'. Apply this logic to create the Event Log:
FOR EACH Row IN Exported_CSV:
EpisodeID = Row['Contact Serial Number']
FUNCTION CreateEvent(ActivityName, TimestampColumn):
IF Row[TimestampColumn] IS NOT NULL:
OUTPUT_ROW = {
'PatientEpisodeId': EpisodeID,
'ActivityName': ActivityName,
'EventTimestamp': Row[TimestampColumn],
'PatientMrn': Row['Patient MRN'],
'DepartmentName': Row['Department at Discharge'],
... [All Attributes]
}
APPEND OUTPUT_ROW TO Event_Log
# Execute for all 15 mappings defined above
CreateEvent('Patient Registered', 'Hospital Admission Time')
CreateEvent('Triage Completed', 'Triage End Time')
... [Repeat for all mapped columns]
END LOOP Passaggi
Richieda l'accesso al database: verifichi di disporre dell'accesso in lettura a Epic Clarity Console o a un client SQL connesso al database Clarity di produzione o di reporting. Le saranno necessarie autorizzazioni per
PAT_ENC,ORDER_PROC,CLARITY_ADT,MAR_ADMIN_INFOe le relative tabelle di riferimento.Identifichi l'ambito e gli ID dei filtri: prima di eseguire lo script completo, esegua piccole query esplorative per individuare i valori specifici di
ORDER_TYPE_Crelativi a laboratori, radiologia, consulenze e trasferimenti nella Sua istanza Epic, poiché questi Custom Lists (Category Lists) variano da ospedale a ospedale.Configuri l'intervallo temporale: individui le clausole
WHEREnello script SQL fornito che filtranoCONTACT_DATEoHOSP_ADMSN_TIME. Le modifichi in base all'intervallo desiderato, ad esempio gli ultimi 6 mesi.Mappi i Flowsheet personalizzati (facoltativo): se Le servono timestamp precisi per il triage o la pianificazione delle dimissioni non presenti nella tabella principale degli incontri, individui il
FLO_MEAS_ID(Flowsheet Measure ID) specifico per questi campi e aggiorni le sezioni segnaposto dello script.Esegua la query: esegua lo script SQL completo nel Suo client SQL, ad esempio SQL Server Management Studio o Oracle SQL Developer. Lo script utilizza
UNION ALLper combinare diversi eventi clinici in una struttura standardizzata di Event Log.Post-elaborazione: la query restituisce un elenco piatto. Verifichi che
EventTimestampnon sia nullo. Converta gli eventuali formati datetime specifici del database in ISO 8601 (YYYY-MM-DDTHH:MM:SS) se richiesto dal middleware.Esporti i dati: salvi il risultato come file CSV. Verifichi che le intestazioni corrispondano agli attributi specifici definiti (
PatientEpisodeId,ActivityNamee così via).Carichi i dati in ProcessMind: importi il CSV in ProcessMind. Mappi
PatientEpisodeIdcome Case ID,ActivityNamecome Activity eEventTimestampcome Timestamp.
Configurazione
- Connessione al database: Epic Clarity, generalmente con backend MSSQL o Oracle.
- Filtro per data: filtri
PAT_ENC.HOSP_ADMSN_TIMEoPAT_ENC.CONTACT_DATE. Per l'analisi iniziale si consiglia un intervallo di 3-6 mesi, così da gestire le prestazioni delle query. - Tipi di incontro: lo script filtra gli incontri Inpatient ed Emergency (i valori
ENC_TYPE_Ccomunemente utilizzati sono 3 e 50, ma li verifichi rispetto aZC_ENC_TYPE). - Tipi di ordine: è necessario personalizzare i valori di
ORDER_TYPE_Cper laboratori, imaging e consulenze in base alla configurazione locale diZC_ORDER_TYPE. - Prestazioni: lo script analizza tabelle ad alto volume (
ORDER_PROC,CLARITY_ADT). Verifichi che siano presenti indici adeguati oppure esegua lo script nelle ore di minor carico.
a Query di esempio sql
WITH Cohort AS (
SELECT
pe.PAT_ENC_CSN_ID,
pe.PAT_ID,
pe.HOSP_ADMSN_TIME,
pe.HOSP_DISCH_TIME,
pe.DEPARTMENT_ID,
dep.DEPARTMENT_NAME,
emp.NAME AS ProviderName,
pat.PAT_MRN_ID,
pe.ACUITY_LEVEL_C,
disch.NAME AS DischargeDisposition,
pe.ENC_TYPE_C
FROM PAT_ENC pe
LEFT JOIN CLARITY_DEP dep ON pe.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON pe.VISIT_PROV_ID = emp.PROV_ID
LEFT JOIN PATIENT pat ON pe.PAT_ID = pat.PAT_ID
LEFT JOIN ZC_DISCH_DISP disch ON pe.DISCH_DISP_C = disch.DISCH_DISP_C
WHERE pe.HOSP_ADMSN_TIME >= DATEADD(month, -6, GETDATE())
AND pe.ENC_TYPE_C IN (3, 50) -- 3=Inpatient, 50=Emergency (Verify local codes)
)
-- 1. Patient Registered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)) AS PatientEpisodeId,
'Patient Registered' AS ActivityName,
c.HOSP_ADMSN_TIME AS EventTimestamp,
c.DepartmentName,
c.ProviderName AS ProviderId,
c.PAT_MRN_ID AS PatientMrn,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)) AS TriageAcuityLevel,
CAST(c.ENC_TYPE_C AS VARCHAR(50)) AS EncounterType,
NULL AS PrimaryDiagnosisCode,
NULL AS ReadmissionFlag,
c.DischargeDisposition,
'Epic EHR' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM Cohort c
WHERE c.HOSP_ADMSN_TIME IS NOT NULL
UNION ALL
-- 2. Triage Completed (Using Flowsheet or Triage Time)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Triage Completed',
ISNULL(pe.TRIAGE_END_INSTANT, c.HOSP_ADMSN_TIME), -- Fallback if specific column unused
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC pe ON c.PAT_ENC_CSN_ID = pe.PAT_ENC_CSN_ID
WHERE pe.TRIAGE_END_INSTANT IS NOT NULL
UNION ALL
-- 3. Care Plan Initiated (Based on Order Type)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Care Plan Initiated',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 100 -- Placeholder: Replace with ID for Care Plan/Protocol
UNION ALL
-- 4. Diagnostic Test Ordered (Lab/Radiology)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnostic Test Ordered',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C IN (1, 2) -- Placeholder: 1=Lab, 2=Radiology (Verify local codes)
UNION ALL
-- 5. Diagnostic Test Performed (Result Time or Procedure Start)
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnostic Test Performed',
COALESCE(ord2.PROC_START_TIME, ord2.PROC_ENDING_TIME, ord.ORDER_INST),
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
JOIN ORDER_PROC_2 ord2 ON ord.ORDER_PROC_ID = ord2.ORDER_PROC_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C IN (1, 2)
AND ord2.PROC_START_TIME IS NOT NULL
UNION ALL
-- 6. Diagnosis Confirmed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Diagnosis Confirmed',
dx.NOTED_DATE,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
edg.DX_NAME,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC_DX dx ON c.PAT_ENC_CSN_ID = dx.PAT_ENC_CSN_ID
JOIN CLARITY_EDG edg ON dx.DX_ID = edg.DX_ID
WHERE dx.NOTED_DATE IS NOT NULL
UNION ALL
-- 7. Consultation Requested
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Consultation Requested',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 35 -- Placeholder: Replace with ID for Consult
UNION ALL
-- 8. Consultation Completed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Consultation Completed',
ord.ORDER_END_TIME,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 35 -- Placeholder: Replace with ID for Consult
AND ord.ORDER_STATUS_C = 5 -- Placeholder: 5=Completed
AND ord.ORDER_END_TIME IS NOT NULL
UNION ALL
-- 9. Medication Administered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Medication Administered',
mar.TAKEN_TIME,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_MED med ON c.PAT_ENC_CSN_ID = med.PAT_ENC_CSN_ID
JOIN MAR_ADMIN_INFO mar ON med.ORDER_MED_ID = mar.ORDER_MED_ID
LEFT JOIN CLARITY_EMP emp ON mar.TAKEN_USER_ID = emp.USER_ID
WHERE mar.TAKEN_TIME IS NOT NULL
AND mar.MAR_ACTION_C = 1 -- Placeholder: 1=Given
UNION ALL
-- 10. Transfer Ordered
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Transfer Ordered',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 60 -- Placeholder: Replace with ID for Transfer/Bed Request
UNION ALL
-- 11. Patient Transferred
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Patient Transferred',
adt.EFFECTIVE_TIME,
dep.DEPARTMENT_NAME,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN CLARITY_ADT adt ON c.PAT_ENC_CSN_ID = adt.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_DEP dep ON adt.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE adt.EVENT_TYPE_C = 3 -- 3=Transfer In
UNION ALL
-- 12. Discharge Planning Initiated
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Discharge Planning Initiated',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.ORDER_TYPE_C = 70 -- Placeholder: Case Management/Discharge Order Type
UNION ALL
-- 13. Discharge Order Signed
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Discharge Order Signed',
ord.ORDER_INST,
c.DepartmentName,
emp.NAME,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN ORDER_PROC ord ON c.PAT_ENC_CSN_ID = ord.PAT_ENC_CSN_ID
LEFT JOIN CLARITY_EMP emp ON ord.ORDERING_PROV_ID = emp.PROV_ID
WHERE ord.PROC_CODE = 'DISCHARGE' -- Placeholder: Filter by specific discharge procedure code
UNION ALL
-- 14. Patient Discharged
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Patient Discharged',
c.HOSP_DISCH_TIME,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
WHERE c.HOSP_DISCH_TIME IS NOT NULL
UNION ALL
-- 15. Follow-up Appointment Scheduled
SELECT
CAST(c.PAT_ENC_CSN_ID AS VARCHAR(50)),
'Follow-up Appointment Scheduled',
next_pe.APPT_MADE_DATE,
c.DepartmentName,
c.ProviderName,
c.PAT_MRN_ID,
CAST(c.ACUITY_LEVEL_C AS VARCHAR(50)),
CAST(c.ENC_TYPE_C AS VARCHAR(50)),
NULL,
NULL,
c.DischargeDisposition,
'Epic EHR',
GETDATE()
FROM Cohort c
JOIN PAT_ENC next_pe ON c.PAT_ID = next_pe.PAT_ID
WHERE next_pe.APPT_MADE_DATE BETWEEN c.HOSP_ADMSN_TIME AND ISNULL(c.HOSP_DISCH_TIME, GETDATE())
AND next_pe.CONTACT_DATE > c.HOSP_ADMSN_TIME -- The appointment is for a future date relative to admission È pronto per iniziare?
Inizi oggi a trasformare le Sue attività cliniche applicando questo Template ai dati Epic. Il nostro team è a Sua disposizione per aiutarLa a gestire il processo di estrazione e ottenere risultati concreti fin da subito.
Ottimizzi oggi il percorso del paziente e riduca il tempo di ciclo
Individui i colli di bottiglia clinici per ridurre il tempo di ciclo del 30%.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.