> Kontinuierliche Prozessverbesserung > Patientenpfad > Veradigm (Allscripts) > Daten Template

Ihr Daten-Template für den Patientenpfad

Veradigm (Allscripts)

Attribute des Patientenpfads (19) Aktivitäten des Patientenpfads (13) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für den Patientenpfad

Dieses Template bietet einen strukturierten Ansatz, um die für die Analyse Ihres Patientenpfads erforderlichen Daten zu erfassen. Es beschreibt die wesentlichen Attribute und Aktivitäten, die Sie nachverfolgen sollten, und enthält praktische Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um Ihre Daten für ein umfassendes Process Mining vorzubereiten.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Aktivitäten für eine präzise Prozesserkennung
Praktische Hinweise zur Datenextraktion aus Ihrem System

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des Patientenpfads

Dies sind die empfohlenen Datenfelder für Ihr Event Log, um den Patientenpfad umfassend zu analysieren.

3 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das konkrete klinische oder administrative Ereignis, das durchgeführt wurde.
Beschreibung Beschreibt den ausgeführten Prozessschritt, etwa „Patient Registered“, „Medication Administered“ oder „Discharge Planning Initiated“. Dieses Attribut unterscheidet die verschiedenen Phasen der Patient Journey und ist für die Prozesserkennung und Variantenanalyse unverzichtbar. Warum das wichtig ist Definiert die Knoten in der Prozesslandkarte. Ohne dieses Attribut lässt sich kein Prozessfluss visualisieren. Bezugsquelle Abgeleitet aus verschiedenen Transaktionstabellen: ADT-Ereignisse, Orders, Results und Tabellen der klinischen Dokumentation. Beispiele Patient registriertDiagnostischer Test angeordnetMedikament verabreichtPatient entlassen
	Ereignis-Timestamp EventDateTime	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Erfasst den chronologischen Zeitpunkt der Aktivität. Dies ist entscheidend für die Berechnung von Durchlaufzeiten und Dauern sowie für die korrekte Anordnung der Ereignisse. Bei Gesundheitsdaten ist eine Genauigkeit bis auf die Minute für eine präzise Durchsatzanalyse besonders wichtig. Warum das wichtig ist Ermöglicht die Berechnung aller zeitbezogenen KPIs, einschließlich der durchschnittlichen Durchlaufzeit der Patient Journey und der Wartezeiten. Bezugsquelle Transaktions-Timestamps in Quelltabellen, beispielsweise ADT_DATE, ORDER_DATE und RESULT_DATE. Beispiele 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Patientenepisode PatientEpisodeId	Eindeutige Kennung für den jeweiligen Patientenbesuch oder Patientenkontakt.
Beschreibung Die Patientenepisode dient als primäre Case-ID und fasst alle Ereignisse zusammen, die zur spezifischen medizinischen Versorgung eines Patienten für eine bestimmte Erkrankung oder einen bestimmten Zeitraum gehören. Dadurch entsteht eine integrierte Sicht auf Diagnose, Behandlung und Genesung, in der Interaktionen verschiedener Abteilungen zu einem zusammenhängenden Ablauf verknüpft werden. In Veradigm-(Allscripts-)Systemen wie Sunrise oder Paragon entspricht dies in der Regel der Visit ID oder Encounter Number. Warum das wichtig ist Sie ist der grundlegende Schlüssel für Process Mining und ermöglicht die Rekonstruktion der Patient Journey von Anfang bis Ende. Bezugsquelle Wahrscheinlich im Kopfbereich der Visit- oder Encounter-Tabellen zu finden, beispielsweise als VISIT_ID oder ENCOUNTER_ID. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele EP-2023-998877VIS-10029384100029384ENC-554433
	Aufnahmedatum AdmissionDate	Das Datum und die Uhrzeit, zu denen der Patient formell aufgenommen wurde.
Beschreibung Der Timestamp, der den Beginn des stationären Aufenthalts markiert. Zusammen mit dem Entlassungsdatum wird er zur Berechnung der Aufenthaltsdauer (ALOS) verwendet. Warum das wichtig ist Zentraler Bezugspunkt für die ALOS-Berechnung und die Messung von Verzögerungen bei der Aufnahme. Bezugsquelle Kopftabelle für Visit oder Encounter, beispielsweise mit ADMIT_DATE. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Behandelnder Leistungserbringer AttendingProvider	Der primäre klinische Leistungserbringer, der während des Ereignisses für den Patienten verantwortlich ist.
Beschreibung Identifiziert den Arzt, die Pflegekraft oder den Spezialisten, der die Aktivität durchführt oder für den Versorgungsplan verantwortlich ist. Die Analyse dieses Attributs hilft, die „Clinical Resource Utilization“ und Unterschiede in den Behandlungspfaden einzelner Ärzte zu verstehen. Warum das wichtig ist Ermöglicht die Analyse von Ressourcenengpässen und den Leistungsvergleich zwischen klinischen Mitarbeitenden. Bezugsquelle Transaktionstabellen, beispielsweise ORDERing_PROVIDER und ATTENDING_PHYSICIAN_ID. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele Dr. Sarah SmithNurse Practitioner JonesRadiology Tech A
	Entlassungsart DischargeDisposition	Der Status oder Aufenthaltsort des Patienten bei der Entlassung.
Beschreibung Gibt an, wohin der Patient nach dem Krankenhausaufenthalt gegangen ist, beispielsweise nach Hause, in eine qualifizierte Pflegeeinrichtung, verstorben oder verlegt. Dies ist für die Analyse von Wiederaufnahmerisiken wichtig, da verschiedene Entlassungsarten mit unterschiedlichen Risikoprofilen verbunden sind. Warum das wichtig ist Ordnet das Dashboard zur „Discharge Planning“ ein und hilft, Abweichungen bei der ALOS zu erklären. Bezugsquelle Kopftabelle für Visit oder Encounter, beispielsweise mit DISCH_DISP. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele Nach HauseIn eine SNF verlegtNach Hause mit häuslicher PflegeAuf eigenen Wunsch entgegen ärztlichem Rat entlassen
	Entlassungsdatum DischargeDate	Das Datum und die Uhrzeit, zu denen der Patient entlassen wurde.
Beschreibung Der Timestamp, der das Ende der Episode markiert. Er wird verwendet, um den Case im Process Mining zu schließen, und ist für die Berechnung von ALOS und Wiederaufnahmen unverzichtbar. Warum das wichtig ist Definiert das Ende des Prozesszyklus und ist für die Durchsatzanalyse entscheidend. Bezugsquelle Kopftabelle für Visit oder Encounter, beispielsweise mit DISCH_DATE. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Name der Abteilung DepartmentName	Die Station oder Abteilung des Krankenhauses, in der die Aktivität stattgefunden hat.
Beschreibung Gibt den Standortkontext an, beispielsweise „Emergency Room“, „Cardiology“ oder „Radiology“. Dies ist für die „Admission & Transfer Bottleneck Analysis“ entscheidend, um zu erkennen, an welchen Stellen Patienten bei der Verlegung zwischen Stationen aufgehalten werden. Warum das wichtig ist Unterstützt die Analyse der Ressourcennutzung und die Identifizierung von Engpässen in Abteilungen. Bezugsquelle Mit der Transaktion verknüpfte Stammtabellen zu Standorten oder Abteilungen. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele NotaufnahmeICUAllgemeinchirurgieRadiologie
	Patienten-MRN PatientMrn	Medical Record Number zur eindeutigen Identifizierung des Patienten über mehrere Episoden hinweg.
