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

Ihr Daten-Template für den Behandlungsverlauf

Veradigm (Allscripts)

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute zum Behandlungsverlauf(19) Aktivitäten im Behandlungsverlauf(13) Anleitungen zur Datenextraktion(2)

Ihr Daten-Template für den Behandlungsverlauf

Dieses Template bietet eine strukturierte Grundlage, um die für die Analyse des Behandlungsverlaufs erforderlichen Daten zu erfassen. Es beschreibt die wichtigsten Attribute und Aktivitäten, die Sie verfolgen sollten, und zeigt, wie Sie diese Informationen aus Ihrem Quellsystem extrahieren. Bereiten Sie Ihre Daten damit für eine umfassende Process-Mining-Analyse vor.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Aktivitäten für eine präzise Prozesserkennung
Praktische Anleitung zum Extrahieren von Daten aus Ihrem System

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute zum Behandlungsverlauf

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie den Behandlungsverlauf umfassend analysieren können.

3 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das konkrete klinische oder administrative Ereignis, das stattgefunden hat.
Beschreibung Beschreibt den ausgeführten Prozessschritt, etwa „Patient registriert“, „Medikament verabreicht“ oder „Entlassungsplanung eingeleitet“. Dieses Attribut unterscheidet die verschiedenen Phasen der Patientenreise und ist für die Prozesserkennung und Variantenanalyse unverzichtbar. Warum das wichtig ist Legt die Knoten in der Prozesslandkarte fest. Ohne dieses Attribut lässt sich kein Prozessfluss visualisieren. Woher beziehen Abgeleitet aus verschiedenen Transaktionstabellen: ADT-Ereignisse, Aufträge, Ergebnisse und Tabellen der klinischen Dokumentation. Beispiele Patient registriertDiagnostischer Test angeordnetMedikament verabreichtPatient entlassen
	Ereignis-Timestamp EventDateTime	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Erfasst den Zeitpunkt der Aktivität in der zeitlichen Abfolge. Das ist entscheidend, um Zykluszeiten und Dauern zu berechnen und die Ereignisse korrekt zu ordnen. Bei Gesundheitsdaten ist eine minutengenaue Erfassung für eine präzise Durchsatzanalyse unerlässlich. Warum das wichtig ist Ermöglicht die Berechnung aller zeitbasierten KPIs, darunter die durchschnittliche Zykluszeit der Patientenreise und Wartezeiten. Woher beziehen Transaktions-Timestamps in den Quelltabellen, zum Beispiel 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 Gesundheitsversorgung eines Patienten bei einer bestimmten Erkrankung oder während eines bestimmten Behandlungszeitraums gehören. So lassen sich Diagnose, Behandlung und Genesung gemeinsam betrachten und die Kontakte mit verschiedenen Abteilungen zu einem Gesamtbild zusammenführen. In Veradigm (Allscripts)-Systemen wie Sunrise oder Paragon entspricht sie üblicherweise der Visit ID oder Encounter Number. Warum das wichtig ist Sie ist der zentrale Schlüssel für Process Mining und ermöglicht die Rekonstruktion der Patientenreise von Anfang bis Ende. Woher beziehen Wahrscheinlich im Kopfbereich der Visit- oder Encounter-Tabellen zu finden, zum Beispiel als VISIT_ID oder ENCOUNTER_ID. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele EP-2023-998877VIS-10029384100029384ENC-554433
	Abteilungsname DepartmentName	Die Station oder Abteilung des Krankenhauses, in der die Aktivität stattgefunden hat.
Beschreibung Gibt den Ort an, etwa „Notaufnahme“, „Kardiologie“ oder „Radiologie“. Diese Angabe ist wichtig für die „Engpassanalyse bei Aufnahme und Verlegung“, um zu erkennen, wo Patienten beim Wechsel zwischen Stationen warten. Warum das wichtig ist Unterstützt die Analyse der Ressourcennutzung und das Erkennen von Engpässen in einzelnen Abteilungen. Woher beziehen Standort- oder Abteilungsstammtabellen, die mit der Transaktion verknüpft sind. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele NotaufnahmeICUAllgemeinchirurgieRadiologie
	Aufnahmedatum AdmissionDate	Datum und Uhrzeit der formellen Aufnahme des Patienten.
