> Kontinuierliche Prozessoptimierung > Patientenreise > Veradigm (Allscripts) > Datenvorlage

Ihre Patientenreise-Datenvorlage

Veradigm (Allscripts)

Patientenreise-Attribute (20) Patientenreise-Aktivitäten (13) Extraktionsleitfäden (2)

Ihre Patientenreise-Datenvorlage

Diese Vorlage bietet einen strukturierten Ansatz zur Erfassung der notwendigen Daten für die Analyse Ihres Patientenreise-Prozesses. Sie skizziert die wesentlichen Attribute und Aktivitäten, die verfolgt werden sollen, sowie praktische Anleitungen zur Extraktion dieser Informationen aus Ihrem Quellsystem. Nutzen Sie diese Ressource, um Ihre Daten für ein umfassendes Process Mining vorzubereiten.

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

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

Vorlage herunterladen

Patientenreise-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log für eine umfassende Analyse des Patientenreise-Prozesses enthalten sein sollten.

3 Erforderlich 9 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das spezifische klinische oder administrative Event, das durchgeführt wurde.
Beschreibung Beschreibt den im Prozess durchgeführten Schritt, wie 'Patient Registered', 'Medication Administered' oder 'Discharge Planning Initiated'. Dieses Attribut differenziert die verschiedenen Phasen der Patientenreise und ist wesentlich für die Prozesserkennung und Variantenanalyse. Bedeutung Definiert die Knoten in der Prozesskarte; ohne diese kann kein Prozessfluss visualisiert werden. Datenquelle Abgeleitet aus verschiedenen Transaktionstabellen: ADT Events, Orders, Results und Clinical Documentation Tables. Beispiele Patient registriertDiagnostic Test OrderedMedikation verabreichtPatient entlassen
	Ereignis-Timestamp EventDateTime	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Zeichnet den chronologischen Zeitpunkt der Aktivität auf. Dies ist entscheidend für die Berechnung von Zykluszeiten, Dauern und die korrekte Reihenfolge der Ereignisse. In Gesundheitsdaten ist die minutengenaue Präzision für eine genaue Durchsatzanalyse unerlässlich. Bedeutung Ermöglicht die Berechnung aller zeitbasierten KPIs, einschließlich der durchschnittlichen Zykluszeit der Patientenreise und der Wartezeiten. Datenquelle Transaktions-Timestamps in Quelltabellen (z.B. ADT_DATE, ORDER_DATE, RESULT_DATE). Beispiele 2023-10-12T08:30:00Z2023-10-12T14:45:22Z2023-10-15T09:00:00Z
	Patientenepisode PatientEpisodeId	Eindeutiger Identifikator für den spezifischen Patientenbesuch oder Encounter.
Beschreibung Die Patientenepisode dient als primärer Case-Identifier, der alle Events im Zusammenhang mit der spezifischen Gesundheitsreise eines Patienten für einen bestimmten Zustand oder eine bestimmte Pflegeperiode gruppiert. Dies ermöglicht eine integrierte Sicht auf Diagnose-, Behandlungs- und Genesungsphasen, indem verschiedene Abteilungsinteraktionen zu einem kohärenten Ganzen verbunden werden. In Veradigm (Allscripts) Systemen (wie Sunrise oder Paragon) entspricht dies normalerweise der Visit ID oder Encounter Number. Bedeutung Es ist der grundlegende Schlüssel für Process Mining, da er die Rekonstruktion der vollständigen Patientenreise ermöglicht. Datenquelle Wahrscheinlich in der Kopfzeile der Besuchs- oder Begegnungstabellen zu finden (z.B. VISIT_ID, ENCOUNTER_ID). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele EP-2023-998877VIS-10029384100029384ENC-554433
	Abteilungsname DepartmentName	Die Krankenhauseinheit oder Abteilung, in der die Aktivität stattfand.
Beschreibung Gibt den Standortkontext an, wie 'Emergency Room', 'Cardiology' oder 'Radiology'. Dies ist entscheidend für die 'Aufnahme- und Verlegungsengpassanalyse', um zu sehen, wo Patienten beim Wechsel zwischen Stationen stecken bleiben. Bedeutung Unterstützt die Analyse der Ressourcennutzung und die Identifizierung von Engpässen in Abteilungen. Datenquelle Stammtabellen für Standort oder Abteilung, die mit der Transaktion verknüpft sind. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele Emergency DepartmentICUGeneral SurgeryRadiologie
	Admission Date AdmissionDate	Das Datum und die Uhrzeit der formellen Aufnahme des Patienten.
Beschreibung Der Timestamp, der den Beginn des stationären Aufenthalts markiert. Wird in Verbindung mit dem Entlassungsdatum verwendet, um die Verweildauer (ALOS) zu berechnen. Bedeutung Kritischer Ankerpunkt für die ALOS-Berechnung und die Messung von Aufnahmeverzögerungen. Datenquelle Besuchs-/Encounter-Kopfzeilentabelle (z.B. ADMIT_DATE). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-10-01T10:00:00Z2023-10-05T14:20:00Z
	Attending Provider AttendingProvider	Der primäre Kliniker, der für den Patienten während des Events verantwortlich ist.