Beschreibung Die Medical Record Number (MRN) oder Enterprise Patient ID. Anders als die ID der Patientenepisode bleibt diese ID über verschiedene Besuche hinweg für den Patienten konstant. Sie ist der entscheidende Schlüssel, um separate Episoden zu verknüpfen und Wiederaufnahmeraten zu berechnen. Warum das wichtig ist Unverzichtbar für die „30-Day Readmission Rate“ und die Identifizierung wiederkehrender Patienten. Bezugsquelle Patientenstammdatenindex oder demografische Tabellen, wahrscheinlich mit den Spalten MRN und PATIENT_ID. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele MRN-884422P-10022399887766
	Primärer Diagnosecode PrimaryDiagnosisCode	Der ICD-10- oder SNOMED-Code, der die Hauptdiagnose repräsentiert.
Beschreibung Der codierte Grund für den Besuch des Patienten. Dieses Attribut dient als Filter für den „Treatment Pathway Variation Explorer“. Damit können Analysten vergleichen, wie verschiedene Erkrankungen, etwa Pneumonie und Herzinsuffizienz, das System durchlaufen. Warum das wichtig ist Erforderlich, um Prozesse nach klinischer Erkrankung zu segmentieren und die Einhaltung von Protokollen zu prüfen. Bezugsquelle Tabellen zu Diagnosen oder Problemlisten, typischerweise mit ICD-10-Spalten. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele I50.9J18.9E11.9
	Wiederaufnahme IsReadmission	Kennzeichen dafür, ob es sich bei diesem Fall innerhalb von 30 Tagen um eine Wiederaufnahme handelt.
Beschreibung Ein berechnetes boolesches Attribut. Es gibt true zurück, wenn der Patient innerhalb von 30 Tagen vor dem aktuellen Aufnahmedatum bereits entlassen wurde. Dieses Attribut steuert den „Monitor für vermeidbare Wiederaufnahmen“. Warum das wichtig ist Zentraler KPI für die Qualität und Vergütung im Krankenhaus, insbesondere im Rahmen der CMS-Vorgaben. Bezugsquelle Wird in der ETL- beziehungsweise Datentransformationsschicht anhand von PatientMRN sowie Aufnahme- und Entlassungsdaten berechnet. Beispiele truefalse
	Datum des Nachsorgetermins FollowUpAppointmentDate	Datum des geplanten Nachsorgetermins.
Beschreibung Wird zur Berechnung der „Rate geplanter Nachsorgetermine“ verwendet. Ist dieses Feld ausgefüllt, wurde eine Nachsorge geplant. Ist es null oder leer, wurde keine Nachsorge geplant. Warum das wichtig ist Misst direkt den KPI „Compliance in der Nachsorge“. Bezugsquelle Terminplanungssystem oder Tabelle mit zukünftigen, dem Patienten zugeordneten Terminen. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-11-15T14:00:00Znull
	Durchlaufzeit der Diagnostik DiagnosticTurnaroundTime	Zeitspanne zwischen der Anforderung eines Tests und dem Eingang des Testergebnisses.
Beschreibung Berechnete Dauer zwischen „Diagnostiktest angefordert“ und „Diagnose bestätigt“ beziehungsweise dem Eingang des Ergebnisses. Wird für die „Übersicht der diagnostischen Durchlaufzeiten“ verwendet. Warum das wichtig ist Lange Durchlaufzeiten verlängern die Verweildauer. Diese Kennzahl macht Verzögerungen in Labor und Radiologie sichtbar. Bezugsquelle Berechnung: Timestamp(Ergebnis) - Timestamp(Anforderung). Beispiele 2 Stunden45 Minuten1,5 Tage
	Kostenstelle CostCenter	Der finanzielle Code, der der Abteilung oder Leistung zugeordnet ist.
Beschreibung Ordnet die klinische Aktivität einer finanziellen Einheit zu. Dadurch lässt sich die „Aktivitätskosten“ oder die generische finanzielle Leistung verschiedener Abteilungen analysieren. Warum das wichtig ist Verknüpft operatives Process Mining mit den finanziellen Auswirkungen. Bezugsquelle Tabellen für Abteilungen oder den Charge Master. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele CC-1020CC-Rad-01Emergency-001
	Letzte Datenaktualisierung LastDataUpdate	Timestamp der letzten Extraktion oder Aktualisierung des Datensatzes.
Beschreibung Zeigt an, wie aktuell die für die Analyse verwendeten Daten sind. Dieses Feld hilft Benutzern zu erkennen, ob sie Echtzeitdaten oder eine Momentaufnahme aus einem früheren Zeitraum betrachten. Warum das wichtig ist Sorgt für Transparenz hinsichtlich der Datenlatenz und unterstützt Strategien für das inkrementelle Laden von Daten. Bezugsquelle Vom System während des ETL- oder Extraktionslaufs generierter Timestamp. Beispiele 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Medikamentenname MedicationName	Der Name des angeordneten oder verabreichten Medikaments.
Beschreibung Wird speziell für das Dashboard zu „Medication Administration Time Gaps“ verwendet. Damit lässt sich erkennen, ob sich bei bestimmten Medikamenten, etwa Antibiotika oder Schmerzmitteln, Verzögerungen bei der Verabreichung ergeben. Warum das wichtig ist Entscheidend für die Analyse der klinischen Sicherheit und die Optimierung von Apothekenprozessen. Bezugsquelle Medikationsverabreichungsprotokoll (MAR) oder Apothekenbestellungen. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele AmoxicillinHeparinMorphinsulfat
	Order-ID OrderId	Kennung für bestimmte Orders, etwa Laboruntersuchungen, Medikamente oder Prozeduren.
Beschreibung Verknüpft das Ereignis „Order“ mit dem Ereignis „Result“ oder „Administration“. So lässt sich beispielsweise „Diagnostic Test Ordered“ mit „Diagnostic Test Completed“ verbinden. Diese Granularität ist für das Dashboard zur „Diagnostic Turnaround Time“ erforderlich. Warum das wichtig ist Ermöglicht die Berechnung der Dauer einzelner Prozessschritte, beispielsweise der Labor-Durchlaufzeit. Bezugsquelle Tabellen zur Eingabe von Orders, beispielsweise ORDER_ID und PLACER_ORDER_NUM. Ziehen Sie die Dokumentation von Veradigm (Allscripts) hinzu. Beispiele ORD-998877LAB-112233RX-445566
	Protokollkonform IsProtocolCompliant	Kennzeichen dafür, ob der Fall dem standardmäßigen Behandlungspfad gefolgt ist.