Beschreibung Der Timestamp, der den Beginn des stationären Aufenthalts kennzeichnet. Zusammen mit dem Entlassungsdatum dient er zur Berechnung der Aufenthaltsdauer (ALOS). Warum das wichtig ist Entscheidender Bezugspunkt für die Berechnung der Aufenthaltsdauer und die Messung von Aufnahmeverzögerungen. Woher beziehen Kopftabelle für Visit oder Encounter, zum Beispiel ADMIT_DATE. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Behandelnde Fachkraft AttendingProvider	Die primär für den Patienten während des Ereignisses verantwortliche klinische Fachkraft.
Beschreibung Gibt an, welcher Arzt, welche Pflegekraft oder welcher Spezialist die Aktivität ausführt oder für den Behandlungsplan verantwortlich ist. Die Analyse dieses Attributs hilft, die „Nutzung klinischer Ressourcen“ und Unterschiede zwischen den Behandlungspfaden einzelner Ärzte zu verstehen. Warum das wichtig ist Ermöglicht die Analyse von Ressourcenengpässen und den Leistungsvergleich zwischen klinischen Mitarbeitenden. Woher beziehen Transaktionstabellen, zum Beispiel ORDERING_PROVIDER und ATTENDING_PHYSICIAN_ID. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele Dr. Sarah SmithPflegefachkraft JonesRadiologietechniker A
	Entlassungsart DischargeDisposition	Status oder Aufenthaltsort des Patienten zum Zeitpunkt der Entlassung.
Beschreibung Gibt an, wohin der Patient nach dem Krankenhausaufenthalt gegangen ist (z. B. „Nach Hause“, „Pflegeeinrichtung“, „Verstorben“, „Verlegung“). Diese Angabe ist wichtig, um das Risiko einer Wiederaufnahme zu analysieren, da die verschiedenen Entlassungsarten mit unterschiedlichen Risikoprofilen verbunden sind. Warum das wichtig ist Liefert Kontext für das Dashboard „Entlassungsplanung“ und hilft, Abweichungen bei ALOS zu erklären. Woher beziehen Kopftabelle für Besuche bzw. Behandlungsfälle (z. B. DISCH_DISP). Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele Nach HauseIn eine Pflegeeinrichtung verlegtNach Hause mit häuslicher PflegeGegen ärztlichen Rat gegangen
	Entlassungsdatum DischargeDate	Datum und Uhrzeit der Entlassung des Patienten.
Beschreibung Der Timestamp, der das Ende des Behandlungsfalls markiert. Er schließt den Case im Process Mining ab und ist für die Berechnung von ALOS und Wiederaufnahmen unerlässlich. Warum das wichtig ist Legt das Ende des Prozesszyklus fest und ist entscheidend für die Durchsatzanalyse. Woher beziehen Kopftabelle für Besuche bzw. Behandlungsfälle (z. B. DISCH_DATE). Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Patienten-MRN PatientMrn	Die Medical Record Number (MRN) identifiziert den Patienten eindeutig über mehrere Episoden hinweg.
Beschreibung Die Medical Record Number (MRN) oder Enterprise Patient ID. Anders als die ID der Patientenepisode bleibt diese Kennung bei verschiedenen Besuchen gleich. Sie ist entscheidend, um separate Episoden miteinander zu verknüpfen und Wiederaufnahmeraten zu berechnen. Warum das wichtig ist Unverzichtbar für die „Wiederaufnahmerate innerhalb von 30 Tagen“ und die Identifizierung wiederkehrender Patienten. Woher beziehen Patientenstammverzeichnis oder demografische Tabellen, wahrscheinlich mit den Spalten MRN und PATIENT_ID. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele MRN-884422P-10022399887766
	Primärer Diagnosecode PrimaryDiagnosisCode	Der ICD-10- oder SNOMED-Code für die Hauptdiagnose.
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 unterschiedliche Erkrankungen, etwa Lungenentzündung oder Herzinsuffizienz, den Behandlungsverlauf im System beeinflussen. Warum das wichtig ist Erforderlich, um Prozesse nach klinischer Erkrankung aufzuschlüsseln und die Einhaltung von Behandlungsprotokollen zu prüfen. Woher beziehen Diagnose- oder Problemlistentabellen, in der Regel mit ICD-10-Spalten. Ziehen Sie die Dokumentation zu Veradigm (Allscripts) heran. Beispiele I50.9J18.9E11.9
	Wiederaufnahme IsReadmission	Kennzeichen dafür, ob es sich bei diesem Behandlungsfall um eine Wiederaufnahme innerhalb von 30 Tagen handelt.
Beschreibung Ein berechnetes boolesches Attribut. Es gibt „true“ zurück, wenn der Patient innerhalb von 30 Tagen vor dem aktuellen Aufnahmedatum entlassen wurde. Dieser Wert fließt in den „Monitor für vermeidbare Wiederaufnahmen“ ein. Warum das wichtig ist Zentrale KPI für die Qualität und Vergütung von Krankenhäusern, insbesondere im Zusammenhang mit CMS-Vorschriften. Woher beziehen Wird in der ETL- bzw. Datentransformationsschicht anhand von PatientMRN sowie Aufnahme- und Entlassungsdaten berechnet. Beispiele truefalse
	Auftrags-ID OrderId	Kennung für einzelne Aufträge (Labor, Medikamente, Eingriffe).
