Ihr Daten-Template für den Patientenpfad
Ihr Daten-Template für den Patientenpfad
- Empfohlene Attribute für den klinischen Kontext
- Zentrale Prozessmeilensteine zur Nachverfolgung
- Spezifische Hinweise zur Datenextraktion aus Epic EHR
Attribute des Patientenpfads
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Die konkrete klinische oder administrative Handlung. | ||
| Beschreibung Dieses Attribut enthält den Namen des Ereignisses im Behandlungsverlauf, zum Beispiel „Patient registriert“, „Medikament verabreicht“ oder „Entlassungsanordnung unterzeichnet“. Es ist das zentrale Element zur Definition des Prozessablaufs. In der Analyse bilden die Werte dieses Feldes die Knoten der Prozesslandkarte. Sie werden aus verschiedenen Transaktionscodes und Anordnungsstatus im EHR abgeleitet und ergeben ein verständliches Event Log. Warum das wichtig ist Es definiert die Prozessschritte und ermöglicht die Visualisierung des Workflows. Woher beziehen Abgeleitet aus den Tabellen CLARITY_ADT, ORDER_PROC und ORDER_MED. Beispiele Triage abgeschlossenDiagnostischer Test angeordnetPatient entlassenMedikament verabreicht | |||
| Ereignis-Timestamp EventTimestamp | Datum und genaue Uhrzeit des Ereignisses. | ||
| 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 zeitbasierten Kennzahlen zu berechnen, etwa die Aufenthaltsdauer und Zykluszeiten. Für die Erkennung von Engpässen ist die Genauigkeit dieses Feldes entscheidend. Es liefert die zeitlichen Bezugspunkte für Start und Ende und unterstützt damit die Dashboards „Triage-Durchsatz“ und „Zeit bis zur gesicherten Diagnose“. Warum das wichtig ist Damit lassen sich Zykluszeiten, Durchlaufzeiten und die Reihenfolge der Prozessschritte berechnen. Woher beziehen Je nach Quelltabelle verschiedene Timestamp-Spalten, zum Beispiel EFFECTIVE_TIME und ORDER_TIME. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z | |||
| Patienten-Behandlungsfall PatientEpisodeId | Die eindeutige Kennung des jeweiligen Patientenkontakts oder Behandlungsfalls. | ||
| Beschreibung Der Patienten-Behandlungsfall dient als primäre Case-ID für Process Mining. Er umfasst alle klinischen, administrativen und logistischen Ereignisse eines zusammenhängenden Behandlungszeitraums, etwa eines stationären Aufenthalts oder eines Besuchs in der Notaufnahme. In Epic Clarity entspricht er in der Regel der Contact Serial Number (CSN) oder der Encounter ID. Durch die Analyse dieses Attributs lässt sich der gesamte Behandlungsverlauf rekonstruieren. Triage, Diagnose, Behandlung und Entlassung können so zu einem zusammenhängenden Prozessfall verknüpft werden. Warum das wichtig ist Dieser Schlüssel ist entscheidend, um unterschiedliche Ereignisse einem einzelnen Prozessfall zuzuordnen. Woher beziehen 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 gibt an, wann die Daten zuletzt durch die ETL-Pipeline verarbeitet wurden. Es unterscheidet sich vom Ereignis-Timestamp und hilft dabei, die Aktualität der Daten zu überwachen. Analysten können damit feststellen, ob das Dashboard den aktuellen Stand abbildet oder ob eine Datenverzögerung die Genauigkeit von Kennzahlen wie den Wartezeiten bei der Triage beeinträchtigt. Warum das wichtig ist Es hilft, Aktualität und Zuverlässigkeit der Process-Mining-Daten einzuschätzen. Woher beziehen 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 Epic EHR. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Daten an. In dieser Ansicht lautet der Wert meist „Epic EHR“. Es ist auch hilfreich, wenn Daten aus weiteren Systemen wie einem separaten LIS (Laborinformationssystem) oder einem Abrechnungssystem einfließen. Bei der Analyse sorgt es für die Nachvollziehbarkeit der Datenherkunft und erleichtert die Fehlersuche, wenn Ereignisse im Vergleich zum Quellsystem fehlen oder fehlerhaft erscheinen. Warum das wichtig ist Es macht die Herkunft der Daten nachvollziehbar und liefert den nötigen Kontext. Woher beziehen Fest codiert oder aus der Konfiguration der Verbindungszeichenfolge abgeleitet. Beispiele Epic EHREpic ClarityEpic Caboodle | |||
| Abteilungsname DepartmentName | Die Station oder Abteilung, in der die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut gibt den organisatorischen Ort des Ereignisses an, zum Beispiel „Notaufnahme“, „Radiologie“ oder „Allgemeinchirurgische Station“. Es ist entscheidend für die Analyse interner Stationsverlegungen. Die Daten ermöglichen eine Aufschlüsselung der Prozesslandkarte nach Abteilung. So können Verantwortliche Engpässe in ihrer eigenen Einheit von Problemen unterscheiden, die das gesamte Krankenhaus betreffen. Warum das wichtig ist Es ermöglicht die Filterung nach Organisationseinheit und die Analyse von Übergaben. Woher beziehen Epic-Clarity-Tabelle: CLARITY_DEP, Spalte: DEPARTMENT_NAME Beispiele NotaufnahmeRadiologieICUPädiatrie | |||
| Art des Behandlungsfalls EncounterType | Die Klassifizierung des Patientenbesuchs, zum Beispiel stationär oder in der Notaufnahme. | ||
| Beschreibung Dieses Attribut kategorisiert die Art des Patienten-Behandlungsfalls. Übliche Werte sind „Notfall“, „Stationär“, „Ambulant“ oder „Virtuell“. Das Feld wird dem Attribut „CaseType“ zugeordnet und ist grundlegend für die Filterung der Analyse. Das Dashboard zur Entlassungsplanung ist beispielsweise vor allem für stationäre Behandlungsfälle relevant, während die Triage nur Notfälle betrifft. Warum das wichtig ist Es liefert den übergeordneten Kontext für den Prozessfall. Woher beziehen Epic-Clarity-Tabelle: PAT_ENC, Spalte: ENC_TYPE_C Beispiele NotfallKrankenhausambulanzStationär | |||
| Behandler-ID ProviderId | Die Kennung des Benutzers oder Klinikers, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die eindeutige ID des Mitarbeitenden, der für das Ereignis verantwortlich war, etwa der Pflegekraft, die ein Medikament verabreicht, oder des Arztes, der die Entlassungsanordnung unterzeichnet. Die Zuordnung zum generischen Attribut „Benutzer“ ermöglicht die Analyse von Leistungsunterschieden und Arbeitsaufkommen. Bei automatisierten Aktivitäten kann es sich um die ID eines Systembenutzers handeln. Warum das wichtig ist Damit lassen sich Leistungsunterschiede und Arbeitsaufkommen der Mitarbeitenden analysieren. Woher beziehen Epic-Clarity-Tabelle: CLARITY_EMP, Spalte: USER_ID Beispiele EMP10023DOC5592SYSTEM | |||
| Code der Hauptdiagnose PrimaryDiagnosisCode | Der ICD-10-Code oder interne Code für die Hauptdiagnose. | ||
| Beschreibung Dieses Attribut erfasst die bestätigte Erkrankung des Patienten. In der Regel wird es bei der Aktivität „Diagnose bestätigt“ ausgefüllt. Es dient dazu, Fälle für die Ansicht zur Einhaltung klinischer Protokolle nach Erkrankung zu gruppieren. Durch die Zuordnung zum Attribut „Produkt“ können Analysten erkennen, wie sich die „Erbringung“ der Versorgung je nach Erkrankung unterscheidet. Warum das wichtig ist Es gruppiert Fälle nach klinischer Ähnlichkeit und unterstützt so die Protokollanalyse. Woher beziehen 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 treten zu einem bestimmten Zeitpunkt ein. Manche Aktivitäten, etwa „Diagnostische Untersuchung durchgeführt“ oder „Konsil abgeschlossen“, dauern jedoch länger. Dieses Attribut erfasst den Abschlusszeitpunkt. Damit lässt sich die aktive Bearbeitungszeit von der Wartezeit unterscheiden. Das ist besonders für das Dashboard „Zykluszeiten diagnostischer Leistungen“ relevant. Warum das wichtig ist Damit lassen sich die Dauer von Aktivitäten und die Ressourcenauslastung berechnen. Woher beziehen Die Epic-EHR-Dokumentation enthält Informationen zu den jeweiligen Endzeitspalten in ORDER_PROC. Beispiele 2023-10-15T09:45:00Z2023-10-16T15:00:00Z | |||
| Entlassungsziel DischargeDisposition | Der Aufenthaltsort des Patienten nach der Entlassung, zum Beispiel zu Hause, in einer Pflegeeinrichtung 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 zum Wiederaufnahmerisiko ist es besonders wichtig, da sich die Wiederaufnahmeraten von Patienten, die in eine qualifizierte Pflegeeinrichtung (SNF) entlassen werden, von denen unterscheiden, die nach Hause gehen. Warum das wichtig ist Es liefert Kontext zum Ergebnis des Behandlungsprozesses. Woher beziehen Epic-Clarity-Tabelle: PAT_ENC, Spalte: DISCH_DISP_C Beispiele Zu HauseQualifizierte PflegeeinrichtungHäusliche Pflege | |||
| Kennzeichen für Wiederaufnahme ReadmissionFlag | Gibt an, ob der Patient innerhalb von 30 Tagen unerwartet zurückgekehrt ist. | ||
| Beschreibung Dieses boolesche Attribut gibt an, ob auf den jeweiligen Behandlungsfall innerhalb von 30 Tagen eine weitere ungeplante Aufnahme desselben Patienten folgte. Es bildet die Grundlage für die KPI zur Rate ungeplanter Wiederaufnahmen innerhalb von 30 Tagen. In der Analyse dient es als wichtige Ergebnisvariable. Prozesspfade, die zu einem Wert „True“ führen, werden untersucht, um Ursachen in der Entlassungsplanung zu ermitteln. Warum das wichtig ist Es hilft, Probleme bei der Entlassung und bei der Versorgungsqualität zu erkennen. Woher beziehen Wird per SQL berechnet, indem zukünftige Behandlungsfälle derselben MRN berücksichtigt werden. Beispiele truefalse | |||
| Patienten-MRN PatientMrn | Die Medical Record Number (MRN), die den Patienten identifiziert. | ||
| Beschreibung Die MRN ist die eindeutige Kennung eines Patienten im gesamten Gesundheitssystem und unterscheidet sich von der ID des Behandlungsfalls. Mit ihr lässt sich die Krankengeschichte eines Patienten über mehrere Besuche hinweg verfolgen. Dieses Attribut hilft, Wiederaufnahmen zu erkennen und einzelne Behandlungsfälle für das Dashboard zum Wiederaufnahmerisiko zu verknüpfen. Im generischen Modell wird es dem Attribut „Kunde“ zugeordnet. Warum das wichtig ist Sie ist wichtig, um wiederholte Besuche zu erkennen und die Krankengeschichte des Patienten zu analysieren. Woher beziehen Epic-Clarity-Tabelle: PATIENT, Spalte: PAT_ID oder PAT_MRN_ID Beispiele MRN-882910MRN-112003MRN-554211 | |||
| Triage-Dringlichkeitsstufe TriageAcuityLevel | Die Dringlichkeitsstufe, die dem Patienten bei der Triage zugewiesen wird. | ||
| Beschreibung Dieses Attribut gibt an, wie dringend der Zustand des Patienten ist, üblicherweise anhand einer Skala, zum Beispiel den ESI-Stufen 1 bis 5. Es wird bei der Aktivität „Triage abgeschlossen“ erfasst. Es ermöglicht die Aufschlüsselung im Dashboard „Ressourcenbedarf nach Schweregrad“. Patienten mit hoher Dringlichkeit durchlaufen andere Prozesspfade als Patienten mit niedriger Dringlichkeit. Dieses Feld hilft, die Varianten zu unterscheiden. Warum das wichtig ist Es gliedert den Prozess nach Dringlichkeit und erwartetem Ressourcenbedarf. Woher beziehen Informationen zum Feld für die Dringlichkeitsstufe in den ED-Protokollen finden Sie in der Epic-EHR-Dokumentation. Beispiele 1 - Wiederbelebung2 - Akuter Notfall3 - Dringend | |||
| Fachgebiet des anordnenden Arztes OrderingProviderSpecialty | Das Fachgebiet des Arztes, der ein Konsil oder eine Untersuchung anfordert. | ||
| Beschreibung Dieses Attribut erfasst die Abteilung oder das Fachgebiet des anordnenden Arztes, zum Beispiel „Kardiologie“ oder „Onkologie“. Es wird im Dashboard zu Wartezeiten auf fachärztliche Konsile verwendet. Damit lässt sich untersuchen, ob bestimmte Fachgebiete bei internen Leistungen länger warten müssen als andere. So werden mögliche Benachteiligungen oder Ressourcenengpässe in einzelnen Leistungsbereichen sichtbar. Warum das wichtig ist Es gliedert die Nachfrage nach diagnostischen Leistungen und Konsilen. Woher beziehen Informationen zu den Stammdaten der Behandler finden Sie in der Epic-EHR-Dokumentation. Beispiele KardiologieInnere MedizinOrthopädie | |||
| Kosten diagnostischer Anordnung DiagnosticOrderCost | Die internen Kosten einer diagnostischen Untersuchung oder eines Eingriffs. | ||
| Beschreibung Dieses Attribut ordnet Aktivitäten vom Typ „Diagnostische Untersuchung durchgeführt“ einen finanziellen Wert zu. Damit lassen sich finanzielle Aspekte in der Prozesslandkarte darstellen. Es ist keine primäre klinische Kennzahl, hilft der Verwaltung aber, die finanziellen Auswirkungen verschiedener Prozessvarianten einzuschätzen, insbesondere bei hohen Schweregraden mit entsprechendem Ressourcenbedarf. Warum das wichtig ist Es ergänzt die Effizienzanalyse von Prozessen um eine finanzielle Dimension. Woher beziehen Abrechnungs- oder Kostenrechnungstabellen, die mit dem Eingriff verknüpft sind. Beispiele 150.001200.0045.00 | |||
| Regionsname RegionName | Die geografische Region oder der Krankenhausstandort. | ||
| Beschreibung Bei Gesundheitssystemen mit mehreren Standorten gibt dieses Attribut den jeweiligen Standort an. So lässt sich die Leistung verschiedener Krankenhäuser vergleichen. Die Zuordnung zum Attribut „Region“ ermöglicht standortübergreifende Vergleiche. Damit lässt sich beispielsweise feststellen, ob eine Klinik den Triage-Durchsatz besser steuert als eine andere. Warum das wichtig ist Es ermöglicht den Vergleich verschiedener Einrichtungen innerhalb eines Gesundheitsnetzwerks. Woher beziehen Abgeleitet aus den Stammdaten der Abteilung oder Einrichtung. Beispiele NordcampusStadtzentrumWestflügel | |||
| Status der Protokolleinhaltung ProtocolAdherenceStatus | Gibt an, ob der Fall dem klinischen Standardpfad gefolgt ist. | ||
| Beschreibung Dieses Attribut vergleicht die Abfolge der Aktivitäten im Fall mit einem festgelegten Referenzmodell (Standard Operating Procedure). Es unterstützt die Ansicht zur Einhaltung klinischer Protokolle. Mögliche Werte sind „Konform“, „Schritt übersprungen“ oder „Reihenfolge abweichend“. So können klinische Verantwortliche Fälle mit Abweichungen schnell filtern, ohne jede Prozesslandkarte einzeln prüfen zu müssen. Warum das wichtig ist Es erkennt schnell Abweichungen von evidenzbasierten Versorgungsstandards. Woher beziehen Wird im Process-Mining-Tool berechnet oder vorab in SQL verarbeitet. Beispiele KonformAbweichendUnvollständig | |||
| Terminbuchungsmethode SchedulingMethod | Gibt an, wie der Folgetermin gebucht wurde. | ||
| Beschreibung Dieses Attribut erfasst den Kanal, über den Termine gebucht werden, zum Beispiel „MyChart“, „Cadence Auto“ oder „Empfang“. Es ist entscheidend für das Dashboard zum Automatisierungsstatus bei ambulanten Folgeterminen. Wenn der Wert auf einen digitalen Kanal des Systems oder des Patienten hinweist, kann das Kennzeichen „IsAutomated“ auf „true“ gesetzt werden. So wird der Erfolg digitaler Transformationsinitiativen sichtbar. Warum das wichtig ist Es zeigt, wie stark automatisierte oder selbstbediente Angebote genutzt werden. Woher beziehen Informationen zur Quelle der Terminerstellung finden Sie in der Epic-EHR-Dokumentation. Beispiele MyChartCadenceTelefonPersönlich | |||
| Terminplanung automatisiert IsAutomatedScheduling | Kennzeichen dafür, ob die Terminplanung ohne Eingreifen von Mitarbeitenden erfolgte. | ||
| Beschreibung Dieses boolesche Attribut wird aus der Terminbuchungsmethode abgeleitet. Wurde der Termin über MyChart oder einen automatisierten Cadence-Workflow gebucht, lautet der Wert „True“. Es unterstützt direkt die KPI zur Automatisierungsrate bei der Terminplanung für Folgetermine. So können Verantwortliche im operativen Bereich nachvollziehen, in welchem Umfang Technologie den Verwaltungsaufwand reduziert. Warum das wichtig ist Es misst den Erfolg der Prozessautomatisierung. Woher beziehen Abgeleitet aus SchedulingMethod. Beispiele truefalse | |||
| Wartezeit bis zur Verlegung TransferWaitDuration | Die Zeit zwischen der Verlegungsanordnung 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 einen Rückstau hin: Patienten warten auf ein Bett, wodurch der Ablauf in der Notaufnahme ins Stocken gerät. Warum das wichtig ist Sie macht logistische Engpässe und Kapazitätsengpässe im Patientenfluss sichtbar. Woher beziehen Berechnet als Zeitdifferenz zwischen den Timestamps der Anordnung und der Verlegung. Beispiele 2 Std. 30 Min.45 Min.12 Std. | |||
Aktivitäten im Patientenpfad
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Diagnose bestätigt | Eintrag einer bestätigten Diagnose in die Problemliste des Patienten oder in das Diagnosenfeld des Patientenfalls. Kennzeichnet den Abschluss der diagnostischen Abklärung. | ||
| Warum das wichtig ist Erforderlich für die KPI „Zeit bis zur gesicherten Diagnose“. Kennzeichnet den Übergang von der Untersuchung zur gezielten Behandlung. Woher beziehen Tabelle PAT_ENC_DX oder Aktualisierung von PROBLEM_LIST mit Bezug zum Patientenfall. Erfassung Wird protokolliert, wenn ein Arzt einen Eintrag in der Aktivität „Encounter Diagnosis“ hinzufügt. Ereignistyp explicit | |||
| Patient entlassen | Formeller Abschluss des stationären Patientenfalls. Wird erfasst, wenn der Patient im Census virtuell entlassen wird. | ||
| Warum das wichtig ist Formaler Abschluss des Patientenfalls für die Berechnung der Aufenthaltsdauer. Wichtig für die „Erkennung von Varianten im Patientenfluss“. Woher beziehen ADT Feed (Event A03) oder PAT_ENC_HSP.DISCH_TIME. Erfassung Wird protokolliert, wenn das Verwaltungspersonal den Entlassungs-Workflow abschließt. Ereignistyp explicit | |||
| Patient registriert | Zu Beginn des Behandlungsfalls wird der Patientenkontakt im System angelegt. Dieser Schritt wird erfasst, wenn ein Patient am Anmeldeschalter oder in der Notaufnahme eintrifft und im Epic EHR angemeldet wird. | ||
| Warum das wichtig ist Legt den Ausgangspunkt für den gesamten Patientenverlauf fest und ermöglicht die Berechnung der Gesamtaufenthaltsdauer. Wichtig für das Dashboard „Triage-Durchsatz und Wartezeiten“. Woher beziehen ADT Feed (Event A04 oder A01) oder Clarity-Tabelle PAT_ENC (Anlage von HSP_ACCOUNT_ID). Erfassung Wird protokolliert, wenn die Transaktion „Check In“ oder „Admit“ ausgeführt wird. Ereignistyp explicit | |||
| Triage abgeschlossen | Abschluss der ersten pflegerischen Untersuchung oder Triage-Einschätzung. Dieser Schritt wird üblicherweise erfasst, wenn das Triage-Flowsheet eingereicht oder der Triage-Status auf „Complete“ gesetzt wird. | ||
| Warum das wichtig ist Wichtig für das Dashboard „Triage-Durchsatz und Wartezeiten“, um die Effizienz der Aufnahme zu messen. Verzögerungen an dieser Stelle wirken sich auf den gesamten Behandlungspfad aus. Woher beziehen PAT_ENC_HSP.TRIAGE_END_TIME oder Timestamp der Einreichung einer bestimmten Flowsheet-Zeile (FLO_MEASUREMENT). Erfassung Wird protokolliert, wenn die Triage-Dokumentation unterzeichnet oder das Statusfeld aktualisiert wird. Ereignistyp explicit | |||
| Behandlungsplan begonnen | Zuweisung eines bestimmten klinischen Behandlungspfads oder Protokolls an den Patienten. Dieser Schritt wird erfasst, wenn ein standardisierter Order Set oder Care Plan dem Patientenfall zugeordnet wird. | ||
| Warum das wichtig ist Unterstützt die „Ansicht zur Einhaltung klinischer Protokolle“, indem die Absicht zur Einhaltung des Versorgungsstandards erfasst wird. Abweichungen von den anschließend geplanten Schritten lassen sich ab diesem Zeitpunkt messen. Woher beziehen ORDER_SET_BKG oder Care-Plan-Tabellen, die anzeigen, dass dem Patientenfall ein Protokoll zugeordnet wurde. Erfassung Wird protokolliert, wenn ein Arzt ein Order Set auswählt und unterzeichnet. Ereignistyp explicit | |||
| Diagnostischer Test angeordnet | Erfassung eines Auftrags für eine bildgebende Untersuchung (Radiologie) oder Laborleistung. Dieser Schritt wird erfasst, wenn ein Arzt im CPOE-System einen Auftrag eingibt und unterzeichnet. | ||
| Warum das wichtig ist Ausgangspunkt für das Dashboard „Zykluszeiten diagnostischer Leistungen“. Viele Aufträge ohne entsprechende Ergebnisse weisen auf Engpässe hin. Woher beziehen Tabelle ORDER_PROC, in der ORDER_TYPE den Wert Lab oder Imaging/Radiology hat. Erfassung Wird protokolliert, wenn der Auftragsstatus auf „Signed“ oder „Active“ wechselt. Ereignistyp explicit | |||
| Diagnostischer Test durchgeführt | Durchführung des diagnostischen Tests oder Einreichung 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. Woher beziehen ORDER_PROC.PROC_END_TIME oder ORDER_STAT_HISTORY, wenn der Status auf „Completed“ oder „Resulted“ wechselt. Erfassung Wird protokolliert, wenn ein Techniker die Aufgabe abschließt oder die Ergebnisschnittstelle Daten empfängt. Ereignistyp explicit | |||
| Entlassungsauftrag unterzeichnet | Formelle Genehmigung des Arztes, den Patienten aus dem Krankenhaus zu entlassen. Wird im Epic EHR als eigener Auftrag erfasst. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein bei der „Entlassungsplanung und -durchführung“. Die Zeit bis zur tatsächlichen Abreise zeigt administrative Verzögerungen. Woher beziehen ORDER_PROC mit dem Typ „Discharge Patient“. Erfassung Wird protokolliert, wenn der Arzt den Entlassungsauftrag unterzeichnet. Ereignistyp explicit | |||
| Entlassungsplanung begonnen | Beginn der Aktivitäten zur Vorbereitung der Entlassung des Patienten. Wird über die Dokumentation des Case Managements oder bestimmte Auftragsarten für „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 Aufenthaltsdauer. Woher beziehen Anlage von HSP_DISCH_PLAN oder erste Notiz durch Case Manager oder Sozialarbeiter. Erfassung Abgeleitet aus der ersten Interaktion mit dem Discharge Navigator oder einer Case-Mgmt-Notiz. Ereignistyp inferred | |||
| Konsultation abgeschlossen | Abschluss der fachärztlichen Untersuchung, üblicherweise gekennzeichnet durch die Unterzeichnung einer Consult Note oder den Abschluss des Konsultationsauftrags. | ||
| Warum das wichtig ist Endpunkt für „Wartezeit auf Facharztkonsultationen“. Zeigt an, dass die fachärztliche Einschätzung vorliegt und der Behandlungsplan fortgesetzt werden kann. Woher beziehen HNO_NOTE_TEXT (eingereichte Notiz vom Typ Consult) oder Statusänderung von ORDER_PROC auf Completed. Erfassung Abgeleitet aus dem Erstellungszeitpunkt der Consult Note oder der Aktualisierung des Auftragsstatus. Ereignistyp inferred | |||
| Konsultation angefordert | Auftrag an einen Facharzt, den Patienten zu untersuchen. Im Epic EHR wird dies als spezifischer Auftragstyp „Consult“ erfasst. | ||
| Warum das wichtig ist Ausgangspunkt für die KPI „Wartezeit auf Facharztkonsultationen“. Hilft, Engpässe in bestimmten medizinischen Fachrichtungen zu erkennen. Woher beziehen ORDER_PROC mit ORDER_CLASS = 'Consult' oder spezifische Überweisungsaufträge. Erfassung Wird protokolliert, wenn der Konsultationsauftrag unterzeichnet wird. Ereignistyp explicit | |||
| Medikament verabreicht | Eine Pflegekraft oder ein Leistungserbringer verabreicht dem Patienten ein Medikament. Dieser Schritt wird im Medication Administration Record (MAR) erfasst. | ||
| Warum das wichtig ist Zentrales Ereignis für das Dashboard „Leistung bei der Medikamentengabe“. Erfasst die Einhaltung des entwickelten Behandlungsplans. Woher beziehen Tabelle MAR_ADMIN_INFO, insbesondere Ereignisse mit der Aktion „Given“ oder „New Bag“. Erfassung Wird protokolliert, wenn eine Pflegekraft das Patientenarmband und das Medikament scannt (BCMA). Ereignistyp explicit | |||
| Nachsorgetermin vereinbart | Die Buchung eines zukünftigen ambulanten Termins für den Patienten. Der Termin wird im Terminplanungsmodul Cadence erfasst und mit der Patientenakte verknüpft. | ||
| Warum das wichtig ist Unterstützt die Kennzahl „Automatisierungsrate bei der Terminplanung für Folgetermine“. Sichert die Kontinuität der Versorgung und trägt dazu bei, Wiederaufnahmen zu vermeiden. Woher beziehen PAT_ENC_APPT, verknüpft mit der Patienten-ID und kurz vor der Entlassung erstellt. Erfassung Wird erfasst, sobald der Termin im Cadence-System bestätigt ist. Ereignistyp explicit | |||
| Patient verlegt | Physische Verlegung des Patienten in eine andere Abteilung oder auf eine andere Station. Wird über ADT-Verlegungsereignisse erfasst. | ||
| Warum das wichtig ist Endpunkt für die „Durchschnittliche Verlegungszeit zwischen Stationen“. Unterstützt die „Analyse interner Stationsverlegungen“, um Engpässe in der Krankenhauslogistik zu erkennen. Woher beziehen ADT Feed (Event A02) oder PAT_ENC_HSP_TRANSACTION (Transfer In). Erfassung Wird protokolliert, wenn ein Stationsmitarbeiter den Aufenthaltsort des Patienten im Census aktualisiert. Ereignistyp explicit | |||
| Verlegung angeordnet | Anforderung, den Patienten in eine andere Abteilung oder auf eine andere Versorgungsebene zu verlegen. Wird im System als „Bed Request“ oder „Transfer Order“ erfasst. | ||
| Warum das wichtig ist Ausgangspunkt für die „Durchschnittliche Verlegungszeit zwischen Stationen“. Unterscheidet zwischen der klinischen Entscheidung zur Verlegung und der logistischen Verfügbarkeit eines Bettes. Woher beziehen ADT_TRANSFER_ORDER oder ORDER_PROC (Bed Request). Erfassung Wird protokolliert, wenn ein Arzt einen Verlegungsauftrag eingibt. 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: Wählen Sie die Registerkarte Library und suchen Sie nach dem Template "Encounter Search" oder "Patient Encounters". Mit diesem Template können Details auf Kontaktebene abgerufen werden, die über die CSN (Contact Serial Number) identifiziert werden.
- Kriterien konfigurieren (Registerkarte Settings):
- Legen Sie den Datumsbereich fest (z. B. Entlassungsdatum = letzte 90 Tage), um abgeschlossene Episoden zu erfassen.
- Filtern Sie nach Begegnungstyp (z. B. „Hospital Encounter“, „Emergency“), um nicht relevante ambulante Besuche auszuschließen.
- Filtern Sie bei Bedarf nach Abteilung oder Einrichtung, um den Umfang einzugrenzen.
- Anzeigespalten konfigurieren (Registerkarte Display):
- Dies ist der entscheidende Schritt bei der Datenextraktion. Suchen Sie nach den passenden Spalten für die Zeitstempel der erforderlichen Aktivitäten und fügen Sie sie hinzu.
- Fügen Sie Patientenkennungen hinzu:
CSN(Patientenepisode),MRN(Patienten-ID). - Fügen Sie demografische Daten und Attribute hinzu:
Department,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 Query/Configuration.)
- 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).
- Aktivieren Sie die Option „Include Column Headers“.
- Speichern Sie die Datei unter
Raw_Epic_Extract.csv.
- Datentransformation (entscheidend):
- Beim Export aus der RWB entsteht ein „breiter“ Datensatz: eine Zeile pro Patientenepisode mit mehreren Timestamp-Spalten.
- Sie müssen diese Daten entpivotieren (umstrukturieren), damit jede Timestamp-Spalte als eigene Zeile im Event Log erscheint.
- Erstellen Sie eine Datei mit den Spalten
PatientEpisodeId,ActivityName,EventTimestampund den zugeordneten Attributen.
- Datumsformat festlegen: Achten Sie darauf, dass
EventTimestampim ISO-Format (YYYY-MM-DD HH:MM:SS) vorliegt, das mit ProcessMind kompatibel ist. - Abschließende Prüfung: Kontrollieren Sie, ob die Datei die Spaltenüberschriften
PatientEpisodeId,ActivityName,EventTimestampenthält, und laden Sie sie in ProcessMind hoch.
Konfiguration
- Template: Verwenden Sie je nach Epic-Version „Encounter Search“ (LBF) oder „Find Patients“.
- Datumsbereich: Begrenzen Sie den Zeitraum zunächst auf 3 bis 6 Monate, um Zeitüberschreitungen zu vermeiden. Die RWB ist nicht für umfangreiche Massendatenexporte ausgelegt.
- Zeilenbegrenzung: Für Epic RWB gilt häufig eine Zeilenbegrenzung (z. B. 25.000 oder 50.000 Zeilen). Achten Sie darauf, dass Ihr Datumsbereich diese Grenze nicht überschreitet, oder führen Sie den Export in mehreren Durchläufen aus.
- Berechtigungen: Erforderlich sind die Sicherheitsberechtigungen „Create“ und „Export“ für Reporting Workbench.
- Leistung: Führen Sie die Abfrage bei großen historischen Zeiträumen außerhalb der Hauptnutzungszeiten aus.
- Granularität: Diese Methode liefert zusammenfassende Zeitstempel auf Begegnungsebene (z. B. „First Med Admin“). Sie erfasst nicht jeden einzelnen Vorgang (z. B. jede verabreichte Tablette), sofern Sie keine speziellen „Audit“-Templates verwenden. Diese sind für diesen Anwendungsfall selten.
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
Datenbankzugriff anfordern: Stellen Sie sicher, dass Sie Lesezugriff auf die Epic Clarity Console oder einen SQL-Client haben, der mit der Clarity-Produktions- oder Reporting-Datenbank verbunden ist. Sie benötigen Berechtigungen für
PAT_ENC,ORDER_PROC,CLARITY_ADT,MAR_ADMIN_INFOund zugehörige Referenztabellen.Umfang und Filter-IDs festlegen: Führen Sie vor dem vollständigen Skript zunächst kurze Abfragen zur Ermittlung der spezifischen
ORDER_TYPE_C-Werte für Labore, Radiologie, Konsile und Verlegungen in Ihrer Epic-Instanz aus. Diese benutzerdefinierten Listen (Category Lists) unterscheiden sich je nach Krankenhaus.Zeitraum festlegen: Suchen Sie im bereitgestellten SQL-Skript nach den
WHERE-Klauseln, die nachCONTACT_DATEoderHOSP_ADMSN_TIMEfiltern. Passen Sie diese an den gewünschten Extraktionszeitraum an (z. B. die letzten 6 Monate).Benutzerdefinierte Flowsheets zuordnen (optional): Wenn Sie genaue Zeitstempel für Triage oder Entlassungsplanung benötigen, die nicht in der Haupttabelle für Begegnungen enthalten sind, ermitteln Sie die entsprechenden
FLO_MEAS_ID-Werte (Flowsheet Measure ID) und aktualisieren Sie die Platzhalterabschnitte im Skript.Abfrage ausführen: Führen Sie das vollständige SQL-Skript in Ihrem SQL-Client aus (z. B. 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, ob
EventTimestampnicht leer ist. Konvertieren Sie datenbankspezifische Datums- und Zeitformate in ISO 8601 (YYYY-MM-DDTHH:MM:SS), falls Ihre Middleware dies erfordert.Daten exportieren: Speichern Sie das Ergebnis als CSV-Datei. Achten Sie darauf, dass die Spaltenüberschriften den festgelegten Attributen entsprechen (PatientEpisodeId, ActivityName usw.).
In ProcessMind hochladen: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie
PatientEpisodeIdder Case-ID,ActivityNameder Aktivität undEventTimestampdem Timestamp zu.
Konfiguration
- Datenbankverbindung: Epic Clarity (in der Regel MSSQL- oder Oracle-Backend).
- Datumsfilter: Filtern Sie nach
PAT_ENC.HOSP_ADMSN_TIMEoderPAT_ENC.CONTACT_DATE. Für die erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um die Abfrageleistung zu steuern. - Begegnungstypen: Das Skript filtert stationäre und Notaufnahme-Begegnungen (
ENC_TYPE_C-Werte sind häufig 3 und 50; prüfen Sie dies anhand vonZC_ENC_TYPE). - Auftragstypen: Die
ORDER_TYPE_C-Werte für Labore, Bildgebung und Konsile müssen entsprechend der lokalen Konfiguration von ZC_ORDER_TYPE angepasst werden. - Leistung: Das Skript durchsucht umfangreiche Tabellen (
ORDER_PROC,CLARITY_ADT). Achten Sie auf geeignete Indizes oder führen Sie es außerhalb der Hauptnutzungszeiten aus.
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 Bereit für den Einstieg?
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 den Patientenpfad und verkürzen Sie die Zykluszeit noch heute
Ermitteln Sie klinische Engpässe, um die Zykluszeit um 30 % zu verkürzen.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.