Beschreibung Identifiziert den Arzt, die Pflegekraft oder den Spezialisten, der die Aktivität durchführt oder für den Behandlungsplan verantwortlich ist. Die Analyse dieses Attributs hilft beim Verständnis der 'Clinical Resource Utilization' und Variationen in Behandlungspfaden nach Arzt. Bedeutung Ermöglicht die Analyse von Ressourcenengpässen und Performance Benchmarking für klinisches Personal. Datenquelle Transaktionstabellen (z.B. ORDERing_PROVIDER, ATTENDING_PHYSICIAN_ID). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele Dr. Sarah SmithNurse Practitioner JonesRadiology Tech A
	Discharge Disposition DischargeDisposition	Der Status oder Ort des Patienten bei der Entlassung.
Beschreibung Gibt an, wohin der Patient nach dem Krankenhausaufenthalt ging (z.B. 'Home', 'Skilled Nursing Facility', 'Expired', 'Transfer'). Dies ist wichtig für die Analyse von Wiederaufnahmerisiken, da verschiedene Entlassungsarten unterschiedliche Risikoprofile aufweisen. Bedeutung Kontextualisiert das 'Discharge Planning' Dashboard und hilft, Varianzen im ALOS zu erklären. Datenquelle Besuchs-/Encounter-Kopfzeilentabelle (z.B. DISCH_DISP). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele StartseiteIn SNF verlegtHome with Home HealthEntlassung gegen ärztlichen Rat
	Erfüllungsdatum DischargeDate	Das Datum und die Uhrzeit der Entlassung des Patienten.
Beschreibung Der Timestamp, der das Ende der Episode markiert. Dies wird verwendet, um den Case im Process Mining abzuschließen und ist essentiell für ALOS- und Wiederaufnahmeberechnungen. Bedeutung Definiert das Ende des Prozesszyklus; entscheidend für die Durchsatzanalyse. Datenquelle Besuchs-/Encounter-Kopfzeilentabelle (z.B. DISCH_DATE). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-10-04T11:00:00Z2023-10-10T09:30:00Z
	Is Readmission IsReadmission	Flag, das anzeigt, ob diese Episode eine Wiederaufnahme innerhalb von 30 Tagen ist.
Beschreibung Ein berechnetes boolesches Attribut. Es gibt True zurück, wenn der Patient innerhalb von 30 Tagen vor dem aktuellen Aufnahmedatum entlassen wurde. Dies speist den 'Avoidable Readmission Rate Monitor'. Bedeutung Kern-KPI für Krankenhausqualität und Kostenerstattung (insbesondere für CMS-Vorschriften). Datenquelle Berechnet in der ETL-/Daten-Transformationsschicht unter Verwendung von PatientMRN und Aufnahme-/Entlassungsdaten. Beispiele truefalsch
	Patienten MRN PatientMrn	Medizinische Aktennummer, die den Patienten über Episoden hinweg eindeutig identifiziert.
Beschreibung Die medizinische Aktennummer (MRN) oder die Patienten-ID des Unternehmens. Im Gegensatz zur Patientenepisoden-ID bleibt diese ID für den Patienten über verschiedene Besuche hinweg konstant. Dies ist der entscheidende Schlüssel zur Verknüpfung separater Episoden, um Wiederaufnahmeraten zu berechnen. Bedeutung Essentiell für die '30-Tage-Wiederaufnahmerate' und die Identifizierung von Wiederholungspatienten. Datenquelle Patientenstammdaten oder demografische Tabellen (wahrscheinliche Spalten: MRN, PATIENT_ID). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele MRN-884422P-10022399887766
	Primärdiagnosecode PrimaryDiagnosisCode	Der ICD-10- oder SNOMED-Code, der die Hauptbedingung darstellt.
Beschreibung Der kodierte Grund für den Patientenbesuch. Dieses Attribut dient als Filter für den 'Explorer für Behandlungspfadabweichungen'. Es ermöglicht Analysten zu vergleichen, wie verschiedene Zustände (z.B. Lungenentzündung vs. Herzinsuffizienz) durch das System fließen. Bedeutung Erforderlich für die Segmentierung von Prozessen nach klinischem Zustand und die Überprüfung der Protokolleinhaltung. Datenquelle Diagnose- oder Problemlistentabellen (typischerweise ICD-10-Spalten). Konsultieren Sie die Veradigm (Allscripts)-Dokumentation. Beispiele I50.9J18.9E11.9
	Verweildauer LengthOfStay	Dauer des Krankenhausaufenthalts in Tagen.
Beschreibung Die berechnete Dauer zwischen 'Aufnahmedatum' und 'Entlassungsdatum'. Wird für den KPI 'Durchschnittliche Verweildauer (ALOS)' verwendet. Obwohl es im Dashboard berechnet werden kann, vereinfacht es als Attribut die Filterung (z.B. 'Zeige mir alle Aufenthalte > 7 Tage'). Bedeutung Standardmaß für Effizienz und Ressourcenverbrauch. Datenquelle Calculated: DischargeDate - AdmissionDate. Beispiele 4.512.00.8
	Auftrags-ID OrderId	Identifikator für spezifische Aufträge (Labs, Meds, Procedures).