Beschreibung Verknüpft das Ereignis „Auftrag“ mit dem Ereignis „Ergebnis“ oder „Verabreichung“. So lässt sich beispielsweise „Diagnostische Untersuchung angeordnet“ mit „Diagnostische Untersuchung abgeschlossen“ verknüpfen. Diese Detailtiefe ist für das Dashboard „Durchlaufzeit diagnostischer Untersuchungen“ erforderlich. Warum das wichtig ist Ermöglicht die Berechnung der Dauer einzelner Prozessschritte (z. B. der Durchlaufzeit im Labor). Woher beziehen Tabellen zur Auftragserfassung (z. B. ORDER_ID, PLACER_ORDER_NUM). Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele ORD-998877LAB-112233RX-445566
	Datum des Folgetermins FollowUpAppointmentDate	Datum des geplanten Folgetermins.
Beschreibung Wird zur Berechnung der „Quote geplanter Folgetermine“ verwendet. Ist dieses Feld ausgefüllt, wurde ein Folgetermin vereinbart. Ist es leer oder enthält es null, wurde kein Folgetermin vereinbart. Warum das wichtig ist Misst direkt die KPI „Einhaltung der Nachsorge“. Woher beziehen Terminplanungssystem oder Tabelle mit künftigen, dem Patienten zugeordneten Terminen. Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-11-15T14:00:00Znull
	Durchlaufzeit diagnostischer Untersuchungen DiagnosticTurnaroundTime	Zeitspanne zwischen der Anordnung einer Untersuchung und dem Vorliegen des Ergebnisses.
Beschreibung Berechnete Zeitspanne zwischen „Diagnostische Untersuchung angeordnet“ und „Diagnose bestätigt“ (oder dem Eingang des Ergebnisses). Wird für die „Übersicht der Durchlaufzeiten diagnostischer Untersuchungen“ verwendet. Warum das wichtig ist Lange Durchlaufzeiten verlängern die Verweildauer. Diese Kennzahl zeigt Verzögerungen im Labor oder in der Radiologie auf. Woher beziehen Berechnung: Timestamp(Ergebnis) - Timestamp(Auftrag). Beispiele 2 Stunden45 Minuten1,5 Tage
	Einhaltung des Behandlungsprotokolls IsProtocolCompliant	Kennzeichen dafür, ob der Case dem standardisierten Behandlungspfad gefolgt ist.
Beschreibung Ein berechnetes Attribut, das prüft, ob bestimmte vorgeschriebene Aktivitäten, etwa „Vitalwerte erfasst“ vor „Medikament verabreicht“, in der richtigen Reihenfolge stattgefunden haben. Unterstützt das „Dashboard zur Einhaltung von Behandlungsprotokollen“. Warum das wichtig ist Erkennt Abweichungen von Vorgaben automatisch, ohne dass Patientenakten manuell geprüft werden müssen. Woher beziehen Wird im Process-Mining-Tool oder in der ETL anhand der Aktivitätsreihenfolge berechnet. Beispiele truefalse
	Kostenstelle CostCenter	Finanzcode der Abteilung oder Leistung.
Beschreibung Ordnet klinische Aktivitäten einer Finanzeinheit zu. So lassen sich die „Aktivitätskosten“ und die allgemeine finanzielle Leistung verschiedener Abteilungen analysieren. Warum das wichtig ist Stellt den Zusammenhang zwischen operativem Process Mining und finanziellen Auswirkungen her. Woher beziehen Tabellen zu Abteilungen oder Gebührenkatalogen. Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele CC-1020CC-Rad-01Emergency-001
	Letzte Datenaktualisierung LastDataUpdate	Timestamp der letzten Extraktion oder Aktualisierung des Datensatzes.