Beschreibung Ein berechnetes Attribut, das prüft, ob bestimmte verpflichtende Aktivitäten, beispielsweise „Vitalwerte erfasst“ vor „Medikament verabreicht“, in der richtigen Reihenfolge stattgefunden haben. Unterstützt das „Dashboard zur Einhaltung des Behandlungspfads“. Warum das wichtig ist Automatisiert die Erkennung von Abweichungen von Vorgaben, ohne dass eine manuelle Prüfung der Patientenakte erforderlich ist. Bezugsquelle Wird im Process-Mining-Tool oder per ETL auf Grundlage der Aktivitätsreihenfolge berechnet. Beispiele truefalse
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Identifiziert die Softwareinstanz, die die Daten bereitstellt, beispielsweise „Veradigm Sunrise“ oder „Veradigm TouchWorks“. Dies ist besonders in Umgebungen mit mehreren Krankenhäusern oder bei der Zusammenführung von Daten aus stationären und ambulanten Bereichen wichtig. Warum das wichtig ist Sorgt für Rückverfolgbarkeit und Data Lineage und ist hilfreich bei der Analyse von Problemen mit der Datenqualität. Bezugsquelle Während des ETL-Prozesses fest hinterlegt oder aus Metadatentabellen des Systems extrahiert. Beispiele Veradigm SunriseAllscripts PMVeradigm TouchWorks

Erforderlich Empfohlen Optional

Aktivitäten des Patientenpfads

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung des Patientenpfads in Ihrem Event Log erfassen sollten.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Behandlungsplan erstellt	Bezeichnet die formale Festlegung des Behandlungsplans durch das klinische Team. Dieses Ereignis wird häufig erfasst, wenn ein Dokument wie „Plan of Care“ oder eine Gruppe initialer Behandlungsanordnungen im EHR erstellt und signiert wird.
Warum das wichtig ist Dieser Meilenstein leitet die aktive Behandlungsphase ein. Er bildet die Grundlage für die Messung der Einhaltung von Versorgungsprotokollen und der Zeit bis zur ersten Behandlung, etwa der Verabreichung eines Medikaments. Bezugsquelle Abgeleitet aus dem Signatur-Timestamp eines „Plan of Care“-Formulars oder dem Erstellungs-Timestamp der ersten größeren Gruppe therapeutischer Anordnungen nach der Diagnose. Erfassen Ermitteln Sie den Timestamp, an dem ein „Plan of Care“-Dokument durch den behandelnden Arzt finalisiert oder signiert wird. Ereignistyp inferred
	Diagnose bestätigt	Diese Aktivität zeigt an, dass ein Arzt eine Diagnose offiziell in der Patientenakte dokumentiert hat. Dies kann erfasst werden, wenn ein Diagnosecode zur Problemliste hinzugefügt oder eine klinische Notiz mit der Diagnose signiert wird.
Warum das wichtig ist Die Bestätigung der Diagnose ist ein entscheidender Wendepunkt, der den weiteren Behandlungspfad bestimmt. Sie ermöglicht die Analyse unterschiedlicher Behandlungspfade auf Grundlage verschiedener Diagnosen. Bezugsquelle Zu finden in der Problemliste des Patienten, in den Diagnosedatensätzen des Patientenkontakts oder in der klinischen Dokumentation. Das Ereignis kann aus dem Timestamp abgeleitet werden, an dem ein primärer Diagnosecode für den Patientenkontakt eingegeben und finalisiert wird. Erfassen Verwenden Sie den Erstellungs- oder Aktualisierungs-Timestamp des primären Diagnoseeintrags für die betreffende Patientenepisode. Ereignistyp inferred
	Entlassungsplanung eingeleitet	Bezeichnet den formalen Beginn der Entlassungsplanung für einen Patienten. Das Ereignis kann aus der Erstellung eines Dokuments zur Entlassungsplanung, der Eingabe einer Entlassungsanordnung oder dem Abschluss einer speziellen Einschätzung zur Entlassungsplanung abgeleitet werden.
Warum das wichtig ist Diese Aktivität ist der Ausgangspunkt für die Messung der Effizienz des Entlassungsprozesses. Ein früher Beginn der Planung steht häufig mit niedrigeren Wiederaufnahmeraten in Zusammenhang. Bezugsquelle Abgeleitet aus dem Erstellungs-Timestamp einer Notiz zur Entlassungsplanung, eines Entlassungs-Order-Sets oder eines speziellen Bewertungsformulars in Veradigm. Erfassen Identifizieren Sie den Timestamp, an dem erstmals eine entlassungsspezifische Anordnung oder ein entsprechendes Dokument für den Patientenkontakt erstellt wird. Ereignistyp inferred
	Ersteinschätzung abgeschlossen	Bezeichnet den Abschluss der ersten klinischen Untersuchung durch eine Pflegekraft oder einen Arzt, beispielsweise der Triage oder der Erstaufnahme. Dieses Ereignis wird häufig erfasst, wenn ein bestimmtes klinisches Formular oder eine Notiz, etwa eine „Nursing Initial Assessment“, im EHR signiert und finalisiert wird.
Warum das wichtig ist Diese Aktivität ist ein wichtiger früher Meilenstein. Die Zeit zwischen Registrierung und dieser Einschätzung macht mögliche Verzögerungen bei der Patientenaufnahme und der initialen Versorgung sichtbar. Bezugsquelle Abgeleitet aus dem Finalisierungs- oder Signatur-Timestamp von Formularen oder klinischen Notizen zur Ersteinschätzung in den Modulen für klinische Dokumentation von Veradigm. Erfassen Identifizieren Sie den Timestamp, an dem der Status der Notiz oder des Formulars zur Ersteinschätzung auf „completed“ oder „signed“ geändert wird. Ereignistyp inferred
	Patient entlassen	Kennzeichnet das offizielle Ende der stationären Episode, wenn der Patient formell aus der Einrichtung entlassen wird. Dies ist ein ausdrückliches, zentrales Ereignis im ADT-System, das den Status des Patientenkontakts auf „discharged“ aktualisiert.
Warum das wichtig ist Dies ist die zentrale Endaktivität der meisten Patient Journeys. Sie ist entscheidend für die Berechnung der durchschnittlichen Aufenthaltsdauer (ALOS) und der gesamten Prozessdurchlaufzeit. Bezugsquelle Wird ausdrücklich im ADT-Modul protokolliert. Der Datensatz des Patientenkontakts enthält einen Entlassungs-Timestamp und die Entlassungsart. Erfassen Verwenden Sie den Entlassungs-Timestamp aus dem Hauptdatensatz des Patientenkontakts oder Besuchs. Ereignistyp explicit
	Patient registriert	Kennzeichnet den offiziellen Beginn der Patientenepisode, sobald die Patienteninformationen in das Veradigm-System eingegeben wurden. Dieses Ereignis wird in der Regel ausdrücklich erfasst, wenn ein Benutzer den Registrierungs-Workflow abschließt und einen neuen Datensatz für den Patientenkontakt mit eindeutiger Kennung und Timestamp anlegt.