Beschreibung Verbindet das Event 'Bestellung' mit dem Event 'Ergebnis' oder 'Verabreichung'. Beispielsweise die Verknüpfung von 'Diagnosetest bestellt' mit 'Diagnosetest abgeschlossen'. Diese Granularität ist für das Dashboard 'Bearbeitungszeit Diagnose' erforderlich. Bedeutung Ermöglicht die Berechnung der Dauer spezifischer Prozessschritte (z. B. Labordurchlaufzeit). Datenquelle Bestelleingabetabellen (z.B. ORDER_ID, PLACER_ORDER_NUM). Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele ORD-998877LAB-112233RX-445566
	Diagnostische Durchlaufzeit DiagnosticTurnaroundTime	Zeitdauer zwischen Testbestellung und Testergebnis.
Beschreibung Berechnete Dauer zwischen 'Diagnostic Test Ordered' und 'Diagnosis Confirmed' (oder erhaltenem Ergebnis). Verwendet für die 'Diagnostic Turnaround Time Overview'. Bedeutung Hohe Durchlaufzeiten verlängern die Verweildauer; diese Metrik identifiziert Labor-/Radiologieverzögerungen. Datenquelle Calculated: Timestamp(Result) - Timestamp(Order). Beispiele 2 Stunden45 Minuten1.5 Tage
	Follow-up Appt Date FollowUpAppointmentDate	Datum des geplanten Nachsorgetermins.
Beschreibung Wird verwendet, um die 'Rate der geplanten Nachsorgetermine' zu berechnen. Wenn dieses Feld ausgefüllt ist, zeigt es an, dass eine Nachsorge geplant wurde. Ist es null/leer, wurde keine geplant. Bedeutung Misst direkt den 'Follow-up Care Compliance' KPI. Datenquelle Terminplanungssystem oder zukünftige Termintabelle, die mit dem Patienten verknüpft ist. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele 2023-11-15T14:00:00Znull
	Is Protocol Compliant IsProtocolCompliant	Flag, das anzeigt, ob der Fall dem Standard-Behandlungspfad gefolgt ist.
Beschreibung Ein berechnetes Attribut, das prüft, ob spezifische obligatorische Aktivitäten (z.B. 'Vitals Recorded' vor 'Medication Administered') in der richtigen Reihenfolge auftraten. Unterstützt das 'Care Protocol Adherence Dashboard'. Bedeutung Automatisiert die Erkennung von Non-Compliance ohne manuelle Aktenprüfung. Datenquelle Berechnet im Process Mining Tool oder ETL basierend auf der Aktivitätssequenz. Beispiele truefalsch
	Kostenstelle CostCenter	Der Finanzcode, der der Abteilung oder Dienstleistung zugeordnet ist.
Beschreibung Ordnet die klinische Aktivität einer finanziellen Einheit zu. Dies hilft bei der Analyse der 'Aktivitätskosten' oder der generischen finanziellen Leistung verschiedener Abteilungen. Bedeutung Verbindet operatives Process Mining mit finanziellen Auswirkungen. Datenquelle Abteilungs- oder Kostenstellentabellen. Konsultieren Sie die Veradigm (Allscripts)-Dokumentation. Beispiele CC-1020CC-Rad-01Emergency-001
	Letzte Datenaktualisierung LastDataUpdate	Timestamp, wann der Datensatz zuletzt extrahiert oder aktualisiert wurde.
Beschreibung Gibt die Aktualität der für die Analyse verwendeten Daten an. Dieses Feld hilft Benutzern zu verstehen, ob sie Echtzeitdaten oder eine Momentaufnahme aus einem früheren Zeitraum betrachten. Bedeutung Gewährleistet Transparenz hinsichtlich der Datenlatenz und unterstützt inkrementelle Datenladestrategien. Datenquelle Systemgenerierter Timestamp während des ETL-/Extraktionslaufs. Beispiele 2023-11-01T23:59:59Z2023-11-02T06:00:00Z
	Medikamentenname MedicationName	Der Name des bestellten oder verabreichten Medikaments.
Beschreibung Wird speziell für das Dashboard 'Medikamentenverabreichungs-Zeitlücken' verwendet. Es hilft zu identifizieren, ob spezifische Medikamente (z.B. Antibiotika, Schmerzmittel) Verabreichungsverzögerungen aufweisen. Bedeutung Entscheidend für die klinische Sicherheitsanalyse und Apothekenprozessoptimierung. Datenquelle Medikationsverabreichungsaufzeichnung (MAR) oder Apothekenbestellungen. Konsultieren Sie die Dokumentation von Veradigm (Allscripts). Beispiele AmoxicillinHeparinMorphine Sulfate
	Quellsystem SourceSystem	Der Name des Systems, aus dem die `data` stammen.