Beschreibung Gibt an, wie aktuell die für die Analyse verwendeten Daten sind. Anhand dieses Feldes können Benutzer erkennen, ob sie Echtzeitdaten oder einen Datenstand aus einem früheren Zeitraum betrachten. Warum das wichtig ist Sorgt für Transparenz bei der Datenlatenz und unterstützt Strategien zum schrittweisen Laden von Daten. Woher beziehen Vom System während des ETL- oder Extraktionslaufs generierter Timestamp. Beispiele 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Medikamentenname MedicationName	Name des verordneten oder verabreichten Medikaments.
Beschreibung Wird speziell für das Dashboard „Zeitabstände bei der Medikamentengabe“ verwendet. Damit lässt sich feststellen, ob sich die Verabreichung bestimmter Medikamente, etwa Antibiotika oder Schmerzmittel, verzögert. Warum das wichtig ist Entscheidend für die Analyse der klinischen Sicherheit und die Optimierung der Abläufe in der Apotheke. Woher beziehen Medikamentengabeprotokoll (MAR) oder Apothekenaufträge. Beachten Sie die Dokumentation von Veradigm (Allscripts). Beispiele AmoxicillinHeparinMorphinsulfat
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Gibt die Softwareinstanz an, aus der die Daten stammen, etwa „Veradigm Sunrise“ oder „Veradigm TouchWorks“. Das ist besonders wichtig in Krankenhausverbünden oder wenn Daten aus der Akutversorgung und dem ambulanten Bereich zusammengeführt werden. Warum das wichtig ist Ermöglicht die Rückverfolgung der Datenherkunft und ist hilfreich bei der Fehlersuche in der Datenqualität. Woher beziehen Während des ETL-Prozesses fest codiert oder aus Metadatentabellen des Systems extrahiert. Beispiele Veradigm SunriseAllscripts PMVeradigm TouchWorks

Erforderlich Empfohlen Optional

Aktivitäten im Behandlungsverlauf

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Behandlungsverlauf präzise zu analysieren.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Behandlungsplan erstellt	Bezeichnet die formelle Festlegung des Behandlungsplans durch das klinische Team. Erfasst wird dieses Ereignis häufig, wenn ein bestimmtes Dokument wie „Plan of Care“ oder eine Reihe erster Behandlungsaufträge im EHR erstellt und unterzeichnet wird.
Warum das wichtig ist Mit diesem Meilenstein beginnt die aktive Behandlungsphase. Er dient als Ausgangspunkt, um die Einhaltung von Behandlungsprotokollen und die Zeit bis zur ersten Behandlungsmaßnahme, etwa der Medikamentengabe, zu messen. Woher beziehen Abgeleitet aus dem Signatur-Timestamp eines „Plan of Care“-Formulars oder dem Erstellungs-Timestamp der ersten größeren Gruppe therapeutischer Aufträge nach der Diagnose. Erfassung Ermitteln Sie den Timestamp, zu dem das Dokument „Plan of Care“ von der behandelnden Ärztin oder dem behandelnden Arzt abgeschlossen oder unterzeichnet wird. Ereignistyp inferred
	Diagnose bestätigt	Diese Aktivität zeigt an, dass ein Arzt oder eine Ärztin eine Diagnose offiziell in der Patientenakte dokumentiert hat. Erfasst wird sie beispielsweise, wenn ein Diagnosecode zur Problemliste hinzugefügt oder eine klinische Notiz mit der Diagnose unterzeichnet wird.
Warum das wichtig ist Die Bestätigung der Diagnose ist ein entscheidender Wendepunkt, der den weiteren Behandlungsverlauf bestimmt. So lassen sich Unterschiede in den Behandlungspfaden je nach Diagnose analysieren. Woher beziehen Zu finden in der Problemliste des Patienten, den Diagnosedatensätzen des Patientenkontakts oder der klinischen Dokumentation. Das Ereignis lässt sich anhand des Timestamps ableiten, zu dem ein primärer Diagnosecode für den Kontakt eingetragen und abgeschlossen wird. Erfassung Verwenden Sie den Erstellungs- oder Aktualisierungs-Timestamp des primären Diagnoseeintrags für die betreffende Patientenepisode. Ereignistyp inferred
	Entlassungsplanung eingeleitet	Bezeichnet den formellen Beginn der Entlassungsplanung für einen Patienten. Das Ereignis lässt sich beispielsweise aus der Erstellung eines Entlassungsplans, der Anordnung einer Entlassung oder dem Abschluss einer speziellen Einschätzung zur Entlassungsplanung ableiten.
Warum das wichtig ist Diese Aktivität bildet den Ausgangspunkt, um die Effizienz des Entlassungsprozesses zu messen. Ein frühzeitiger Beginn der Planung geht häufig mit weniger Wiederaufnahmen einher. Woher beziehen Abgeleitet aus dem Erstellungs-Timestamp einer Notiz zur Entlassungsplanung, eines Entlassungsauftragssatzes oder eines speziellen Einschätzungsformulars in Veradigm. Erfassung Ermitteln Sie den Timestamp, zu dem erstmals ein entlassungsspezifischer Auftrag 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, etwa der Triage oder der Erstaufnahme. Dieses Ereignis wird häufig erfasst, wenn ein bestimmtes klinisches Formular oder eine Notiz, beispielsweise eine „Nursing Initial Assessment“, im EHR unterzeichnet und abgeschlossen wird.
Warum das wichtig ist Diese Aktivität ist ein wichtiger früher Meilenstein. Die Zeit zwischen der Registrierung und dieser Einschätzung zeigt mögliche Verzögerungen bei der Patientenaufnahme und Erstversorgung auf. Woher beziehen Abgeleitet aus dem Abschluss- oder Signatur-Timestamp von Formularen zur Ersteinschätzung oder klinischen Notizen in den klinischen Dokumentationsmodulen von Veradigm. Erfassung Ermitteln Sie den Timestamp, zu dem der Status der Notiz oder des Formulars zur Ersteinschätzung auf „abgeschlossen“ oder „unterzeichnet“ wechselt. Ereignistyp inferred
	Patient entlassen	Kennzeichnet das offizielle Ende der stationären Episode, wenn der Patient formell aus der Einrichtung entlassen wird. Dieses wichtige Ereignis wird ausdrücklich im ADT-System erfasst, das den Status des Patientenkontakts auf „entlassen“ setzt.
