Ihr Daten-Template für die Patientenreise
Ihr Daten-Template für die Patientenreise
- Empfohlene Attribute für den klinischen Kontext
- Zentrale Prozessmeilensteine zur Nachverfolgung
- Spezifische Hinweise zur Datenextraktion aus Epic EHR
Attribute der Patientenreise
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Die konkrete klinische oder administrative Handlung, die ausgeführt wurde. | ||
| Beschreibung Dieses Attribut erfasst den Namen des Ereignisses innerhalb der Patientenreise, etwa „Patient registriert“, „Medikament verabreicht“ oder „Entlassungsanordnung unterzeichnet“. Es ist das zentrale Element für die Definition des Prozessablaufs. In der Analyse bildet dieses Feld die Knoten der Prozessdarstellung. Es wird aus verschiedenen Transaktionscodes und Auftragsstatus im EHR abgeleitet, um ein verständliches Event Log zu erstellen. Warum das wichtig ist Es definiert die Prozessschritte und ermöglicht die Visualisierung des Workflows. Bezugsquelle Abgeleitet aus den Tabellen CLARITY_ADT, ORDER_PROC und ORDER_MED. Beispiele Triage abgeschlossenDiagnostischer Test angeordnetPatient entlassenMedikament verabreicht | |||
| Ereignis-Timestamp EventTimestamp | Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt, zu dem ein Ereignis im Epic-System protokolliert wurde. Es dient dazu, Aktivitäten zeitlich zu ordnen und alle zeitbezogenen Kennzahlen zu berechnen, etwa Aufenthaltsdauer und Durchlaufzeiten. Die Genauigkeit dieses Feldes ist entscheidend, um Engpässe zu erkennen. Es unterstützt die Dashboards „Triage Throughput“ und „Time to Definitive Diagnosis“, indem es die zeitlichen Bezugspunkte für Start- und Endpunkte liefert. Warum das wichtig ist Es ermöglicht die Berechnung von Zykluszeiten, Durchlaufzeiten und der Prozessreihenfolge. Bezugsquelle Je nach Quelltabelle verschiedene Timestamp-Spalten, etwa EFFECTIVE_TIME oder ORDER_TIME. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z | |||
| Patientenepisode PatientEpisodeId | Die eindeutige Kennung für den spezifischen Patientenkontakt oder die Behandlungsepisode. | ||
| Beschreibung Die Patientenepisode dient als primäre Case-Kennung für Process Mining. Sie fasst alle klinischen, administrativen und logistischen Ereignisse zusammen, die zu einem zusammenhängenden Behandlungszeitraum gehören, etwa zu einem stationären Aufenthalt oder einem Besuch in der Notaufnahme. In Epic Clarity entspricht sie in der Regel der Contact Serial Number (CSN) oder der Encounter ID. Durch die Analyse dieses Attributs lässt sich die gesamte Patientenreise rekonstruieren. Triage, Diagnose, Behandlung und Entlassung können zu einer zusammenhängenden Prozessinstanz verknüpft werden. Warum das wichtig ist Sie ist der zentrale Schlüssel, um unterschiedliche Ereignisse zu einem einzelnen Prozess-Case zu verknüpfen. Bezugsquelle Epic-Clarity-Tabelle: PAT_ENC, Spalte: PAT_ENC_CSN_ID Beispiele 200459112200459113200459114200459115 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, zu dem die Daten extrahiert oder zuletzt aktualisiert wurden. | ||
| Beschreibung Dieses Attribut zeigt an, wann der Datensatz zuletzt durch die ETL-Pipeline verarbeitet wurde. Es unterscheidet sich vom Ereignis-Timestamp und unterstützt die Überwachung der Aktualität der Daten. Analysten verwenden diesen Wert, um festzustellen, ob das Dashboard die aktuelle Situation abbildet oder ob eine Datenverzögerung die Genauigkeit von KPIs wie den Triage-Wartezeiten beeinträchtigt. Warum das wichtig ist Es hilft dabei, die Aktualität und Zuverlässigkeit der Process-Mining-Daten zu bewerten. Bezugsquelle Timestamp des ETL-Systems. Beispiele 2023-10-27T23:59:59Z2023-10-28T06:00:00Z | |||
| Quellsystem SourceSystem | Das führende System für die Daten, in der Regel das Epic EHR. | ||
| Beschreibung Dieses Attribut identifiziert die Herkunft der Daten. Für diese Ansicht lautet der Wert hauptsächlich „Epic EHR“. Es ist jedoch auch hilfreich, wenn Daten mit anderen Systemen wie einem separaten LIS (Laborinformationssystem) oder einem Abrechnungssystem kombiniert werden. In der Analyse stellt es die Datenherkunft sicher und erleichtert die Fehlerbehebung, wenn bestimmte Ereignisse im Vergleich zur Quelle fehlen oder fehlerhaft erscheinen. Warum das wichtig ist Es sorgt für Rückverfolgbarkeit und liefert Kontext zur Herkunft der Daten. Bezugsquelle Fest codiert oder aus der Konfiguration der Verbindungszeichenfolge abgeleitet. Beispiele Epic EHREpic ClarityEpic Caboodle | |||
| Abteilungsname DepartmentName | Die Station oder Abteilung des Krankenhauses, in der die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut identifiziert den funktionalen Ort des Ereignisses, etwa „Notaufnahme“, „Radiologie“ oder „chirurgische Allgemeinstation“. Es ist für die Analyse interner Stationsverlegungen entscheidend. Die Daten werden verwendet, um die Prozessdarstellung nach Abteilungen zu segmentieren. So können Verantwortliche Engpässe in ihrer eigenen Einheit von systemweiten Problemen des Krankenhauses unterscheiden. Warum das wichtig ist Es ermöglicht die Filterung nach Organisationseinheiten und die Analyse von Übergaben. Bezugsquelle Epic-Clarity-Tabelle: CLARITY_DEP, Spalte: DEPARTMENT_NAME Beispiele NotaufnahmeRadiologieICUPädiatrie | |||
| Code der Hauptdiagnose PrimaryDiagnosisCode | Der ICD-10-Code oder interne Code für die Hauptdiagnose. | ||
| Beschreibung Dieses Attribut erfasst den bestätigten medizinischen Zustand des Patienten. Es wird in der Regel während der Aktivität „Diagnose bestätigt“ befüllt. Es wird verwendet, um Cases für die Ansicht zur Einhaltung klinischer Protokolle nach Krankheitsbild zu gruppieren. Durch die Zuordnung zu „Product“ können Analysten erkennen, wie sich die „Produktion“ der Versorgung je nach Krankheitsbild unterscheidet. Warum das wichtig ist Es gruppiert Cases nach klinischer Ähnlichkeit für die Protokollanalyse. Bezugsquelle Epic-Clarity-Tabelle: PAT_ENC_DX, Spalte: DX_ID Beispiele J18.9I21.9E11.9 | |||
| Endzeit des Ereignisses EventEndTime | Der Timestamp, zu dem die Aktivität abgeschlossen wurde. | ||
| Beschreibung Viele Ereignisse finden zu einem bestimmten Zeitpunkt statt. Einige Aktivitäten wie „Diagnosetest durchgeführt“ oder „Konsultation abgeschlossen“ haben jedoch eine Dauer. Dieses Attribut erfasst den Abschlusszeitpunkt. Damit lassen sich aktive Bearbeitungszeit und Wartezeit unterscheiden. Das ist besonders für das Dashboard „Diagnostic Service Cycle Times“ relevant. Warum das wichtig ist Es ermöglicht die Berechnung der Aktivitätsdauer und der Ressourcenauslastung. Bezugsquelle Weitere Informationen zu den spezifischen Endzeitspalten in ORDER_PROC finden Sie in der Dokumentation zum Epic EHR. Beispiele 2023-10-15T09:45:00Z2023-10-16T15:00:00Z | |||
| Entlassungsziel DischargeDisposition | Das Ziel des Patienten nach der Entlassung, etwa Zuhause, SNF oder verstorben. | ||
| Beschreibung Dieses Attribut erfasst, wohin der Patient nach dem Verlassen des Krankenhauses gegangen ist. Es wird bei der Aktivität „Patient entlassen“ erfasst. Für das Dashboard „Readmission Risk“ ist es besonders wichtig, da Patienten, die in eine Skilled Nursing Facility (SNF) entlassen werden, andere Wiederaufnahmemuster aufweisen als Patienten, die nach Hause gehen. Warum das wichtig ist Es liefert Kontext zum Ergebnis des Versorgungsprozesses. Bezugsquelle Epic-Clarity-Tabelle: PAT_ENC, Spalte: DISCH_DISP_C Beispiele Nach HausePflegeeinrichtungHäusliche Pflege | |||
| Flag für Wiederaufnahme ReadmissionFlag | Gibt an, ob der Patient innerhalb von 30 Tagen unerwartet zurückgekehrt ist. | ||
| Beschreibung Dieses boolesche Attribut zeigt an, ob auf die betreffende Episode innerhalb eines Zeitraums von 30 Tagen eine ungeplante Aufnahme desselben Patienten folgte. Es bildet die Grundlage für den KPI zur Rate ungeplanter Wiederaufnahmen innerhalb von 30 Tagen. In der Analyse dient es als wichtige Ergebnisvariable. Prozesspfade, die zu einem Flag mit dem Wert „True“ führen, werden untersucht, um Ursachen in der Entlassungsplanung zu ermitteln. Warum das wichtig ist Es identifiziert fehlerhafte Entlassungsprozesse und Probleme bei der Versorgungsqualität. Bezugsquelle Berechnet per SQL durch die Suche nach späteren Kontakten desselben Patienten anhand der MRN. Beispiele truefalse | |||
| Kontaktart EncounterType | Die Klassifizierung des Patientenbesuchs, etwa stationär oder als Notfall. | ||
| Beschreibung Dieses Attribut kategorisiert die Art der Patientenepisode. Häufige Werte sind „Emergency“, „Inpatient“, „Outpatient“ oder „Virtual“. Durch die Zuordnung zu „CaseType“ ist dieses Feld für die Filterung der Analyse grundlegend. Das Dashboard zur Entlassungsplanung ist beispielsweise hauptsächlich für stationäre Kontakte relevant, während die Triage spezifisch für Notfälle ist. Warum das wichtig ist Es liefert den übergeordneten Kontext für die Prozessinstanz. Bezugsquelle Epic-Clarity-Tabelle: PAT_ENC, Spalte: ENC_TYPE_C Beispiele NotfallAmbulante KrankenhausbehandlungStationär | |||
| Patienten-MRN PatientMrn | Die Medical Record Number zur Identifizierung des Patienten. | ||
| Beschreibung Die MRN ist die eindeutige Kennung des Patienten im gesamten Gesundheitssystem und unterscheidet sich von der Episoden-ID. Sie ermöglicht die Nachverfolgung der Krankengeschichte über mehrere Besuche hinweg. Dieses Attribut wird verwendet, um Wiederaufnahmen zu erkennen und separate Episoden für das Dashboard „Readmission Risk“ zu verknüpfen. Im generischen Modell wird es „Customer“ zugeordnet. Warum das wichtig ist Sie ist entscheidend, um wiederholte Besuche zu erkennen und die Krankengeschichte des Patienten zu analysieren. Bezugsquelle Epic-Clarity-Tabelle: PATIENT, Spalte: PAT_ID oder PAT_MRN_ID Beispiele MRN-882910MRN-112003MRN-554211 | |||
| Provider-ID ProviderId | Die Kennung des Benutzers oder Klinikers, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die eindeutige ID des für das Ereignis verantwortlichen Mitarbeiters, etwa der Pflegekraft, die ein Medikament verabreicht, oder des Arztes, der Entlassungsanordnungen unterzeichnet. Es wird dem generischen Attribut „User“ zugeordnet, um Unterschiede bei Ressourcen und Arbeitslast zu analysieren. Bei automatisierten Aktivitäten kann es sich um die ID eines Systembenutzers handeln. Warum das wichtig ist Es ermöglicht die Analyse von Leistungs- und Arbeitslastunterschieden zwischen Mitarbeitenden. Bezugsquelle Epic-Clarity-Tabelle: CLARITY_EMP, Spalte: USER_ID Beispiele EMP10023DOC5592SYSTEM | |||
| Triage-Schweregrad TriageAcuityLevel | Der Schweregrad, der dem Patienten während der Triage zugewiesen wurde. | ||
| Beschreibung Dieses Attribut zeigt die Dringlichkeit des Zustands des Patienten an, typischerweise auf einer Skala wie den ESI-Stufen 1 bis 5. Es wird während der Aktivität „Triage abgeschlossen“ erfasst. Es ermöglicht die Segmentierung im Dashboard „Resource Intensity by Severity Score“. Patienten mit hoher Dringlichkeit durchlaufen andere Prozesspfade als Patienten mit niedriger Dringlichkeit. Dieses Feld hilft, diese Varianten zu unterscheiden. Warum das wichtig ist Es segmentiert den Prozess nach Dringlichkeit und erwartetem Ressourcenverbrauch. Bezugsquelle Weitere Informationen zum Feld Acuity in den ED-Logs finden Sie in der Dokumentation zum Epic EHR. Beispiele 1 - Reanimation2 - Dringender Notfall3 - Dringend | |||
| Automatisierte Terminplanung IsAutomatedScheduling | Flag, das angibt, ob die Terminplanung ohne Eingreifen von Mitarbeitenden erfolgt ist. | ||
| Beschreibung Dieses boolesche Attribut wird aus der Planungsmethode abgeleitet. Wurde der Termin über MyChart oder einen automatisierten Cadence-Workflow erstellt, lautet der Wert True. Es unterstützt direkt den KPI zur Automatisierungsquote bei der Folgeterminplanung. Damit können Verantwortliche nachvollziehen, welcher Anteil des administrativen Aufwands an die Technologie übertragen wird. Warum das wichtig ist Es misst den Erfolg der Prozessautomatisierung. Bezugsquelle Abgeleitet aus SchedulingMethod. Beispiele truefalse | |||
| Fachgebiet des anordnenden Providers OrderingProviderSpecialty | Das medizinische Fachgebiet des Arztes, der eine Konsultation oder Untersuchung anfordert. | ||
| Beschreibung Dieses Attribut erfasst die Abteilung oder das Fachgebiet, etwa „Kardiologie“ oder „Onkologie“, des anordnenden Providers. Es wird im Dashboard zur Verzögerung bei Fachkonsultationen verwendet. Damit lässt sich analysieren, ob bestimmte Fachgebiete bei internen Leistungen längere Wartezeiten haben als andere. So werden mögliche Verzerrungen oder Ressourcenengpässe in bestimmten Leistungsbereichen sichtbar. Warum das wichtig ist Es segmentiert die Nachfrage nach diagnostischen Leistungen und Konsultationen. Bezugsquelle Weitere Informationen zu den Stammdaten der Provider finden Sie in der Dokumentation zum Epic EHR. Beispiele KardiologieInnere MedizinOrthopädie | |||
| Kosten der diagnostischen Anordnung DiagnosticOrderCost | Die internen Kosten für einen diagnostischen Test oder Eingriff. | ||
| Beschreibung Dieses Attribut weist Aktivitäten vom Typ „Diagnosetest durchgeführt“ einen finanziellen Wert zu. Dadurch lässt sich die Prozessdarstellung um eine finanzielle Perspektive ergänzen. Es ist zwar keine primäre klinische Kennzahl, hilft der Verwaltung jedoch dabei, die finanzielle Bedeutung verschiedener Prozessvarianten zu verstehen, insbesondere bei Varianten mit hohem Ressourcenbedarf. Warum das wichtig ist Es ergänzt die Analyse der Prozesseffizienz um eine finanzielle Dimension. Bezugsquelle Abrechnungs- oder Kostenrechnungstabellen, die mit dem Eingriff verknüpft sind. Beispiele 150.001200.0045.00 | |||
| Planungsmethode SchedulingMethod | Gibt an, wie der Folgetermin gebucht wurde. | ||
| Beschreibung Dieses Attribut erfasst den Kanal, über den Termine gebucht werden, etwa „MyChart“, „Cadence Auto“ oder „Front Desk“. Es ist entscheidend für das Dashboard zum Automatisierungsstatus der ambulanten Nachsorge. Wenn der Wert auf einen systemgestützten oder patientengesteuerten digitalen Kanal hinweist, kann das Flag „IsAutomated“ auf true gesetzt werden. So wird sichtbar, wie erfolgreich Initiativen zur digitalen Transformation sind. Warum das wichtig ist Es erfasst die Nutzung automatisierter oder selbst bedienbarer Werkzeuge. Bezugsquelle Weitere Informationen zur Quelle der Terminerstellung finden Sie in der Dokumentation zum Epic EHR. Beispiele MyChartCadenceTelefonPersönlich | |||
| Regionsname RegionName | Die geografische Region oder der Krankenhausstandort. | ||
| Beschreibung Bei Gesundheitssystemen mit mehreren Standorten identifiziert dieses Attribut den Standort der Einrichtung. Dadurch lässt sich die Leistung verschiedener Krankenhäuser vergleichen. Die Zuordnung zu „Region“ ermöglicht standortübergreifende Benchmarks, um zu prüfen, ob ein Krankenhaus die Triage-Durchsatzleistung besser steuert als ein anderes. Warum das wichtig ist Es ermöglicht Benchmarks zwischen verschiedenen Einrichtungen eines Gesundheitsnetzwerks. Bezugsquelle Abgeleitet aus den Stammdaten der Abteilung oder Einrichtung. Beispiele NordcampusStadtzentrumWestflügel | |||
| Status der Protokolleinhaltung ProtocolAdherenceStatus | Status, der angibt, ob der Case dem standardmäßigen klinischen Pfad gefolgt ist. | ||
| Beschreibung Dieses Attribut vergleicht die Reihenfolge der Aktivitäten im Case mit einem definierten Referenzmodell (Standard Operating Procedure). Es unterstützt die Ansicht zur Einhaltung klinischer Protokolle. Mögliche Werte sind „Compliant“, „Skipped Step“ oder „Out of Sequence“. So können klinische Verantwortliche nicht konforme Cases schnell filtern, ohne jede Prozessdarstellung manuell prüfen zu müssen. Warum das wichtig ist Es erkennt schnell Abweichungen von evidenzbasierten Versorgungsstandards. Bezugsquelle Wird im Process-Mining-Tool berechnet oder vorab in SQL verarbeitet. Beispiele KonformAbweichendUnvollständig | |||
| Wartezeit bei der Verlegung TransferWaitDuration | Die verstrichene Zeit zwischen der Anordnung einer Verlegung und der tatsächlichen Verlegung. | ||
| Beschreibung Diese Kennzahl misst die Zeitspanne zwischen „Verlegung angeordnet“ und „Patient verlegt“. Sie ist der zentrale Datenpunkt für die Analyse interner Stationsverlegungen. Hohe Werte weisen auf „Boarding“ hin, also auf Patienten, die auf ein Bett warten. Dadurch wird der vorgelagerte Ablauf aus der Notaufnahme blockiert. Warum das wichtig ist Sie macht logistische Engpässe und Kapazitätsengpässe im Patientenfluss sichtbar. Bezugsquelle Berechnete Differenz zwischen den Timestamps des Anordnungs- und des Verlegungsereignisses. Beispiele 2 Std. 30 Min.45 Min.12 Std. | |||
Aktivitäten der Patientenreise
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Diagnose bestätigt | Die Eingabe einer bestätigten Diagnose in die Problemliste des Patienten oder in das Diagnosenfeld des Patientenkontakts. Sie markiert den Abschluss der Untersuchungsphase. | ||
| Warum das wichtig ist Erforderlich für die KPI „Zeit bis zur endgültigen Diagnose“. Markiert den Übergang von der Untersuchung zur gezielten Behandlung. Bezugsquelle Tabelle PAT_ENC_DX oder Aktualisierung von PROBLEM_LIST mit Verknüpfung zum Patientenkontakt. Erfassen Wird protokolliert, wenn ein Kliniker einen Eintrag in der Aktivität „Encounter Diagnosis“ ergänzt Ereignistyp explicit | |||
| Patient entlassen | Der offizielle Abschluss des stationären Patientenkontakts. Wird erfasst, wenn der Patient im Census virtuell entlassen wird. | ||
| Warum das wichtig ist Das formale Ende der Patient Episode für die Berechnung der Verweildauer. Unverzichtbar für „Patient Flow Variant Discovery“. Bezugsquelle ADT Feed (Event A03) oder PAT_ENC_HSP.DISCH_TIME. Erfassen Wird protokolliert, wenn das Verwaltungspersonal den Entlassungs-Workflow abschließt Ereignistyp explicit | |||
| Patient registriert | Die erstmalige Erstellung des Patientenkontaktdatensatzes im System markiert den Beginn der Patient Episode. Dieses Ereignis wird ausdrücklich erfasst, wenn ein Patient am Registrierungsschalter oder in der Notaufnahme eintrifft und im Epic EHR aufgenommen wird. | ||
| Warum das wichtig ist Legt den Ausgangspunkt für die gesamte Patient Journey fest und ermöglicht die Berechnung der Gesamtverweildauer. Unverzichtbar für das Dashboard „Triage-Durchsatz und Wartezeiten“. Bezugsquelle ADT Feed (Event A04 oder A01) oder Clarity-Tabelle PAT_ENC (Erstellung von HSP_ACCOUNT_ID). Erfassen Wird protokolliert, wenn die Transaktion „Check In“ oder „Admit“ ausgeführt wird Ereignistyp explicit | |||
| Triage abgeschlossen | Der Abschluss der ersten pflegerischen Untersuchung oder Triage-Bewertung. Dieses Ereignis wird typischerweise erfasst, wenn das Triage-Flowsheet abgelegt wird oder sich der Triage-Status in „Complete“ ändert. | ||
| Warum das wichtig ist Entscheidend für das Dashboard „Triage-Durchsatz und Wartezeiten“, um die Effizienz am Prozesseingang zu messen. Verzögerungen an dieser Stelle wirken sich auf den gesamten Versorgungspfad aus. Bezugsquelle PAT_ENC_HSP.TRIAGE_END_TIME oder Timestamp der Ablage einer bestimmten Flowsheet-Zeile (FLO_MEASUREMENT). Erfassen Wird protokolliert, wenn die Triage-Dokumentation signiert wird oder sich ein Statusfeld aktualisiert Ereignistyp explicit | |||
| Diagnostischer Test angeordnet | Die Eingabe eines Auftrags für Bildgebung (Radiology) oder Labordienstleistungen. Wird erfasst, wenn ein Arzt einen Auftrag im CPOE-System eingibt und signiert. | ||
| Warum das wichtig ist Ausgangspunkt für das Dashboard „Zykluszeiten diagnostischer Dienste“. Hohe Fallzahlen ohne entsprechende Ergebnisse weisen auf Bottlenecks hin. Bezugsquelle Tabelle ORDER_PROC, wenn ORDER_TYPE den Wert Lab oder Imaging/Radiology hat. Erfassen Wird protokolliert, wenn der Auftragsstatus in „Signed“ oder „Active“ wechselt Ereignistyp explicit | |||
| Diagnostischer Test durchgeführt | Die tatsächliche Durchführung des diagnostischen Tests oder die Ablage des Ergebnisses. Bei Laboruntersuchungen ist dies die Verarbeitung der Probe, bei bildgebenden Untersuchungen der Abschluss des Scans. | ||
| Warum das wichtig ist Endpunkt für die KPI „Durchschnittliche Zykluszeit diagnostischer Tests“. Wichtig, um Verzögerungen bei klinischen Entscheidungsunterstützungsdiensten zu verstehen. Bezugsquelle ORDER_PROC.PROC_END_TIME oder ORDER_STAT_HISTORY, wenn der Status in „Completed“ oder „Resulted“ wechselt. Erfassen Wird protokolliert, wenn der Techniker die Aufgabe abschließt oder die Ergebnisschnittstelle Daten empfängt Ereignistyp explicit | |||
| Entlassungsauftrag signiert | Die formale Genehmigung des Arztes, dass der Patient das Krankenhaus verlassen darf. Dies ist ein spezifischer Auftragseintrag in Epic. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein in „Entlassungsplanung und -durchführung“. Die Zeitspanne zwischen diesem Ereignis und dem tatsächlichen Verlassen des Krankenhauses stellt den administrativen Verzug dar. Bezugsquelle ORDER_PROC mit dem Typ „Discharge Patient“. Erfassen Wird protokolliert, wenn der Arzt den Entlassungsauftrag signiert Ereignistyp explicit | |||
| Entlassungsplanung gestartet | Der Beginn der Aktivitäten zur Vorbereitung der Entlassung des Patienten. Wird über die Dokumentation des Case Managements oder bestimmte Auftragstypen „Discharge“ erfasst. | ||
| Warum das wichtig ist Wichtig für das Dashboard „Entlassungsplanung und -durchführung“. Ein früher Beginn steht in Zusammenhang mit einer kürzeren Verweildauer. Bezugsquelle Erstellung von HSP_DISCH_PLAN oder erste Notiz durch Case Manager oder Sozialarbeiter. Erfassen Abgeleitet aus der ersten Interaktion mit dem Discharge Navigator oder der ersten Case-Mgmt.-Notiz Ereignistyp inferred | |||
| Konsultation abgeschlossen | Der Abschluss der fachärztlichen Untersuchung, typischerweise gekennzeichnet durch die Signatur einer Consult Note oder das Schließen des Konsultationsauftrags. | ||
| Warum das wichtig ist Endpunkt für die „Vorlaufzeit der Facharztkonsultation“. Zeigt an, dass die fachärztliche Empfehlung vorliegt und der Versorgungsplan fortgesetzt werden kann. Bezugsquelle HNO_NOTE_TEXT (abgelegte Notiz vom Typ Consult) oder Statusänderung von ORDER_PROC in „Completed“. Erfassen Abgeleitet aus dem Erstellungszeitpunkt der Consult Note oder der Aktualisierung des Auftragsstatus Ereignistyp inferred | |||
| Konsultation angefordert | Ein Auftrag an einen Facharzt zur Untersuchung des Patienten. Wird in Epic als spezifischer Auftragstyp „Consult“ erfasst. | ||
| Warum das wichtig ist Ausgangspunkt für die KPI „Vorlaufzeit der Facharztkonsultation“. Hilft, Engpässe in bestimmten medizinischen Fachbereichen zu erkennen. Bezugsquelle ORDER_PROC mit ORDER_CLASS = „Consult“ oder spezifische Überweisungsaufträge. Erfassen Wird protokolliert, wenn der Konsultationsauftrag signiert wird Ereignistyp explicit | |||
| Medikament verabreicht | Die Verabreichung eines Medikaments an den Patienten durch eine Pflegekraft oder einen Leistungserbringer. Wird im Medication Administration Record (MAR) erfasst. | ||
| Warum das wichtig ist Zentrales Ereignis für das Dashboard „Leistung der Medikamentenverabreichung“. Verfolgt die Einhaltung des „Treatment Plan Developed“. Bezugsquelle Tabelle MAR_ADMIN_INFO, insbesondere Ereignisse mit der Aktion „Given“ oder „New Bag“. Erfassen Wird protokolliert, wenn die Pflegekraft das Patientenarmband und das Medikament scannt (BCMA) Ereignistyp explicit | |||
| Nachsorgetermin vereinbart | Die Buchung eines zukünftigen ambulanten Termins für den Patienten. Wird im mit dem Patientendatensatz verknüpften Cadence-Planungsmodul erfasst. | ||
| Warum das wichtig ist Unterstützt die „Automatisierungsrate bei der Nachsorgeterminplanung“. Sichert die Kontinuität der Versorgung und hilft, Wiederaufnahmen zu vermeiden. Bezugsquelle PAT_ENC_APPT, mit der Patienten-ID verknüpft und zeitnah zur Entlassung erstellt. Erfassen Wird protokolliert, wenn der Termin im Cadence-Modul bestätigt wird Ereignistyp explicit | |||
| Patient verlegt | Die physische Verlegung des Patienten in eine neue Abteilung oder Station. Wird über ADT-Transferereignisse erfasst. | ||
| Warum das wichtig ist Endpunkt für die „Durchschnittliche Transferzeit zwischen Stationen“. Unterstützt die „Analyse interner Stationsverlegungen“, um Bottlenecks in der Krankenhauslogistik zu erkennen. Bezugsquelle ADT Feed (Event A02) oder PAT_ENC_HSP_TRANSACTION (Transfer In). Erfassen Wird protokolliert, wenn der Stationssekretär den Patientenstandort im Census aktualisiert Ereignistyp explicit | |||
| Transfer angeordnet | Eine Anfrage, den Patienten auf eine andere Einheit oder Versorgungsebene zu verlegen. Wird im System als „Bed Request“ oder „Transfer Order“ erfasst. | ||
| Warum das wichtig ist Ausgangspunkt für die „Durchschnittliche Transferzeit zwischen Stationen“. Unterscheidet zwischen der klinischen Entscheidung zur Verlegung und der logistischen Verfügbarkeit eines Bettes. Bezugsquelle ADT_TRANSFER_ORDER oder ORDER_PROC (Bed Request). Erfassen Wird protokolliert, wenn der Arzt den Transferauftrag eingibt Ereignistyp explicit | |||
| Versorgungsplan gestartet | Die Zuordnung eines bestimmten klinischen Versorgungspfads oder Protokolls zu einem Patienten. Dieses Ereignis wird erfasst, wenn ein Standard-Order Set oder Care Plan dem Kontext des Patientenkontakts zugeordnet wird. | ||
| Warum das wichtig ist Unterstützt die „Clinical Protocol Compliance View“, indem die Absicht markiert wird, einen Versorgungsstandard einzuhalten. Abweichungen von den anschließend geplanten Schritten lassen sich ab diesem Zeitpunkt messen. Bezugsquelle ORDER_SET_BKG oder Care-Plan-Tabellen, die anzeigen, dass ein Protokoll mit dem Patientenkontakt verknüpft wurde. Erfassen Wird protokolliert, wenn ein Kliniker ein Order Set auswählt und signiert Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Melden Sie sich bei Epic Hyperspace an und starten Sie die Reporting Workbench (RWB) über die Aktivität Analytics oder My Reports.
- Erstellen Sie einen neuen Bericht, indem Sie die Registerkarte Library auswählen und nach dem Template „Encounter Search“ oder „Patient Encounters“ suchen. Dieses Template ermöglicht den Abruf von Kontaktdetails auf Ebene des Kontakts, die durch die CSN (Contact Serial Number) identifiziert werden.
- Kriterien konfigurieren (Registerkarte Settings):
- Legen Sie den Datumsbereich fest, etwa „Discharge Date = Last 90 Days“, um abgeschlossene Episoden zu erfassen.
- Filtern Sie nach Encounter Type, etwa „Hospital Encounter“ oder „Emergency“, um nicht relevante ambulante Besuche auszuschließen.
- Filtern Sie nach Abteilung oder Facility, wenn ein bestimmter Umfang erforderlich ist.
- Anzeigespalten konfigurieren (Registerkarte Display):
- Dies ist der entscheidende Schritt der Extraktion. Suchen Sie nach den spezifischen Spalten, die den Timestamps der erforderlichen Aktivitäten entsprechen, und fügen Sie sie hinzu.
- Fügen Sie Patientenkennungen hinzu:
CSN(Patientenepisode),MRN(Patienten-ID). - Fügen Sie Demografische Daten/Attribute hinzu:
Abteilung,Discharge Disposition,Primary Diagnosis Code,Provider. - Fügen Sie Timestamp-Spalten hinzu: Suchen Sie nach Spalten wie
Admission Time,Triage End Time,Discharge Time,Discharge Order Time,First Med Admin Timeusw. Die genaue Zuordnung finden Sie im Abschnitt zur Abfrage und Konfiguration.
- Führen Sie den Bericht aus und prüfen Sie die Ergebnisse im Vorschaufenster.
- Daten exportieren:
- Klicken Sie auf Toolbar > Export.
- Wählen Sie das Format CSV oder Text (Tab Delimited).
- Stellen Sie sicher, dass Include Column Headers aktiviert ist.
- Speichern Sie die Datei als
Raw_Epic_Extract.csv.
- Datentransformation (entscheidend):
- Der RWB-Export erzeugt einen „breiten“ Datensatz mit einer Zeile pro Patientenepisode und mehreren Timestamp-Spalten.
- Führen Sie ein Unpivot durch, also eine Umformung, bei der jede Timestamp-Spalte zu einer eigenen Zeile im Event Log wird.
- Erstellen Sie eine abschließende Datei mit den Spalten
PatientEpisodeId,ActivityName,EventTimestampund den zugeordneten Attributen.
- Datumsangaben formatieren: Stellen Sie sicher, dass
EventTimestampim mit ProcessMind kompatiblen ISO-Format (YYYY-MM-DD HH:MM:SS) vorliegt. - Abschließende Validierung: Prüfen Sie, ob die Datei die Überschriften
PatientEpisodeId,ActivityNameundEventTimestampenthält, und laden Sie sie in ProcessMind hoch.
Konfiguration
- Template: Verwenden Sie „Encounter Search“ (LBF) oder „Find Patients“, abhängig von Ihrer Epic-Version.
- Datumsbereich: Begrenzen Sie den Zeitraum zunächst auf 3 bis 6 Monate, um Timeout-Fehler zu vermeiden. Die RWB ist nicht für umfangreiche Massendatenextraktionen optimiert.
- Zeilenlimit: Die Epic RWB hat häufig ein Zeilenlimit, zum Beispiel 25.000 oder 50.000 Zeilen. Stellen Sie sicher, dass Ihr Datumsbereich dieses Limit nicht überschreitet, oder führen Sie mehrere Batches aus.
- Berechtigungen: Erforderlich sind die Sicherheitsberechtigungen „Create“ und „Export“ für die Reporting Workbench.
- Leistung: Führen Sie die Suche bei großen historischen Zeiträumen außerhalb der Spitzenzeiten aus.
- Granularität: Diese Methode liefert zusammengefasste Timestamps auf Encounter-Ebene, zum Beispiel „First Med Admin“. Sie extrahiert nicht jede einzelne Schleife, etwa die Verabreichung jeder einzelnen Tablette, sofern Sie keine speziellen „Audit“-Templates verwenden. Diese sind für diesen Anwendungsfall selten.
a Beispielabfrage 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 Schritte
Fordern Sie Datenbankzugriff an: Stellen Sie sicher, dass Sie Lesezugriff auf die Epic Clarity Console oder einen SQL-Client mit Verbindung zur Clarity-Produktions- oder Reporting-Datenbank haben. Sie benötigen Berechtigungen für
PAT_ENC,ORDER_PROC,CLARITY_ADT,MAR_ADMIN_INFOund zugehörige Referenztabellen.Legen Sie Umfang und Filter-IDs fest: Führen Sie vor dem vollständigen Skript kleine Erkennungsabfragen aus, um die spezifischen Werte von
ORDER_TYPE_Cfür Labs, Radiologie, Konsile und Transfers in Ihrer Epic-Instanz zu ermitteln. Diese Custom Lists (Category Lists) unterscheiden sich je nach Krankenhaus.Konfigurieren Sie das Zeitfenster: Suchen Sie im bereitgestellten SQL-Skript nach den
WHERE-Klauseln, die nachCONTACT_DATEoderHOSP_ADMSN_TIMEfiltern. Passen Sie diese an den gewünschten Extraktionszeitraum an, zum Beispiel die letzten 6 Monate.Ordnen Sie benutzerdefinierte Flowsheets zu, optional: Wenn Sie präzise Timestamps für Triage oder Entlassungsplanung benötigen, die nicht in der zentralen Encounter-Tabelle enthalten sind, ermitteln Sie die entsprechende
FLO_MEAS_ID(Flowsheet Measure ID) für diese Felder und aktualisieren Sie die Platzhalterabschnitte des Skripts.Führen Sie die Abfrage aus: Führen Sie das vollständige SQL-Skript in Ihrem SQL-Client aus, zum Beispiel in SQL Server Management Studio oder Oracle SQL Developer. Das Skript verwendet
UNION ALL, um verschiedene klinische Ereignisse in einer einheitlichen Event-Log-Struktur zusammenzuführen.Nachbearbeitung: Die Abfrage gibt eine flache Liste zurück. Prüfen Sie, dass
EventTimestampnicht null ist. Konvertieren Sie datenbankspezifische Datums- und Zeitformate in ISO 8601 (YYYY-MM-DDTHH:MM:SS), falls Ihre Middleware dies erfordert.Exportieren Sie die Daten: Speichern Sie das Ergebnis als CSV-Datei. Stellen Sie sicher, dass die Header den definierten Attributen entsprechen, zum Beispiel PatientEpisodeId und ActivityName.
Laden Sie die Daten in ProcessMind hoch: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie
PatientEpisodeIdals Case ID,ActivityNameals Activity undEventTimestampals Timestamp zu.
Konfiguration
- Datenbankverbindung: Epic Clarity, typischerweise mit MSSQL- oder Oracle-Backend.
- Datumsfilterung: Filtern Sie nach
PAT_ENC.HOSP_ADMSN_TIMEoderPAT_ENC.CONTACT_DATE. Für die erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um die Abfrageleistung zu steuern. - Encounter-Typen: Das Skript filtert stationäre und Notfall-Encounters (
ENC_TYPE_C, häufig mit den Werten 3 und 50). Prüfen Sie diese Werte jedoch anhand vonZC_ENC_TYPE. - Order-Typen: Die Werte von
ORDER_TYPE_Cfür Labs, Bildgebung und Konsile müssen anhand der lokalen Konfiguration vonZC_ORDER_TYPEangepasst werden. - Leistung: Das Skript durchsucht umfangreiche Tabellen wie
ORDER_PROCundCLARITY_ADT. Stellen Sie sicher, dass geeignete Indizes verwendet werden, oder führen Sie die Abfrage außerhalb der Spitzenzeiten aus.
a Beispielabfrage 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 Möchten Sie beginnen?
Beginnen Sie noch heute damit, Ihre klinischen Abläufe zu verbessern, indem Sie dieses Template auf Ihre Epic-Daten anwenden. Unser Team unterstützt Sie bei der Datenextraktion, damit Sie schnell erste Ergebnisse erzielen.
Optimieren Sie Ihre Patientenreise und verkürzen Sie die Durchlaufzeit noch heute
Ermitteln Sie klinische Engpässe und verkürzen Sie die Durchlaufzeit um 30 %.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.