Beschreibung Identifiziert die Software-Instanz, die die Daten bereitstellt, wie 'Veradigm Sunrise' oder 'Veradigm TouchWorks'. Dies ist besonders wichtig in Umgebungen mit mehreren Krankenhäusern oder beim Zusammenführen von Daten aus akuten und ambulanten Settings. Bedeutung Bietet Rückverfolgbarkeit und Datenherkunft, was beim Debugging von Datenqualitätsproblemen nützlich ist. Datenquelle Hardcodiert während des ETL-Prozesses oder aus System-Metadaten-Tabellen extrahiert. Beispiele Veradigm SunriseAllscripts PMVeradigm TouchWorks

Erforderlich Empfohlen Optional

Patientenreise-Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die in Ihrem Event Log für eine präzise Patientenreise-Prozesserkennung erfasst werden sollten.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Behandlungsplan erstellt	Stellt die Formalisierung des Behandlungsplans eines Patienten durch das klinische Team dar. Dies wird oft erfasst, wenn ein spezifisches 'Pflegeplan'-Dokument oder eine Reihe von anfänglichen Behandlungsanordnungen im EHR erstellt und unterzeichnet wird.
Bedeutung Dieser Meilenstein leitet die aktive Behandlungsphase ein. Er ist die Grundlage für die Messung der Einhaltung von Behandlungsprotokollen und der Zeit bis zur ersten Behandlungsmaßnahme, wie der Medikamentenverabreichung. Datenquelle Abgeleitet vom Signatur-Timestamp eines 'Plan of Care'-Formulars oder dem Erstellungs-Timestamp des ersten großen Satzes therapeutischer Aufträge nach der Diagnose. Erfassen Finden Sie den Timestamp, wenn ein 'Plan of Care'-Dokument vom behandelnden Kliniker finalisiert oder unterzeichnet wird. Ereignistyp inferred
	Diagnosis Confirmed	Diese Aktivität signalisiert, dass ein Kliniker offiziell eine Diagnose in der Patientenakte erfasst hat. Dies kann erfasst werden, wenn ein Diagnosecode zur Problemliste hinzugefügt wird oder wenn eine klinische Notiz, die die Diagnose enthält, unterzeichnet wird.
Bedeutung Die Bestätigung der Diagnose ist ein entscheidender Wendepunkt, der den weiteren Behandlungspfad bestimmt. Sie ermöglicht die Analyse von Behandlungspfad-Variationen basierend auf verschiedenen Diagnosen. Datenquelle In der Problemliste des Patienten, den Begegnungsdiagnose-Datensätzen oder der klinischen Dokumentation gefunden. Es kann vom Timestamp abgeleitet werden, wenn ein primärer Diagnosecode für die Begegnung eingegeben und finalisiert wird. Erfassen Verwenden Sie den Erstellungs- oder Aktualisierungs-Timestamp des primären Diagnoseeintrags für die spezifische Patientenepisode. Ereignistyp inferred
	Discharge Planning Initiated	Stellt den formellen Beginn des Entlassungsplanungsprozesses für einen Patienten dar. Dies kann aus der Erstellung eines Entlassungsplans, der Platzierung eines Entlassungsauftrags oder dem Abschluss einer spezifischen Entlassungsplanungsbewertung abgeleitet werden.
Bedeutung Diese Aktivität ist der Ausgangspunkt für die Messung der Effizienz des Entlassungsprozesses. Eine frühzeitige Planungseinleitung korreliert oft mit niedrigeren Wiederaufnahmeraten. Datenquelle Abgeleitet vom Erstellungs-Timestamp einer Entlassungsplanungsnotiz, eines Entlassungsauftragssatzes oder eines spezifischen Bewertungsformulars innerhalb von Veradigm. Erfassen Identifizieren Sie den Timestamp, wenn ein entlassungsspezifischer Auftrag oder Dokument zum ersten Mal für die Patientenbegegnung erstellt wird. Ereignistyp inferred
	Initial Assessment Completed	Stellt den Abschluss der ersten klinischen Beurteilung durch eine Pflegekraft oder einen Arzt dar, z.B. Triage oder Erstaufnahme. Dies wird oft erfasst, wenn ein spezifisches klinisches Formular oder eine Notiz, wie eine 'Pflege-Erstbeurteilung', im EHR unterzeichnet und finalisiert wird.
Bedeutung Diese Aktivität ist ein wichtiger früher Meilenstein. Die Zeit zwischen Registrierung und dieser Beurteilung hebt potenzielle Verzögerungen bei der Patientenaufnahme und der Erstversorgung hervor. Datenquelle Abgeleitet vom Finalisierungs- oder Signatur-Timestamp von ersten Einschätzungsformularen oder klinischen Notizen innerhalb der klinischen Dokumentationsmodule von Veradigm. Erfassen Identifizieren Sie den Timestamp, wenn der Status der ersten Einschätzungsnotiz oder des Formulars auf 'completed' oder 'signed' geändert wird. Ereignistyp inferred
	Patient entlassen	Markiert das offizielle Ende des stationären Behandlungsfalls, wenn der Patient formell aus der Einrichtung entlassen wird. Dies ist ein explizites Schlüsselereignis, das vom ADT-System erfasst wird und den Encounter-Status des Patienten auf 'entlassen' aktualisiert.