Warum das wichtig ist Dies ist bei den meisten Patientenreisen die zentrale Abschlussaktivität. Sie ist entscheidend für die Berechnung der durchschnittlichen Aufenthaltsdauer (ALOS) und der gesamten Prozesszykluszeit. Woher beziehen Wird ausdrücklich im ADT-Modul protokolliert. Der Datensatz des Patientenkontakts enthält einen Entlassungs-Timestamp und Angaben zum Entlassungsziel. Erfassung 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 Veradigm erfasst werden. Dieses Ereignis wird in der Regel ausdrücklich protokolliert, wenn ein Benutzer den Registrierungs-Workflow abschließt. Dabei wird ein neuer Patientenkontakt mit eindeutiger Kennung und Timestamp angelegt.
Warum das wichtig ist Dies ist die zentrale Startaktivität der Patientenreise. Sie ist entscheidend für die Berechnung der gesamten Prozesszykluszeit, der Aufenthaltsdauer und des Patientendurchsatzes. Woher beziehen Dieses Ereignis wird im Patientenregistrierungs- oder ADT-Modul (Admission, Discharge, Transfer) erfasst. Suchen Sie nach dem Erstellungs-Timestamp des Patientenkontakts oder Besuchsdatensatzes. Erfassung Timestamp aus dem Patientenkontakt oder der Registrierungstabelle, der beim Anlegen des Datensatzes erfasst wird. Ereignistyp explicit
	Diagnostischer Test abgeschlossen	Bezeichnet den Zeitpunkt, zu dem die Ergebnisse eines diagnostischen Tests endgültig vorliegen und in der Patientenakte verfügbar sind. Dieses Ereignis wird in der Regel aus einer Statusänderung des ursprünglichen Auftrags abgeleitet, etwa von „aktiv“ oder „in Bearbeitung“ zu „abgeschlossen“ oder „Ergebnis liegt vor“.
Warum das wichtig ist Diese Aktivität ist ein entscheidender Meilenstein für die Messung der Dauer diagnostischer Untersuchungen. Verzögerungen zwischen Anordnung und Abschluss können die Zeit bis zur Diagnose erheblich verlängern. Woher beziehen Abgeleitet aus dem Statusfeld des Auftrags im Auftragsmodul oder aus Timestamps im zugehörigen Ergebnismodul, etwa LIS oder RIS. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Auftragsstatus in einen Endstatus wie „Abgeschlossen“ oder „Ergebnis liegt vor“ ändert. Ereignistyp inferred
	Diagnostischer Test angeordnet	Dieses Ereignis tritt ein, wenn ein Arzt oder eine Ärztin einen diagnostischen Test anordnet, etwa eine Laboruntersuchung oder eine bildgebende Untersuchung. Es wird ausdrücklich über das Computerized Physician Order Entry (CPOE)-System in Veradigm erfasst.
Warum das wichtig ist Damit beginnt der diagnostische Teilprozess. Dieses Ereignis bildet den Ausgangspunkt, um die Dauer der Diagnostik zu messen und Verzögerungen bei der Anordnung von Untersuchungen zu erkennen. Woher beziehen Erfasst im Auftragsmodul oder in den Protokollen des CPOE-Systems. Jeder Auftrag enthält einen Timestamp, der den Zeitpunkt der Anordnung angibt. Erfassung Extrahieren Sie den Erstellungs-Timestamp aus den Auftragseinträgen der relevanten diagnostischen Tests. Ereignistyp explicit
	Eingriff durchgeführt	Bezeichnet den Abschluss eines klinischen oder chirurgischen Eingriffs. Erfasst wird dieses Ereignis in der Regel, wenn ein Arzt oder eine Ärztin den Eingriffsbericht unterzeichnet oder der Status des Eingriffsauftrags im System auf „abgeschlossen“ gesetzt wird.