Warum das wichtig ist Dies ist die zentrale Startaktivität der Patient Journey. Sie ist entscheidend für die Berechnung der gesamten Prozessdurchlaufzeit, der Aufenthaltsdauer und des Patientendurchsatzes. Bezugsquelle Dieses Ereignis wird im Modul für die Patientenregistrierung oder im ADT-Modul (Admission, Discharge, Transfer) erfasst. Suchen Sie nach dem Erstellungs-Timestamp des Patientenkontakts oder Besuchsdatensatzes. Erfassen Timestamp aus der Tabelle für Patientenkontakte oder Registrierungen bei der Erstellung des Datensatzes. Ereignistyp explicit
	Diagnostischer Test abgeschlossen	Bezeichnet den Zeitpunkt, an dem die Ergebnisse eines diagnostischen Tests finalisiert und in der Patientenakte verfügbar sind. Dies wird in der Regel aus einer Statusänderung der ursprünglichen Anordnung von „active“ oder „in-progress“ zu „completed“ oder „resulted“ abgeleitet.
Warum das wichtig ist Diese Aktivität ist ein entscheidender Meilenstein für die Messung diagnostischer Durchlaufzeiten. Verzögerungen zwischen Anordnung und Abschluss können die Zeit bis zur Diagnose erheblich verlängern. Bezugsquelle Abgeleitet aus dem Statusfeld der Anordnung im Order-Modul oder aus Timestamps im zugehörigen Ergebnis-Modul, etwa LIS oder RIS. Erfassen Identifizieren Sie den Timestamp, an dem sich der Status der Anordnung in einen Endstatus wie „Completed“ oder „Resulted“ ändert. Ereignistyp inferred
	Diagnostischer Test angeordnet	Dieses Ereignis tritt ein, wenn ein Arzt einen diagnostischen Test wie eine Laboruntersuchung oder eine bildgebende Untersuchung anordnet. Es wird ausdrücklich über das Computerized Physician Order Entry (CPOE)-System in Veradigm erfasst.
Warum das wichtig ist Dies markiert den Beginn des diagnostischen Teilprozesses. Es ist der Ausgangspunkt für die Messung diagnostischer Durchlaufzeiten und die Identifizierung von Verzögerungen bei der Anordnung. Bezugsquelle Erfasst in den Protokollen des Order-Moduls oder des CPOE-Systems. Jede Anordnung enthält einen Timestamp, der den Zeitpunkt der Eingabe angibt. Erfassen Extrahieren Sie den Erstellungs-Timestamp aus den Order-Datensätzen der relevanten diagnostischen Tests. Ereignistyp explicit
	Medikament verabreicht	Dieses Ereignis wird erfasst, wenn eine Pflegekraft oder ein Arzt die Verabreichung eines Medikaments an den Patienten dokumentiert. Die Erfassung erfolgt im Medication Administration Record (MAR) oder im eMAR-Modul, das den genauen Verabreichungszeitpunkt protokolliert.
Warum das wichtig ist Die Erfassung der Medikamentenverabreichung ist wichtig, um die Rechtzeitigkeit und die Einhaltung der Behandlung zu analysieren. Die Zeitspanne zwischen Anordnung und Verabreichung macht Verzögerungen bei der Medikamentenversorgung sichtbar. Bezugsquelle Wird ausdrücklich im eMAR-Modul (electronic Medication Administration Record) protokolliert. Jedes Verabreichungsereignis enthält einen spezifischen Timestamp, das Medikament und die Dosierung. Erfassen Extrahieren Sie die Timestamps aus der eMAR-Tabelle für jedes Verabreichungsereignis, das mit dem Patientenkontakt verknüpft ist. Ereignistyp explicit
	Nachsorge terminiert	Diese Aktivität bezeichnet die Terminierung eines Nachsorgetermins für den Patienten nach der Entlassung. Das Ereignis wird im Terminplanungsmodul erfasst, sobald ein Termin gebucht und mit dem entlassenen Patientenkontakt verknüpft wird.
Warum das wichtig ist Die Terminierung der Nachsorge ist entscheidend für die Kontinuität der Versorgung und die Verringerung von Wiederaufnahmen. Diese Aktivität hilft dabei, die Einhaltung von Protokollen nach der Entlassung zu messen. Bezugsquelle Erfasst im Terminplanungsmodul. Suchen Sie nach dem Erstellungs-Timestamp eines neuen Patiententermins, der nach dem Entlassungsdatum stattfindet. Erfassen Identifizieren Sie den Erstellungs-Timestamp eines mit dem Patienten verknüpften Termindatensatzes im Terminplanungssystem. Ereignistyp explicit
	Prozedur durchgeführt	Bezeichnet den Abschluss eines klinischen oder chirurgischen Eingriffs. Dieses Ereignis wird in der Regel erfasst, wenn ein Arzt die Prozedurnotiz signiert oder der Status der Prozedur-Anordnung im System auf „completed“ gesetzt wird.
Warum das wichtig ist Prozeduren sind in vielen Patient Journeys wichtige Meilensteine. Die Analyse ihrer Zeitpunkte hilft dabei, die Ressourcennutzung und die Effizienz der Terminplanung zu verstehen. Bezugsquelle Abgeleitet aus dem Signatur-Timestamp einer Prozedurnotiz im Modul für klinische Dokumentation oder dem Abschluss-Timestamp der entsprechenden Prozedur-Anordnung im Order-Modul. Erfassen Verwenden Sie den Abschluss-Timestamp der Prozedur-Anordnung oder den Signatur-Timestamp der zugehörigen Prozedurdokumentation. Ereignistyp inferred
	Verlegung in eine Abteilung	Dieses Ereignis kennzeichnet die physische Verlegung eines Patienten von einer Abteilung oder Versorgungseinheit in eine andere, beispielsweise von der Notaufnahme auf eine Normalstation. Es wird vom ADT-System (Admission, Discharge, Transfer) in Veradigm erfasst.
Warum das wichtig ist Patientenverlegungen sind häufige Ursachen für Engpässe und Verzögerungen. Die Analyse von Dauer und Häufigkeit der Verlegungen hilft, den Patientenfluss und die Ressourcenverteilung zwischen Abteilungen zu optimieren. Bezugsquelle Wird ausdrücklich im ADT-Modul protokolliert. Jedes Verlegungsereignis enthält den Patienten, die Ausgangs- und Zielstation sowie einen Timestamp. Erfassen Extrahieren Sie die Event Logs aus dem ADT-System, die den Bewegungen der Patienten entsprechen. Ereignistyp explicit
	Vitalwerte erfasst	Diese Aktivität tritt jedes Mal auf, wenn die Vitalwerte eines Patienten wie Herzfrequenz, Blutdruck und Temperatur erfasst werden. Es handelt sich um ein ausdrückliches Ereignis im Bereich für klinische Dokumentation oder im speziellen Flowsheet-Bereich des EHR.