Bedeutung Dies ist die primäre Endaktivität für die meisten Patientenreisen. Sie ist entscheidend für die Berechnung der durchschnittlichen Verweildauer (ALOS) und der gesamten Prozesszykluszeit. Datenquelle Explizit im ADT-Modul protokolliert. Der Patientenbegegnungsdatensatz enthält einen Entlassungs-Timestamp und die Entlassungsdisposition. Erfassen Verwenden Sie den Entlassungs-Timestamp aus dem Haupt-Encounter oder Besuchsdatensatz des Patienten. Ereignistyp explicit
	Patient registriert	Markiert den offiziellen Beginn der Patientenepisode, wenn die Patienteninformationen in das Veradigm-System eingegeben werden. Dieses Event wird typischerweise explizit erfasst, wenn ein Benutzer den Registrierungs-Workflow abschließt und einen neuen Patienten-Encounter-Datensatz mit einer eindeutigen Kennung und einem Timestamp erstellt.
Bedeutung Dies ist die primäre Startaktivität für die Patientenreise. Sie ist unerlässlich für die Berechnung der gesamten Prozesszykluszeit, der Verweildauer und der Patientendurchsatzraten. Datenquelle Dieses Event wird im Patientenregistrierungs- oder ADT (Aufnahme, Entlassung, Transfer)-Modul erfasst. Suchen Sie nach dem Erstellungs-Timestamp des Patienten-Encounters oder Besuchsdatensatzes. Erfassen Timestamp aus der Patienten-Encounter- oder Registrierungstabelle bei Datensatz-Erstellung. Ereignistyp explicit
	Diagnostic Test Completed	Stellt den Zeitpunkt dar, an dem die Ergebnisse eines Diagnosetests finalisiert und in der Patientenakte verfügbar gemacht werden. Dies wird typischerweise aus einer Statusänderung der ursprünglichen Bestellung von 'aktiv' oder 'in Bearbeitung' zu 'abgeschlossen' oder 'mit Ergebnis' abgeleitet.
Bedeutung Diese Aktivität ist ein kritischer Meilenstein zur Messung der Bearbeitungszeiten von Diagnosen. Verzögerungen zwischen Bestellung und Abschluss können die Zeit bis zur Diagnose erheblich beeinflussen. Datenquelle Abgeleitet vom Auftragsstatusfeld im Auftragsmodul oder von Timestamps in den entsprechenden Ergebnismodulen, wie LIS oder RIS. Erfassen Identifizieren Sie den Timestamp, wenn der Auftragsstatus in einen Endzustand wie 'Completed' oder 'Resulted' wechselt. Ereignistyp inferred
	Diagnostic Test Ordered	Dieses Event tritt auf, wenn ein Kliniker eine Bestellung für einen Diagnosetest aufgibt, wie z.B. einen Labortest oder eine Bildgebung. Es wird explizit über das Computerized Physician Order Entry (CPOE)-System innerhalb von Veradigm erfasst.
Bedeutung Dies markiert den Beginn des diagnostischen Teilprozesses. Sie ist der Ausgangspunkt für die Messung der diagnostischen Bearbeitungszeiten und die Identifizierung von Verzögerungen bei der Bestellung von Prozeduren. Datenquelle Erfasst im Bestellmodul oder in den CPOE-Systemprotokollen. Jede Bestellung hat einen Timestamp, der angibt, wann sie platziert wurde. Erfassen Extrahieren Sie den Erstellungs-Timestamp aus den Auftragseintragsdatensätzen für relevante diagnostische Tests. Ereignistyp explicit
	Follow-up Scheduled	Diese Aktivität repräsentiert die Terminplanung eines Nachsorgetermins für den Patienten nach der Entlassung. Dieses Event wird im Terminplanungsmodul erfasst, wenn ein Termin gebucht wird, der mit dem entlassenen Encounter verknüpft ist.
Bedeutung Die Sicherstellung der Terminierung von Nachsorge ist entscheidend für die Kontinuität der Versorgung und die Reduzierung von Wiederaufnahmen. Diese Aktivität hilft, die Compliance mit Nachsorgeprotokollen zu messen. Datenquelle Erfasst im Terminplanungsmodul. Suchen Sie nach dem Erstellungs-Timestamp eines neuen Termins für den Patienten, der nach dem Entlassungsdatum liegt. Erfassen Identifizieren Sie den Erstellungs-Timestamp eines Terminplansatzes im Planungssystem, der mit dem Patienten verknüpft ist. Ereignistyp explicit
	Medikation verabreicht	Dieses Event wird erfasst, wenn eine Pflegekraft oder ein Kliniker die Verabreichung eines Medikaments an den Patienten dokumentiert. Dies wird in der Medikationsverabreichungsaufzeichnung (MAR) oder dem eMAR-Modul erfasst, das die genaue Uhrzeit der Verabreichung protokolliert.