Warum das wichtig ist Eingriffe sind in vielen Patientenreisen wichtige Meilensteine. Ihre zeitliche Analyse gibt Aufschluss über die Ressourcennutzung und die Effizienz der Terminplanung. Woher beziehen Abgeleitet aus dem Signatur-Timestamp eines Eingriffsberichts im klinischen Dokumentationsmodul oder dem Abschluss-Timestamp des entsprechenden Eingriffsauftrags im Auftragsmodul. Erfassung Verwenden Sie den Abschluss-Timestamp des Eingriffsauftrags oder den Signatur-Timestamp der zugehörigen Eingriffsdokumentation. Ereignistyp inferred
	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 Medikamentengabe ist wichtig, um die Rechtzeitigkeit und die Einhaltung des Behandlungsplans zu analysieren. Der zeitliche Abstand zwischen Anordnung und Verabreichung hilft, Verzögerungen bei der Medikamentengabe zu erkennen. Woher beziehen Wird ausdrücklich im eMAR-Modul (electronic Medication Administration Record) protokolliert. Für jedes Ereignis sind ein bestimmter Timestamp, das Medikament und die Dosierung hinterlegt. Erfassung Extrahieren Sie die Timestamps für jedes Ereignis der Medikamentengabe aus der eMAR-Tabelle, das mit dem Patientenkontakt verknüpft ist. Ereignistyp explicit
	Nachsorgetermin vereinbart	Diese Aktivität bezeichnet die Vereinbarung eines Nachsorgetermins nach der Entlassung. Das Ereignis wird im Terminplanungsmodul erfasst, wenn ein Termin gebucht und mit dem abgeschlossenen Patientenkontakt verknüpft wird.
Warum das wichtig ist Ein vereinbarter Nachsorgetermin ist wichtig für die Kontinuität der Versorgung und zur Verringerung von Wiederaufnahmen. Anhand dieser Aktivität lässt sich die Einhaltung der Nachsorgeprotokolle nach der Entlassung messen. Woher beziehen Erfasst im Terminplanungsmodul. Suchen Sie nach dem Erstellungs-Timestamp eines neuen Patiententermins, der nach dem Entlassungsdatum liegt. Erfassung Ermitteln Sie den Erstellungs-Timestamp eines mit dem Patienten verknüpften Termineintrags im Terminplanungssystem. Ereignistyp explicit
	Verlegung in eine Abteilung	Dieses Ereignis kennzeichnet die Verlegung eines Patienten von einer Abteilung oder Versorgungseinheit in eine andere, beispielsweise aus der Notaufnahme auf eine Station. Erfasst wird es im ADT-System (Admission, Discharge, Transfer) von Veradigm.
Warum das wichtig ist Bei Patientenverlegungen kommt es häufig zu Engpässen und Verzögerungen. Die Analyse von Dauer und Häufigkeit der Verlegungen hilft, den Patientenfluss und die Ressourcenverteilung zwischen Abteilungen zu verbessern. Woher beziehen Wird ausdrücklich im ADT-Modul protokolliert. Jedes Verlegungsereignis enthält Angaben zum Patienten, zum Ausgangs- und Zielort sowie einen Timestamp. Erfassung Extrahieren Sie die Ereignisprotokolle zu Patientenbewegungen aus dem ADT-System. Ereignistyp explicit
	Vitalwerte erfasst	Diese Aktivität tritt jedes Mal ein, wenn Vitalwerte eines Patienten, etwa Herzfrequenz, Blutdruck und Temperatur, erfasst werden. Sie wird ausdrücklich in der klinischen Dokumentation oder im speziellen Flowsheet-Bereich für Vitalwerte des EHR protokolliert.
Warum das wichtig ist Die regelmäßige Erfassung von Vitalwerten zeigt, dass der Patient aktiv überwacht wird. Häufigkeit und Zeitpunkt lassen sich analysieren, um die Einhaltung der Überwachungsprotokolle zu prüfen. Woher beziehen Erfasst im klinischen Datenrepository oder in Flowsheet-Tabellen, in denen die Vitalwerte gespeichert sind. Jeder Eintrag enthält einen Timestamp. Erfassung Extrahieren Sie die Timestamps der Vitalwerte aus den Flowsheet-Daten zum Patientenkontakt. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Veradigm (Allscripts)

Schritte