Warum das wichtig ist Die regelmäßige Erfassung von Vitalwerten weist auf eine aktive Patientenüberwachung hin. Häufigkeit und Zeitpunkt lassen sich analysieren, um die Einhaltung von Überwachungsprotokollen zu prüfen. Bezugsquelle Erfasst im klinischen Daten-Repository oder in Flowsheet-Tabellen, in denen Vitalwerte gespeichert werden. Jeder Eintrag enthält einen Timestamp. Erfassen Extrahieren Sie die Timestamps aus den Flowsheet-Daten zu den Vitalwerten für den Patientenkontakt. Ereignistyp explicit

Anleitungen zur Datenextraktion

So extrahieren Sie Ihre Daten aus Veradigm (Allscripts)

Schritte

Zielkanal der Schnittstelle identifizieren: Melden Sie sich an der Allscripts Interface Engine (AIE) Management Console an. Suchen Sie den primären Schnittstellenkanal, der eingehende Nachrichten aus dem EHR verarbeitet, meist mit der Bezeichnung „EHR_Inbound“ oder ähnlich. Stellen Sie sicher, dass dieser Kanal die Nachrichtentypen ADT, SIU, ORM, ORU, RAS und DFT verarbeitet, damit der gesamte Patientenpfad erfasst wird.
Neuen Passthrough-/Exportkanal erstellen: Erstellen Sie einen neuen Zielkanal mit dem Namen „ProcessMining_Export“. Legen Sie den Ausgabetyp auf „File Writer“ fest. Dieser Kanal empfängt eine Kopie der Nachrichten aus dem Quellkanal und wandelt sie für ProcessMind in ein Flatfile-Format (CSV) um.
Nachrichtenrouting konfigurieren: Richten Sie in den AIE-Routingregeln eine Kopier- beziehungsweise Routingregel ein, die Nachrichten vom primären EHR-Kanal an den neuen Kanal „ProcessMining_Export“ sendet. Beschränken Sie das Routing auf die erforderlichen Nachrichtentypen: ADT (Registrierung/Verlegung), SIU (Terminplanung), ORM (Anforderungen), ORU (Ergebnisse/Vitalwerte), RAS (Medikamente) und DFT (Abrechnung/Prozeduren).
Transformationslogik definieren: Öffnen Sie im Kanal „ProcessMining_Export“ den Editor für Transformationen und Skripte. Implementieren Sie ein Parsing-Skript, siehe Abschnitt „query“ weiter unten, das die rohen HL7-Segmente liest und bestimmte Trigger Events sowie Statuscodes auf die erforderlichen Standard-Aktivitätsnamen abbildet, beispielsweise „ADT^A01“ auf „Patient registriert“.
Attribute HL7-Feldern zuordnen: Stellen Sie sicher, dass das Skript „PatientEpisodeId“ aus dem Segment PV1-19 (Visit Number) und „PatientMrn“ aus PID-3 extrahiert. Ordnen Sie „EventDateTime“ dem Feld MSH-7 oder EVN-2 zu. Extrahieren Sie klinische Details wie „DepartmentName“ aus PV1-3 und „AttendingProvider“ aus PV1-7.
Parameter für Ausgabedateien festlegen: Konfigurieren Sie die Einstellungen des File Writer. Legen Sie als Ausgabeverzeichnis einen sicheren Netzwerkpfad fest. Definieren Sie die Dateinamenskonvention, beispielsweise EventLog_YYYYMMDD_HH.csv. Stellen Sie den Dateimodus auf „Append“, damit fortlaufend Zeilen zum Log hinzugefügt werden.
Trennzeichen und Maskierung behandeln: Stellen Sie im Skript sicher, dass Textfelder wie Diagnose oder Abteilungsname bereinigt werden. Entfernen Sie Kommas und Zeilenumbrüche, damit die CSV-Struktur erhalten bleibt.
Aktivieren und testen: Starten Sie den Kanal „ProcessMining_Export“. Lösen Sie in der Veradigm-Testumgebung ein Testereignis aus, beispielsweise durch die Registrierung eines Testpatienten. Prüfen Sie, ob eine neue Zeile mit dem korrekten Aktivitätsnamen und Timestamp in der CSV-Datei erscheint.
Log-Rotation konfigurieren: Richten Sie einen Rotationsplan ein, beispielsweise täglich um Mitternacht, damit die aktuelle CSV-Datei geschlossen und eine neue begonnen wird. So bleiben die Dateien für den Upload handhabbar.
Historische Daten erneut verarbeiten (optional): Verwenden Sie den „Message Browser“ oder das Tool „Log Replay“ der AIE, um archivierte HL7-Logs der vergangenen drei bis sechs Monate über den Kanal „ProcessMining_Export“ erneut zu senden. Überwachen Sie die Systemleistung, um Verzögerungen zu vermeiden.
Abrufen und formatieren: Öffnen Sie das Ausgabeverzeichnis, rufen Sie die erzeugten CSV-Dateien ab und prüfen Sie, ob die Kopfzeilen den Anforderungen entsprechen. Führen Sie die Tagesdateien bei Bedarf zusammen.
In ProcessMind hochladen: Importieren Sie den finalen Datensatz in ProcessMind. Ordnen Sie „PatientEpisodeId“ der Case-ID, „ActivityName“ der Aktivität und „EventDateTime“ dem Timestamp zu.

Konfiguration

Kanaltyp: File Writer / Dateisystemausgabe
Trigger Events: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
Dateikodierung: UTF-8, entscheidend für Sonderzeichen in Namen und Diagnosen
Trennzeichen: Komma (,) oder Pipe (|)
Datumsformat: ISO 8601 (YYYY-MM-DDTHH:MM:SS), empfohlen für die Umwandlung von HL7-Timestamps
Log-Rotation: Täglich oder sobald die Dateigröße 100 MB überschreitet
Schreibmodus: Append, nicht überschreiben
Leistung: Stellen Sie sicher, dass das Transformationsskript schlank bleibt, damit sich in der Engine keine Nachrichtenwarteschlange oder Rückstände bilden.

a Beispielabfrage config

// AIE Transformation Script (Pseudo-code for Config)
// Objective: Parse HL7 message and append line to CSV
// Output Columns: PatientEpisodeId, ActivityName, EventDateTime, PatientMrn, AttendingProvider, DepartmentName, PrimaryDiagnosisCode

// 1. Initialize Variables
var msgType = HL7.GetField("MSH-9-1") + "^" + HL7.GetField("MSH-9-2");
var visitNumber = HL7.GetField("PV1-19");
var mrn = HL7.GetField("PID-3");
var eventTime = HL7.GetField("MSH-7"); // Or EVN-2
var provider = HL7.GetField("PV1-7");
var dept = HL7.GetField("PV1-3");
var diagnosis = HL7.GetField("DG1-3"); // For Diagnosis events
var orderStatus = HL7.GetField("ORC-5");
var resultStatus = HL7.GetField("OBR-25");
var activityName = "";