Bedeutung Die Verfolgung der Medikamentenverabreichung ist entscheidend für die Analyse der Behandlungszeit und -adhärenz. Die Lücke zwischen Bestellung und Verabreichung hilft, Verzögerungen im Medikamentenlieferprozess zu identifizieren. Datenquelle Explizit im eMAR-Modul (elektronisches Medikationsverabreichungsregister) protokolliert. Jedes Verabreichungsereignis hat einen spezifischen Timestamp, Medikament und Dosierung. Erfassen Extrahieren Sie Timestamps aus der eMAR-Tabelle für jedes Medikationsverabreichungsereignis, das mit der Patientenbegegnung verknüpft ist. Ereignistyp explicit
	Prozedur durchgeführt	Stellt den Abschluss eines klinischen oder chirurgischen Eingriffs dar. Dies wird typischerweise erfasst, wenn ein Kliniker die Prozedurnotiz unterzeichnet oder wenn der Status des Prozedurauftrags im System auf 'abgeschlossen' aktualisiert wird.
Bedeutung Prozeduren sind wichtige Meilensteine in vielen Patientenreisen. Die Analyse ihres Timings hilft, die Ressourcennutzung und die Planungseffizienz zu verstehen. Datenquelle Abgeleitet vom Signatur-Timestamp einer Prozedurnotiz im klinischen Dokumentationsmodul oder dem Abschluss-Timestamp im Auftragsmodul für diese Prozedur. Erfassen Verwenden Sie den Abschluss-Timestamp aus dem Prozedurauftrag oder den Unterschriften-Timestamp aus der zugehörigen Prozedurdokumentation. Ereignistyp inferred
	Verlegung in Abteilung	Dieses Event markiert die physische Verlegung eines Patienten von einer Abteilung oder Pflegeeinheit in eine andere, wie z.B. von der Notaufnahme auf eine stationäre Station. Dies wird vom ADT (Aufnahme, Entlassung, Transfer)-System innerhalb von Veradigm erfasst.
Bedeutung Patientenverlegungen sind häufige Punkte für Engpässe und Verzögerungen. Die Analyse der Dauer und Häufigkeit von Verlegungen hilft, den Patientenfluss und die Ressourcenallokation zwischen Abteilungen zu optimieren. Datenquelle Explizit im ADT-Modul protokolliert. Jedes Verlegungsereignis umfasst den Patienten, Von-/Zu-Standorte und einen Timestamp. Erfassen Extrahieren Sie Event Logs aus dem ADT-System, die Patientenbewegungen entsprechen. Ereignistyp explicit
	Vitalparameter erfasst	Diese Aktivität tritt jedes Mal auf, wenn die Vitalparameter eines Patienten, wie Herzfrequenz, Blutdruck und Temperatur, erfasst werden. Dies ist ein explizites Event, das in der klinischen Dokumentation oder im vitalparameter-spezifischen Flowsheet-Bereich des EHR erfasst wird.
Bedeutung Regelmäßige Erfassung von Vitaldaten deutet auf eine aktive Patientenüberwachung hin. Die Häufigkeit und der Zeitpunkt können analysiert werden, um die Compliance mit Überwachungsprotokollen sicherzustellen. Datenquelle Erfasst im klinischen Datenrepository oder in Flussdiagramm-Tabellen, wo Vitalparameter gespeichert sind. Jeder Eintrag hat einen Timestamp. Erfassen Extrahieren Sie Timestamps aus den Vitalzeichen-Flowsheet-Daten für die Patientenbegegnung. Ereignistyp explicit

Extraktionsleitfäden

Wie Sie Ihre Daten aus Veradigm (Allscripts) erhalten

Schritte