Ziel-Interface-Kanal ermitteln: Melden Sie sich an der Management Console der Allscripts Interface Engine (AIE) an. Suchen Sie den primären Interface-Kanal, der eingehende Nachrichten aus dem EHR verarbeitet (häufig „EHR_Inbound“ oder ähnlich). Vergewissern Sie sich, dass dieser Kanal die Nachrichtentypen ADT, SIU, ORM, ORU, RAS und DFT verarbeitet, damit alle Aktivitäten der Patientenreise erfasst werden.
Neuen Passthrough-/Exportkanal erstellen: Erstellen Sie einen neuen Zielkanal mit dem Namen „ProcessMining_Export“. Legen Sie als Ausgabetyp „File Writer“ fest. Dieser Kanal erhält eine Kopie der Nachrichten aus dem Quellkanal und wandelt sie für ProcessMind in ein einfaches Dateiformat (CSV) um.
Nachrichtenrouting konfigurieren: Richten Sie in den AIE-Routingregeln eine Kopier- oder Weiterleitungsregel 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 (Bestellungen), ORU (Ergebnisse/Vitalwerte), RAS (Medikamente) und DFT (Abrechnung/Prozeduren).
Transformationslogik festlegen: Ö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 HL7-Rohsegmente ausliest und bestimmte Trigger Events und Statuscodes den erforderlichen standardisierten Aktivitätsnamen zuordnet, zum Beispiel „ADT^A01“ der Aktivität „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 Angaben wie „DepartmentName“ aus PV1-3 und „AttendingProvider“ aus PV1-7.
Ausgabedatei konfigurieren: Legen Sie die Einstellungen für den File Writer fest. Geben Sie als Ausgabeverzeichnis einen sicheren Netzwerkpfad an. Definieren Sie das Dateinamensschema, zum Beispiel EventLog_YYYYMMDD_HH.csv. Wählen Sie als Dateimodus „Append“, damit fortlaufend Zeilen zum Event Log hinzugefügt werden.
Trennzeichen und Sonderzeichen behandeln: Sorgen Sie im Skript dafür, 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, zum Beispiel indem Sie einen Testpatienten registrieren. Prüfen Sie, ob eine neue Zeile mit dem richtigen Aktivitätsnamen und Timestamp in der CSV-Datei erscheint.
Protokollrotation einrichten: Legen Sie einen Rotationszeitplan fest, zum Beispiel täglich um Mitternacht. Dabei wird die aktuelle CSV-Datei geschlossen und eine neue begonnen. So bleiben die Dateien für den Upload handhabbar.
Historische Daten erneut verarbeiten (optional): Verwenden Sie bei Bedarf das Tool „Message Browser“ oder „Log Replay“ der AIE, um archivierte HL7-Protokolle der vergangenen 3 bis 6 Monate erneut über den Kanal „ProcessMining_Export“ zu senden. Behalten Sie die Systemleistung im Blick, damit es nicht zu Verzögerungen kommt.
Dateien abrufen und formatieren: Öffnen Sie das Ausgabeverzeichnis, rufen Sie die erstellten CSV-Dateien ab und prüfen Sie, ob die Spaltenüberschriften den Anforderungen entsprechen. Führen Sie bei Bedarf die Tagesdateien zusammen.
In ProcessMind hochladen: Importieren Sie den fertigen 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 (wichtig für Sonderzeichen in Namen und Diagnosen)
Trennzeichen: Komma (,) oder senkrechter Strich (|)
Datumsformat: Für die Umwandlung von HL7-Timestamps wird ISO 8601 (YYYY-MM-DDTHH:MM:SS) empfohlen.
Protokollrotation: Täglich oder sobald die Dateigröße 100 MB überschreitet
Schreibmodus: Append (nicht überschreiben)
Leistung: Halten Sie das Transformationsskript schlank, damit sich in der Engine keine Nachrichtenwarteschlange oder Rückstände bilden.

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 gültige Zugangsdaten für die Veradigm (Allscripts) Unity API haben. Sie benötigen einen für Ihre Organisation autorisierten Appname (Application Name) sowie eine gültige UserID und ein gültiges Password oder Token zur Authentifizierung. Prüfen Sie, ob das Benutzerkonto auf die klinischen Bereiche Encounters, Bestellungen, Ergebnisse, Vitalwerte und Probleme zugreifen darf.
Umgebung einrichten: Installieren Sie Python 3.8 oder höher. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas. Damit lassen sich HTTP-Anfragen an die Unity API senden und die zurückgegebenen Daten verarbeiten.
Konfiguration: Öffnen Sie das bereitgestellte Python-Skript und suchen Sie am Anfang den Abschnitt CONFIGURATION. Ändern Sie API_URL so, dass die Adresse auf Ihren Unity-Endpunkt verweist, zum Beispiel unity.veradigm.com oder ein internes Gateway. Ersetzen Sie die Platzhalter für Zugangsdaten ([YourAppName], [YourUserID] usw.) durch Ihre tatsächlichen Werte. Legen Sie mit START_DATE und END_DATE 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 fragt es mit GetEncounterInfo alle Patientenepisoden im festgelegten Zeitraum ab. Die Liste der Encounters dient als Ausgangspunkt für die weitere Extraktion.
Aktivitäten extrahieren: Für jede ermittelte EncounterID sendet das Skript weitere API-Anfragen an spezialisierte Endpunkte. Mit GetOrders ruft es diagnostische Tests und Prozeduren ab, mit GetResults abgeschlossene Tests und mit GetVitals die erfassten Vitalwerte. GetPatientProblems liefert bestätigte Diagnosen. Außerdem durchsucht das Skript klinische Notizen nach Beurteilungen und Behandlungsplänen.
Daten transformieren: Das Skript liest die als JSON zurückgegebenen Rohdaten aus und ordnet die benötigten Felder dem ProcessMind-Schema zu. Beispielsweise wird OrderDateTime für die Aktivität „Diagnostischer Test angeordnet“ dem Feld EventDateTime zugeordnet. Dabei wird PatientEpisodeId (Encounter-ID) allen zugehörigen Datensätzen einheitlich zugewiesen.
ADT und Verlegungen behandeln: Wenn verfügbar, prüft das Skript den Standortverlauf des Encounters über entsprechende Audit- oder ADT-Aufrufe. Alternativ leitet es Verlegungen aus Abteilungswechseln in der klinischen Dokumentation ab und erzeugt Aktivitäten vom Typ „Verlegung in eine Abteilung“.
Nachsorge berücksichtigen: Nach der Verarbeitung eines Encounters fragt das Skript mit GetSchedule die Termine derselben PatientID ab. Es sucht nach Terminen nach dem DischargeDate, um die Aktivität „Nachsorgetermin geplant“ zu erzeugen.
Daten prüfen: Das Skript gibt in einer lokalen Validierung die Anzahl der Zeilen je Aktivitätstyp in der Konsole aus. Prüfen Sie die Ergebnisse und vergewissern Sie sich, dass kein Aktivitätstyp unerwartet ohne Datensätze bleibt.
Export: Das Skript führt den fertigen Datensatz in einem Pandas DataFrame zusammen. Es berechnet abgeleitete Attribute wie LengthOfStay und IsReadmission, nachdem die Daten nach Patient und Zeit sortiert wurden. Anschließend exportiert es das bereinigte Event Log in die Datei veradigm_patient_journey_log.csv.
Abschließende Prüfung: Öffnen Sie die erstellte CSV-Datei. Prüfen Sie, ob die Datumsangaben dem ISO-8601-Format (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: Basis-URL der Unity-API-Dienste. Sie hängt von der Installation des jeweiligen Kunden ab, zum Beispiel lokal oder in der Cloud. Prüfen Sie, ob das Protokoll (https) korrekt ist.
Appname: Eindeutige Anwendungskennung, die bei Veradigm/Allscripts registriert ist. Sie legt den Umfang des Datenzugriffs fest.
Datumsbereich: Empfohlen wird ein Extraktionszeitraum von 3 bis 6 Monaten. Bei größeren Zeiträumen kann es zu Zeitüberschreitungen kommen. Teilen Sie die Abfrage bei hohem Datenvolumen gegebenenfalls nach Monaten auf.
Zeitüberschreitung: Für API-Aufrufe verwendet das Skript standardmäßig einen Timeout von 30 Sekunden. Erhöhen Sie diesen Wert, wenn das EHR-System stark ausgelastet ist.
Stapelverarbeitung: Das Skript verarbeitet jeden Encounter einzeln. Bei hohem Datenvolumen kann es erforderlich sein, das Skript so anzupassen, dass Daten gesammelt abgerufen werden, sofern die Endpunkte dies unterstützen, oder parallele Threads einzusetzen.
Zuordnungslogik: Das Skript ordnet „OrderType“ Aktivitäten zu. Prüfen Sie, ob die spezifischen Bestellcodes Ihres Systems, zum Beispiel „Lab“ oder „Rad“, mit der Logik in der Funktion process_orders übereinstimmen.

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 loslegen?

Beginnen Sie noch heute damit, die Patientenerfahrung und die betrieblichen Abläufe zu verbessern. Ihre Daten liefern wichtige Erkenntnisse und zeigen, wo gezielte Verbesserungen möglich sind.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie noch heute die Patientenreise in Veradigm

Verkürzen Sie die Durchlaufzeiten für Patienten um 30 % und verbessern Sie die Behandlungsergebnisse.

Kostenlose Testphase starten

Keine Kreditkarte erforderlich. Legen Sie sofort los.

Ihr Daten-Template für den Behandlungsverlauf

Ihr Daten-Template für den Behandlungsverlauf

Attribute zum Behandlungsverlauf

Aktivitäten im Behandlungsverlauf

Anleitungen zur Datenextraktion

Export des Event Logs aus der Allscripts Interface Engine

Schritte

Konfiguration

Beispielabfrage config

Datenextraktion über die Veradigm Unity API mit Python

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie noch heute die Patientenreise in Veradigm