// 2. Map Message Types to Activities
// Registration & Admission
if (msgType == "ADT^A04" || msgType == "ADT^A01") {
    activityName = "Patient Registered";
}
else if (msgType == "ADT^A02") {
    activityName = "Transfer to Department";
}
else if (msgType == "ADT^A03") {
    activityName = "Patient Discharged";
}
// Scheduling
else if (msgType == "SIU^S12") {
    activityName = "Follow-up Scheduled";
}
// Orders (Diagnostics, Care Plans, Discharge Planning)
else if (msgType == "ORM^O01") {
    var orderControl = HL7.GetField("ORC-1");
    var orderType = HL7.GetField("OBR-4"); // Check for specific service codes
    
    if (orderControl == "NW") { // New Order
        if (orderType.Contains("LAB") || orderType.Contains("RAD")) {
            activityName = "Diagnostic Test Ordered";
        }
        else if (orderType.Contains("DISCHARGE")) {
            activityName = "Discharge Planning Initiated";
        }
        else if (orderType.Contains("CARE_PLAN")) {
            activityName = "Treatment Plan Created";
        }
    }
}
// Results & Vitals
else if (msgType == "ORU^R01") {
    // Check if it is Vitals or Lab Result based on OBX codes or sending app
    var observationId = HL7.GetField("OBX-3"); 
    if (observationId.Contains("VITALS")) {
        activityName = "Vitals Recorded";
    } else {
        if (resultStatus == "F" || resultStatus == "C") {
            activityName = "Diagnostic Test Completed";
        }
    }
    
    // Initial Assessment Check (often a specific doc type in ORU or MDM)
    if (observationId.Contains("INITIAL_ASSESS")) {
        activityName = "Initial Assessment Completed";
    }
}
// Medication Administration (RAS)
else if (msgType == "RAS^O17") {
    activityName = "Medication Administered";
}
// Billing/Procedures (DFT)
else if (msgType == "DFT^P03") {
    activityName = "Procedure Performed";
}
// Diagnosis Updates (Often in ADT or DFT, logic depends on config)
else if (msgType == "ADT^A08" && diagnosis != "") {
    // Check if diagnosis segment is new/updated
    activityName = "Diagnosis Confirmed";
}

// 3. Write to File if Activity Identified
if (activityName != "" && visitNumber != "") {
    // Format Date to ISO
    var formattedDate = FormatDate(eventTime, "yyyy-MM-dd HH:mm:ss");
    
    // Construct CSV Line
    var csvLine = visitNumber + "," + 
                  activityName + "," + 
                  formattedDate + "," + 
                  mrn + "," + 
                  provider + "," + 
                  dept + "," + 
                  diagnosis;
                  
    File.WriteLine("[Configured_Output_Path]\\PatientJourneyLog.csv", csvLine);
}

Schritte

Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie über gültige Zugangsdaten für die Veradigm (Allscripts) Unity API verfügen. Sie benötigen einen für Ihre Organisation autorisierten Appname (Application Name) sowie eine gültige UserID und ein Password oder Token zur Authentifizierung. Prüfen Sie, ob das Benutzerkonto auf klinische Bereiche wie Encounters, Orders, Results, Vitals und Problems zugreifen darf.
Umgebung einrichten: Installieren Sie Python 3.8 oder höher. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas. Sie dienen dazu, HTTP-Anfragen an die Unity API zu senden und die resultierenden Daten zu verarbeiten.
Konfiguration: Öffnen Sie das bereitgestellte Python-Skript. Suchen Sie am Anfang den Abschnitt CONFIGURATION. Aktualisieren Sie API_URL mit dem Endpunkt Ihrer Unity-Umgebung, beispielsweise unity.veradigm.com oder einem internen Gateway. Ersetzen Sie die Platzhalter für Zugangsdaten wie [YourAppName] und [YourUserID] durch Ihre tatsächlichen Werte. Legen Sie START_DATE und END_DATE für den gewünschten Analysezeitraum fest.
Überblick über die Skriptlogik: Das Skript authentifiziert sich zunächst bei der API und ruft ein Sicherheitstoken ab. Anschließend wird GetEncounterInfo aufgerufen, um alle Patientenepisoden im angegebenen Zeitraum abzurufen. Diese Encounter-Liste dient als zentrale Iterationsgrundlage für die Extraktion.
Schleife zur Aktivitätsextraktion: Für jede ermittelte EncounterID führt das Skript weitere API-Aufrufe an spezialisierte Endpunkte aus. Mit GetOrders werden diagnostische Tests und Prozeduren ermittelt. GetResults identifiziert abgeschlossene Tests. GetVitals ruft die Erfassung von Vitalwerten ab. GetPatientProblems liefert bestätigte Diagnosen. Außerdem durchsucht das Skript klinische Notizen nach Untersuchungen und Behandlungsplänen.
Datentransformation: Sobald die API Rohdaten im JSON-Format zurückgibt, ordnet das Skript bestimmte Felder dem ProcessMind-Schema zu. Beispielsweise wird OrderDateTime für die Aktivität „Diagnostiktest angefordert“ auf EventDateTime abgebildet. Das Skript stellt sicher, dass PatientEpisodeId (Encounter ID) allen untergeordneten Datensätzen konsistent zugewiesen wird.
ADT und Verlegungen behandeln: Die Skriptlogik prüft, sofern verfügbar, die Standortchronik des Encounters über spezielle Audit- oder ADT-Aufrufe. Alternativ leitet sie Verlegungen aus Abteilungswechseln in der klinischen Dokumentation ab, um Ereignisse wie „In Abteilung verlegt“ zu erzeugen.
Nachsorgelogik: Nach der Verarbeitung des Encounters fragt das Skript mit GetSchedule für dieselbe PatientID nach Terminen, die nach DischargeDate liegen, um die Aktivität „Nachsorge geplant“ zu erzeugen.
Validierung: Das Skript enthält einen lokalen Validierungsschritt, der die Zeilenanzahl je Aktivitätstyp in der Konsole ausgibt. Prüfen Sie diese Ausgabe, um sicherzustellen, dass kein Aktivitätstyp unerwartet null Datensätze enthält.
Export: Der finale Datensatz wird in einem Pandas DataFrame zusammengeführt. Das Skript berechnet abgeleitete Attribute wie LengthOfStay und IsReadmission, indem es die Daten nach Patient und Zeit sortiert. Anschließend wird das bereinigte Event Log in die CSV-Datei veradigm_patient_journey_log.csv exportiert.
Abschließende Prüfung: Öffnen Sie die erzeugte CSV-Datei. Prüfen Sie, ob die Datumsformate ISO 8601 (YYYY-MM-DD HH:MM:SS) entsprechen und Textfelder wie ActivityName keine Trennzeichen enthalten.
Upload: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie PatientEpisodeId der Case-ID, ActivityName der Aktivität und EventDateTime dem Timestamp zu.

Konfiguration