Identify the Target Interface Channel: Melden Sie sich bei der Allscripts Interface Engine (AIE) Management Console an. Suchen Sie den primären Schnittstellenkanal, der eingehende Nachrichten vom EHR verarbeitet (typischerweise als 'EHR_Inbound' oder ähnlich bezeichnet). Stellen Sie sicher, dass dieser Kanal ADT-, SIU-, ORM-, ORU-, RAS- und DFT-Nachrichtentypen verarbeitet, um den gesamten Umfang der Patientenreiseaktivitäten zu erfassen.
Create a New Passthrough/Export Channel: Erstellen Sie einen neuen Zielkanal namens 'ProcessMining_Export'. Stellen Sie den Ausgabetyp auf 'Dateischreiber' ein. Dieser Kanal empfängt eine Kopie der Nachrichten vom Quellkanal und transformiert sie in ein flaches Dateiformat (CSV) für ProcessMind.
Configure Message Routing: Konfigurieren Sie in den AIE-Routing-Regeln eine Kopier-/Routing-Regel, um Nachrichten vom primären EHR-Kanal an den neuen 'ProcessMining_Export'-Kanal zu senden. Filtern Sie das Routing, um nur die notwendigen Nachrichtentypen einzuschließen: ADT (Registrierung/Verlegung), SIU (Terminplanung), ORM (Aufträge), ORU (Ergebnisse/Vitalwerte), RAS (Medikamente) und DFT (Abrechnung/Prozeduren).
Define the Transformation Logic: Öffnen Sie im 'ProcessMining_Export'-Kanal den Transformations-/Skripteditor. Sie müssen ein Parsing-Skript implementieren (siehe Abschnitt 'query' unten), das die rohen HL7-Segmente liest und spezifische Trigger Events und Statuscodes den erforderlichen Standard-Activity Names zuordnet (z.B. Zuordnung von 'ADT^A01' zu 'Patient Registered').
Map Attributes to HL7 Fields: Stellen Sie sicher, dass das Skript die 'PatientEpisodeId' aus dem PV1-19-Segment (Besuchsnummer) und 'PatientMrn' aus PID-3 extrahiert. Ordnen Sie das 'EventDateTime' MSH-7 oder EVN-2 zu. Extrahieren Sie klinische Details wie 'DepartmentName' aus PV1-3 und 'AttendingProvider' aus PV1-7.
Set Output File Parameters: Konfigurieren Sie die Dateischreiber-Einstellungen. Legen Sie das Ausgabeverzeichnis auf einen sicheren Netzwerkpfad fest. Definieren Sie die Dateibenennungskonvention (z.B. EventLog_YYYYMMDD_HH.csv). Stellen Sie den Dateimodus auf 'Anhänge' ein, um kontinuierlich Zeilen zum Log hinzuzufügen.
Handle Delimiters and Escaping: Stellen Sie im Skript sicher, dass Textfelder (wie Diagnose oder Abteilungsname) bereinigt werden, um Kommas oder Zeilenumbrüche zu entfernen und so ein Brechen der CSV-Struktur zu verhindern.
Activate and Test: Starten Sie den 'ProcessMining_Export'-Kanal. Lösen Sie ein Testereignis in der Veradigm-Testumgebung aus (z.B. registrieren Sie einen Testpatienten). Überprüfen Sie, ob eine neue Zeile in der CSV-Datei mit dem korrekten Activity Name und Timestamp erscheint.
Configure Log Rotation: Richten Sie einen Rotationsplan ein (z.B. täglich um Mitternacht), um die aktuelle CSV-Datei zu schließen und eine neue zu starten. Dies stellt sicher, dass die Dateien für den Upload eine handhabbare Größe haben.
Historical Data Replay (Optional): Falls historische Daten benötigt werden, verwenden Sie das AIE 'Message Browser'- oder 'Log Replay'-Tool, um archivierte HL7-Logs der letzten 3-6 Monate über den 'ProcessMining_Export'-Kanal erneut zu senden. Überwachen Sie die System-Performance, um Verzögerungen zu vermeiden.
Retrieve and Format: Greifen Sie auf das Ausgabeverzeichnis zu, rufen Sie die generierten CSV-Dateien ab und überprüfen Sie, ob die Header den Anforderungen entsprechen. Kombinieren Sie tägliche Dateien bei Bedarf.
Upload to ProcessMind: Importieren Sie den finalen Datensatz in ProcessMind und ordnen Sie 'PatientEpisodeId' als Case ID, 'ActivityName' als Activity und 'EventDateTime' als Timestamp zu.

Konfiguration

Channel Type: Dateischreiber / Dateisystemausgabe
Trigger Events: ADT^A01, ADT^A03, ADT^A04, ADT^A08, SIU^S12, ORM^O01, ORU^R01, RAS^O17, DFT^P03
File Encoding: UTF-8 (Entscheidend für Sonderzeichen in Namen/Diagnosen)
Delimiter: Komma (,) oder Pipe (|)
Date Format: ISO 8601 (JJJJ-MM-TTHH:MM:SS) empfohlen für HL7 Timestamp-Konvertierung
Log Rotation: Täglich oder wenn die Dateigröße 100MB überschreitet
Write Mode: Anhängen (Nicht überschreiben)
Performance: Stellen Sie sicher, dass das Transformationsskript schlank ist, um Nachrichtenwarteschlangen/Rückstände in der Engine zu verhindern.

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