API_URL: Die Basis-URL für die Unity-API-Dienste. Sie unterscheidet sich je nach Kundeninstallation, beispielsweise zwischen On-Premises- und Cloud-Betrieb. Stellen Sie sicher, dass das Protokoll, also https, korrekt ist.
Appname: Die eindeutige, bei Veradigm/Allscripts registrierte Anwendungskennung. Sie bestimmt den Umfang des Datenzugriffs.
Datumsbereich: Der empfohlene Extraktionszeitraum beträgt drei bis sechs Monate. Bei großen Zeiträumen können Timeouts auftreten. Teilen Sie die Extraktion bei hohem Volumen gegebenenfalls nach Monaten auf.
Timeout-Einstellungen: Das Skript verwendet für API-Aufrufe standardmäßig ein Timeout von 30 Sekunden. Erhöhen Sie diesen Wert, wenn das EHR-System stark ausgelastet ist.
Stapelverarbeitung: Das Skript iteriert pro Encounter. Bei Systemen mit hohem Volumen kann es erforderlich sein, das Skript so anzupassen, dass Daten gesammelt abgerufen werden, sofern die Endpunkte dies erlauben, oder parallele Threads einzusetzen.
Zuordnungslogik: Das Skript ordnet OrderType Aktivitäten zu. Stellen Sie sicher, dass die spezifischen Auftragstypcodes Ihres Systems, beispielsweise „Lab“ oder „Rad“, der Logik in der Funktion process_orders entsprechen.

a Beispielabfrage python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_URL = class="hl-string">"https://unity.veradigm.com/[YourEnvironment]/unity/unityservice.svc/json"
APP_NAME = class="hl-string">"[YourAppName]"
USER_ID = class="hl-string">"[YourUserID]"
PASSWORD = class="hl-string">"[YourPassword]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"veradigm_patient_journey_log.csv"

class=class="hl-string">"hl-comment"># Global Session Token
TOKEN = None

def get_security_token():
    class="hl-string">"""Authenticate and retrieve security token."""
    payload = {
        class="hl-string">"Action": class="hl-string">"GetToken",
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Username": USER_ID,
        class="hl-string">"Password": PASSWORD
    }
    try:
        response = requests.post(API_URL, json=payload)
        response.raise_for_status()
        data = response.json()
        class=class="hl-string">"hl-comment"># Depending on Unity version, token might be in body or header. Assuming body here.
        return data[0][class="hl-string">'Token'] if isinstance(data, list) else data.get(class="hl-string">'Token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def make_unity_request(action, params):
    class="hl-string">"""Wrapper for Unity API calls."""
    payload = {
        class="hl-string">"Action": action,
        class="hl-string">"Appname": APP_NAME,
        class="hl-string">"Token": TOKEN
    }
    payload.update(params)
    
    try:
        response = requests.post(API_URL, json=payload, timeout=30)
        response.raise_for_status()
        class=class="hl-string">"hl-comment"># Unity often returns a list of dictionaries
        return response.json()
    except Exception as e:
        print(fclass="hl-string">"API Call Error ({action}): {e}")
        return []

def extract_patient_journey():
    global TOKEN
    TOKEN = get_security_token()
    if not TOKEN:
        return

    print(class="hl-string">"Token acquired. Starting extraction...")
    
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Get Encounters within Date Range
    class=class="hl-string">"hl-comment"># Using GetEncounterInfo or similar search action
    encounters = make_unity_request(class="hl-string">"GetEncounterInfo", {
        class="hl-string">"StartEncounterDate": START_DATE,
        class="hl-string">"EndEncounterDate": END_DATE
    })

    print(fclass="hl-string">"Found {len(encounters)} encounters. Processing details...")

    for enc in encounters:
        try:
            class=class="hl-string">"hl-comment"># Basic Encounter Data
            episode_id = str(enc.get(class="hl-string">'EncounterID'))
            patient_id = enc.get(class="hl-string">'PatientID')
            mrn = enc.get(class="hl-string">'MRN', class="hl-string">'')
            admit_time = enc.get(class="hl-string">'EncounterDate') class=class="hl-string">"hl-comment"># ISO string expected
            discharge_time = enc.get(class="hl-string">'DischargeDate')
            dept_name = enc.get(class="hl-string">'Department', class="hl-string">'General')
            attending = enc.get(class="hl-string">'ProviderName', class="hl-string">'Unknown')
            
            class=class="hl-string">"hl-comment"># --- Activity: Patient Registered ---
            if admit_time:
                event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Registered",
                    class="hl-string">"EventDateTime": admit_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># --- Activity: Patient Discharged ---
            if discharge_time:
                 event_log.append({
                    class="hl-string">"PatientEpisodeId": episode_id,
                    class="hl-string">"ActivityName": class="hl-string">"Patient Discharged",
                    class="hl-string">"EventDateTime": discharge_time,
                    class="hl-string">"PatientMrn": mrn,
                    class="hl-string">"AttendingProvider": attending,
                    class="hl-string">"DepartmentName": dept_name,
                    class="hl-string">"AdmissionDate": admit_time,
                    class="hl-string">"DischargeDate": discharge_time
                })

            class=class="hl-string">"hl-comment"># 2. Get Orders (Labs, Procedures, Consults)
            orders = make_unity_request(class="hl-string">"GetOrders", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for order in orders:
                order_time = order.get(class="hl-string">'OrderDate')
                order_type = order.get(class="hl-string">'OrderType', class="hl-string">'').lower()
                order_name = order.get(class="hl-string">'OrderName', class="hl-string">'Unknown Order')
                
                class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Ordered ---
                if class="hl-string">'lab' in order_type or class="hl-string">'imaging' in order_type or class="hl-string">'radiology' in order_type:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Ordered",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_OrderName": order_name
                    })

                class=class="hl-string">"hl-comment"># --- Activity: Procedure Performed ---
                class=class="hl-string">"hl-comment"># Often procedures are orders with status completed or specific types
                if class="hl-string">'procedure' in order_type and order.get(class="hl-string">'Status') == class="hl-string">'Completed':
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Procedure Performed",
                        class="hl-string">"EventDateTime": order.get(class="hl-string">'CompletionDate', order_time),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ProcedureName": order_name
                    })
                    
                class=class="hl-string">"hl-comment"># --- Activity: Discharge Planning Initiated ---
                if class="hl-string">'discharge' in order_name.lower():
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Discharge Planning Initiated",
                        class="hl-string">"EventDateTime": order_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 3. Get Results (Lab completion)
            results = make_unity_request(class="hl-string">"GetResults", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for res in results:
                result_time = res.get(class="hl-string">'ResultDate')
                if result_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Diagnostic Test Completed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnostic Test Completed",
                        class="hl-string">"EventDateTime": result_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_ResultName": res.get(class="hl-string">'TestName', class="hl-string">'Unknown Test')
                    })

            class=class="hl-string">"hl-comment"># 4. Get Problems (Diagnosis)
            problems = make_unity_request(class="hl-string">"GetPatientProblems", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for prob in problems:
                onset_date = prob.get(class="hl-string">'OnsetDate') or prob.get(class="hl-string">'DateEntered')
                if onset_date:
                     class=class="hl-string">"hl-comment"># --- Activity: Diagnosis Confirmed ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Diagnosis Confirmed",
                        class="hl-string">"EventDateTime": onset_date,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"PrimaryDiagnosisCode": prob.get(class="hl-string">'ICD10', class="hl-string">''),
                        class="hl-string">"Attribute_DiagnosisName": prob.get(class="hl-string">'ProblemDescription', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 5. Get Vitals
            vitals = make_unity_request(class="hl-string">"GetVitals", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for vit in vitals:
                taken_time = vit.get(class="hl-string">'DateTaken')
                if taken_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Vitals Recorded ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Vitals Recorded",
                        class="hl-string">"EventDateTime": taken_time,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 6. Get Clinical Notes (Assessments, Plans)
            class=class="hl-string">"hl-comment"># Sometimes accessed via GetNoteInfo or GetChart
            notes = make_unity_request(class="hl-string">"GetNoteInfo", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for note in notes:
                note_date = note.get(class="hl-string">'NoteDate')
                note_title = note.get(class="hl-string">'DocumentType', class="hl-string">'').lower()
                
                class=class="hl-string">"hl-comment"># --- Activity: Initial Assessment Completed ---
                if class="hl-string">'initial' in note_title or class="hl-string">'assessment' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Initial Assessment Completed",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })
                
                class=class="hl-string">"hl-comment"># --- Activity: Treatment Plan Created ---
                if class="hl-string">'plan' in note_title or class="hl-string">'care' in note_title:
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Treatment Plan Created",
                        class="hl-string">"EventDateTime": note_date,
                        class="hl-string">"PatientMrn": mrn
                    })

            class=class="hl-string">"hl-comment"># 7. Med Administration (GetMedicationAdministration or inferred from Med History)
            meds = make_unity_request(class="hl-string">"GetMedicationAdministration", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for med in meds:
                admin_time = med.get(class="hl-string">'AdministrationDate')
                if admin_time:
                    class=class="hl-string">"hl-comment"># --- Activity: Medication Administered ---
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Medication Administered",
                        class="hl-string">"EventDateTime": admin_time,
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"Attribute_MedicationName": med.get(class="hl-string">'MedicationName', class="hl-string">'')
                    })

            class=class="hl-string">"hl-comment"># 8. Transfer Events (Infer from ADT or Audit log)
            class=class="hl-string">"hl-comment"># Simulating transfer extraction via AuditLog for Location changes
            audit_logs = make_unity_request(class="hl-string">"GetAuditLog", {class="hl-string">"PatientID": patient_id, class="hl-string">"EncounterID": episode_id})
            for log in audit_logs:
                if class="hl-string">"Transfer" in log.get(class="hl-string">'EventName', class="hl-string">'') or class="hl-string">"Location Change" in log.get(class="hl-string">'EventName', class="hl-string">''):
                     class=class="hl-string">"hl-comment"># --- Activity: Transfer to Department ---
                     event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Transfer to Department",
                        class="hl-string">"EventDateTime": log.get(class="hl-string">'EventDate'),
                        class="hl-string">"PatientMrn": mrn,
                        class="hl-string">"DepartmentName": log.get(class="hl-string">'NewValue', class="hl-string">'Unknown Dept')
                     })

            class=class="hl-string">"hl-comment"># 9. Follow-up Scheduled
            if discharge_time:
                future_appts = make_unity_request(class="hl-string">"GetSchedule", {class="hl-string">"PatientID": patient_id, class="hl-string">"StartDate": discharge_time})
                for appt in future_appts:
                    class=class="hl-string">"hl-comment"># --- Activity: Follow-up Scheduled ---
                    class=class="hl-string">"hl-comment"># Note: We want the time the appt was BOOKED, but Unity usually gives ApptDate.
                    class=class="hl-string">"hl-comment"># We will use the creation date of the appt if available, otherwise ApptDate as proxy
                    event_log.append({
                        class="hl-string">"PatientEpisodeId": episode_id,
                        class="hl-string">"ActivityName": class="hl-string">"Follow-up Scheduled",
                        class="hl-string">"EventDateTime": appt.get(class="hl-string">'DateBooked', appt.get(class="hl-string">'ApptDate')), 
                        class="hl-string">"PatientMrn": mrn
                    })

        except Exception as e:
            print(fclass="hl-string">"Error processing encounter {enc.get('EncounterID')}: {e}")
            continue

    class=class="hl-string">"hl-comment"># Post-Processing: Create DataFrame
    df = pd.DataFrame(event_log)
    
    class=class="hl-string">"hl-comment"># Helper: Convert strings to datetime
    df[class="hl-string">'EventDateTime'] = pd.to_datetime(df[class="hl-string">'EventDateTime'], errors=class="hl-string">'coerce')
    df = df.dropna(subset=[class="hl-string">'EventDateTime', class="hl-string">'PatientEpisodeId'])
    
    class=class="hl-string">"hl-comment"># Calculate LOS and Readmission
    df[class="hl-string">'AdmissionDate'] = pd.to_datetime(df[class="hl-string">'AdmissionDate'], errors=class="hl-string">'coerce')
    df[class="hl-string">'DischargeDate'] = pd.to_datetime(df[class="hl-string">'DischargeDate'], errors=class="hl-string">'coerce')
    
    class=class="hl-string">"hl-comment"># LOS
    df[class="hl-string">'LengthOfStay'] = (df[class="hl-string">'DischargeDate'] - df[class="hl-string">'AdmissionDate']).dt.days

    class=class="hl-string">"hl-comment"># IsReadmission (Simplified: check if patient had previous discharge within 30 days)
    class=class="hl-string">"hl-comment"># Requires sorting by patient and admission time first
    class=class="hl-string">"hl-comment"># This is complex in a flat event log context, simplified here as placeholder logic
    df[class="hl-string">'IsReadmission'] = False 

    print(fclass="hl-string">"Extraction complete. Rows: {len(df)}")
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Data saved to {OUTPUT_FILE}")

if __name__ == class="hl-string">"__main__":
    extract_patient_journey()

Möchten Sie beginnen?

Beginnen Sie noch heute damit, die Patientenerfahrung und die operative Effizienz zu verbessern. Ihre Daten helfen Ihnen dabei, wertvolle Erkenntnisse zu gewinnen und wesentliche Verbesserungen umzusetzen.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Ihre Patientenpfade in Veradigm noch heute

Erreichen Sie 30 % kürzere Durchlaufzeiten für Patienten und bessere Behandlungsergebnisse.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie sofort.

Ihr Daten-Template für den Patientenpfad

Ihr Daten-Template für den Patientenpfad

Attribute des Patientenpfads

Aktivitäten des Patientenpfads

Anleitungen zur Datenextraktion

Event-Log-Export aus der Allscripts Interface Engine

Schritte

Konfiguration

a Beispielabfrage config

Extraktion über die Veradigm Unity API mit Python

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie Ihre Patientenpfade in Veradigm noch heute

Ihr Daten-Template für den Patientenpfad

Ihr Daten-Template für den Patientenpfad

Attribute des Patientenpfads

Aktivitäten des Patientenpfads

Anleitungen zur Datenextraktion

Event-Log-Export aus der Allscripts Interface Engine

Schritte

Konfiguration

a Beispielabfrage config

Extraktion über die Veradigm Unity API mit Python

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie Ihre Patientenpfade in Veradigm noch heute

Ihre Privatsphäre ist uns wichtig