Prerequisites and Access: Stellen Sie sicher, dass Sie über gültige Zugangsdaten für die Veradigm (Allscripts) Unity API verfügen. Sie benötigen einen Appname (Anwendungsname), der für Ihre Organisation autorisiert ist, zusammen mit einer gültigen UserID und einem Password (oder Token) zur Authentifizierung. Vergewissern Sie sich, dass das Benutzerkonto Berechtigungen für den Zugriff auf klinische Domänen (Encounters, Orders, Results, Vitals, Problems) besitzt.
Environment Setup: Installieren Sie Python 3.8 oder höher. Installieren Sie die erforderlichen Bibliotheken mittels pip: pip install requests pandas. Diese werden für HTTP-Anfragen an die Unity API und die Bearbeitung der resultierenden Daten verwendet.
Configuration: Öffnen Sie das bereitgestellte Python-Skript. Suchen Sie den Abschnitt CONFIGURATION am Anfang. Aktualisieren Sie die API_URL, um auf den spezifischen Unity-Umgebungsendpunkt (z.B. unity.veradigm.com oder ein internes Gateway) zu verweisen. Ersetzen Sie die Platzhalter-Zugangsdaten ([YourAppName], [YourUserID], etc.) durch Ihre tatsächlichen Zugangsdaten. Setzen Sie das START_DATE und END_DATE auf Ihr gewünschtes Analysefenster.
Script Logic Overview: Das Skript funktioniert, indem es sich zuerst bei der API authentifiziert, um ein Sicherheitstoken zu erhalten. Anschließend ruft es GetEncounterInfo auf, um alle Patient Episoden innerhalb des angegebenen Datumsbereichs abzurufen. Diese Liste von Encounters dient als zentraler Iterator für die Extraktion.
Activity Extraction Loop: Für jede identifizierte EncounterID führt das Skript sekundäre API-Aufrufe an spezialisierte Endpunkte durch. Es ruft GetOrders auf, um diagnostische Tests und Prozeduren zu finden. Es ruft GetResults auf, um abgeschlossene Tests zu identifizieren. Es ruft GetVitals für Vitalzeichenaufzeichnungen auf. Es ruft GetPatientProblems für bestätigte Diagnosen auf. Es iteriert durch klinische Notizen, um Einschätzungen und Behandlungspläne zu finden.
Data Transformation: Wenn rohe JSON-Daten von der API zurückgegeben werden, parst das Skript spezifische Felder, um sie dem ProcessMind-Schema zuzuordnen. Zum Beispiel wird OrderDateTime dem EventDateTime für die Aktivität 'Diagnostic Test Ordered' zugeordnet. Das Skript stellt sicher, dass die PatientEpisodeId (Encounter ID) konsistent auf alle untergeordneten Datensätze angewendet wird.
Handling ADT and Transfers: Die Skriptlogik beinhaltet eine Überprüfung der Standort-Historie des Encounters (falls über spezifische Audit- oder ADT-Unteraufrufe verfügbar) oder leitet Verlegungen basierend auf Abteilungsänderungen in der klinischen Dokumentation ab, um 'Transfer to Department'-Events zu generieren.
Follow-up Logic: Nach der Verarbeitung des Encounters fragt das Skript GetSchedule für dieselbe PatientID ab und sucht nach Termindaten, die nach dem DischargeDate liegen, um die Aktivität 'Follow-up Scheduled' zu generieren.
Validation: Das Skript enthält einen lokalen Validierungsschritt, der die Anzahl der Zeilen pro Aktivitätstyp in der Konsole ausgibt. Überprüfen Sie diese Ausgabe, um sicherzustellen, dass keine Aktivitätstypen null Datensätze aufweisen (es sei denn, dies ist erwartet).
Export: Der finale Datensatz wird in einem Pandas DataFrame aggregiert. Das Skript berechnet abgeleitete Attribute wie LengthOfStay und IsReadmission durch Sortieren der Daten nach Patient und Zeit. Schließlich exportiert es das saubere Event Log in eine CSV-Datei namens veradigm_patient_journey_log.csv.
Final Review: Öffnen Sie die generierte CSV-Datei. Überprüfen Sie, dass die Datumsformate ISO 8601 (JJJJ-MM-TT HH:MM:SS) sind und dass Textfelder wie ActivityName keine Trennzeichen enthalten.
Upload: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie PatientEpisodeId der Case ID, ActivityName der Activity und EventDateTime dem Timestamp zu.

Konfiguration

API_URL: Die Basis-URL für die Unity API-Services. Diese variiert je nach Client-Installation (z.B. On-Premise vs. Cloud). Stellen Sie sicher, dass das Protokoll (https) korrekt ist.
Appname: Der eindeutige Anwendungsidentifikator, der bei Veradigm/Allscripts registriert ist. Dieser steuert den Umfang des Datenzugriffs.
Date Range: Das empfohlene Extraktionsfenster beträgt 3-6 Monate. Große Bereiche können zu einem Timeout führen; erwägen Sie eine monatliche Aufteilung, wenn das Volumen hoch ist.
Timeout Settings: Das Skript verwendet einen Standard-Timeout von 30 Sekunden für API-Aufrufe. Erhöhen Sie diesen, wenn das EHR-System stark ausgelastet ist.
Batching: Das Skript iteriert pro Encounter. Bei Systemen mit hohem Volumen kann es notwendig sein, das Skript zu ändern, um Daten in großen Mengen abzurufen (falls Endpunkte dies zulassen) oder parallele Threads auszuführen.
Mapping Logic: Das Skript ordnet 'OrderType' Aktivitäten zu. Stellen Sie sicher, dass die spezifischen Auftragstypcodes Ihres Systems (z.B. 'Lab', 'Rad') mit der Logik in der process_orders-Funktion übereinstimmen.

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()

Ihre Patientenreise-Datenvorlage

Ihre Patientenreise-Datenvorlage

Patientenreise-Attribute

Patientenreise-Aktivitäten

Extraktionsleitfäden

Allscripts Interface Engine Event-Log-Export

Schritte

Konfiguration

a Beispielabfrage config

Veradigm Unity API Extraction via Python

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Patientenreisen in Veradigm noch heute optimieren

Ihre Patientenreise-Datenvorlage

Ihre Patientenreise-Datenvorlage

Patientenreise-Attribute

Patientenreise-Aktivitäten

Extraktionsleitfäden

Allscripts Interface Engine Event-Log-Export

Schritte

Konfiguration

a Beispielabfrage config

Veradigm Unity API Extraction via Python

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Patientenreisen in Veradigm noch heute optimieren