> Kontinuierliche Prozessverbesserung > Patientenpfad > athenahealth > Daten Template

Ihr Daten-Template für die Patientenreise

athenahealth

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

Ihr Daten-Template für die Patientenreise

Dieses Template bietet eine umfassende Anleitung zur Erfassung der erforderlichen Daten für die Analyse Ihrer Patientenreise. Es beschreibt die wesentlichen Attribute und Aktivitäten, die Sie erfassen sollten, und zeigt klar, wie Sie diese Informationen aus athenahealth extrahieren. Verwenden Sie diese Ressource, um Ihre Daten für ein wirksames Process Mining vorzubereiten.

Empfohlene zu erfassende Attribute
Wichtige zu erfassende Aktivitäten
Anleitung zur Datenextraktion aus athenahealth

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

Template herunterladen

Attribute des Patientenpfads

Dies sind die empfohlenen Datenfelder für Ihr Event Log. Sie sind für eine umfassende Analyse und ein klares Verständnis Ihrer Patientenpfade entscheidend.

5 Erforderlich 9 Empfohlen 5 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des Ereignisses oder der Aufgabe, die im Patientenpfad ausgeführt wird.
Beschreibung Bezeichnet den konkreten Prozessschritt, etwa „Patient eingecheckt“, „Diagnostische Untersuchung angeordnet“ oder „Medikament verabreicht“. Diese Zeichenfolge definiert die Knoten in der Prozessdarstellung. Sie wird verwendet, um den Prozessfluss zu visualisieren und die Abfolge der Vorgänge zu erkennen. Einheitliche Bezeichnungen sind entscheidend für eine übersichtliche und gut lesbare Prozessdarstellung ohne unnötige Gruppierungen. Warum das wichtig ist Definiert die Schritte der Prozessdarstellung und ist für jedes Process Mining erforderlich. Bezugsquelle Abgeleitet aus Audit Logs, Statusänderungen von Terminen oder Beschreibungen einzelner Abrechnungspositionen. Beispiele Termin vereinbartPatient eingechecktDiagnostische Untersuchung angeordnetPatient entlassen
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Erfasst den exakten Zeitpunkt einer Aktivität. Damit werden Ereignisse chronologisch geordnet und Zeitspannen zwischen den einzelnen Schritten berechnet. Der Timestamp ist für zeitbasierte Analysen entscheidend, darunter Durchlaufzeiten, Wartezeiten und Durchsatzanalysen. Eine hohe Genauigkeit ist vorzuziehen, damit die Reihenfolge von Ereignissen am selben Tag eindeutig bestimmt werden kann. Warum das wichtig ist Erforderlich, um Ereignisse zu ordnen und alle zeitbasierten KPIs zu berechnen. Bezugsquelle Timestamp-Felder, die in athenahealth-Tabellen mit Statusänderungen oder Erstellungsdaten verknüpft sind. Beispiele 2023-10-12T08:30:00Z2023-10-12T09:15:22Z2023-10-15T14:20:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten zuletzt extrahiert oder aktualisiert wurden.
Beschreibung Zeigt, wie aktuell die für die Analyse verwendeten Daten sind. So können Benutzer erkennen, ob sie Echtzeitdaten oder eine historische Momentaufnahme betrachten. Das Attribut dient der Steuerung von Datenpipelines und stellt sicher, dass Dashboards den aktuellen Stand des Prozesses abbilden. Warum das wichtig ist Entscheidend für Data Governance und das Vertrauen der Benutzer in die Aktualität des Dashboards. Bezugsquelle Systemzeit zum Zeitpunkt der ETL-Ausführung. Beispiele 2023-11-01T12:00:00Z2023-11-02T06:00:00Z
	Patientenepisode PatientEpisodeId	Eindeutige Kennung für die spezifische Patientenepisode oder den Patientenpfad.
Beschreibung Dieses Attribut dient als zentrale Case-Kennung und fasst alle Aktivitäten zusammen, die zu einem bestimmten Versorgungszeitraum oder Krankheitsbild eines Patienten gehören. Es verbindet unterschiedliche Ereignisse wie Termine, diagnostische Aufträge und Entlassungsverfahren zu einem zusammenhängenden Patientenpfad. In der Analyse ist diese ID der Primärschlüssel für Process Mining und ermöglicht die Rekonstruktion des Ablaufs von Anfang bis Ende. Dadurch werden mehrere Besuche desselben Patienten wegen unterschiedlicher Erkrankungen als eigenständige Prozessinstanzen behandelt. Warum das wichtig ist Erforderlich, um den Umfang einer einzelnen Prozessinstanz innerhalb der Analyse festzulegen. Bezugsquelle Abgeleitet aus der Gruppierung von Encounter-IDs oder verknüpft mit einer bestimmten Episode-of-Care-ID in athenahealth. Beispiele EP-2023-88491EP-2023-99102ENC-55412-GRP
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Identifiziert das IT-System, das den Datensatz erzeugt hat, in diesem Fall „athenahealth“. Das ist besonders in Umgebungen mit mehreren Systemen hilfreich, in denen Daten zusammengeführt werden. Analysten können die Ansicht nach Datenquelle filtern und Datenqualitätsprobleme eines bestimmten Systems gezielt untersuchen. Warum das wichtig ist Stellt Datenherkunft und Kontext in Process-Mining-Umgebungen mit mehreren Systemen bereit. Bezugsquelle Fest codierter Wert oder ID der Systemkonfiguration. Beispiele athenahealthAthenaOneAthenaPractice
	Altersgruppe des Patienten PatientAgeGroup	Kategorische Einteilung des Patientenalters, etwa 18 bis 25 oder 65 Jahre und älter.
Beschreibung Teilt Patienten in demografische Kohorten ein. Dieses Attribut wird direkt für das Dashboard zum Vergleich von Patientenpfaden nach Altersgruppe und Diagnose benötigt. So lässt sich erkennen, ob Prozessineffizienzen oder Ergebnisse bestimmte Altersgruppen überproportional betreffen, etwa ältere Menschen oder pädiatrische Patienten. Warum das wichtig ist Standardisierte demografische Segmentierung für die Analyse von Gesundheitsprozessen. Bezugsquelle Abgeleitet aus dem Geburtsdatum des Patienten und StartTime. Beispiele 18-2930-4965+
	Endzeit des Ereignisses EventEndTime	Der Zeitpunkt, zu dem die jeweilige Aktivität abgeschlossen wurde.
Beschreibung Erfasst den Abschlusszeitpunkt einer Aktivität. Dadurch lässt sich die aktive Dauer, also die Bearbeitungszeit des Schritts selbst, getrennt von der davorliegenden Wartezeit berechnen. Das Attribut dient der Analyse der Ressourceneffizienz und der Identifikation von Aufgaben, deren manuelle Ausführung länger als erwartet dauert. Warum das wichtig ist Ermöglicht die Berechnung der aktiven Bearbeitungszeit im Vergleich zur passiven Wartezeit. Bezugsquelle Checkout-Zeit, Zeitpunkt der Ergebnisprüfung oder spezifische Abschluss-Timestamps in athenahealth. Beispiele 2023-10-12T09:00:00Z2023-10-12T10:45:00Z
	Entlassungsart DischargeDisposition	Das Ziel oder der Status des Patienten bei der Entlassung.
Beschreibung Zeigt, wohin der Patient nach der Episode gegangen ist, etwa nach Hause, in eine qualifizierte Pflegeeinrichtung oder in ein Hospiz. Dieses Attribut ist für „Entlassungsplanung und Trends bei Wiederaufnahmen“ von großer Bedeutung. Es liefert Kontext für die Komplexität der erforderlichen Entlassungsplanung und hilft, die Wirksamkeit von Übergängen in der Versorgung zu bewerten. Warum das wichtig ist Wichtiger Kontext für Entlassungsplanung und Wiederaufnahmerisiko. Bezugsquelle athenahealth-Encounter-Felder oder Entlassungsdaten aus dem Krankenhaus. Beispiele Nach HausePflegeeinrichtungIn ein Akutkrankenhaus verlegtVerstorben
	Kontaktart EncounterType	Die Klassifizierung des Besuchs, etwa Praxisbesuch, Telemedizin oder Notfall.
Beschreibung Definiert die Form oder den Versorgungskontext der Behandlung. In generischen Datenmodellen dient dieses Attribut als „Case Type“. Für unterschiedliche Kontaktarten gelten jeweils eigene erwartete Abläufe und Abrechnungsanforderungen. Eine Filterung nach diesem Attribut ist unerlässlich, damit in der Durchlaufzeitanalyse nicht unterschiedliche Fälle miteinander verglichen werden. Warum das wichtig ist Unterscheidet verschiedene Prozessvarianten, etwa Telemedizin und persönliche Behandlung vor Ort. Bezugsquelle Feld „encountertype“ in athenahealth. Beispiele Ambulante UntersuchungTelemedizinNotfallChirurgischer Eingriff
	Name der Abteilung DepartmentName	Die Krankenhaus- oder Klinikabteilung, in der die Aktivität stattgefunden hat.
Beschreibung Unterteilt die Prozessdaten nach funktionaler Einheit, etwa Notaufnahme, Kardiologie oder Radiologie. Dies ist für das Dashboard „Abteilungsdurchsatz und Übergaben“ unerlässlich. Die Analyse dieses Attributs macht Engpässe in bestimmten Bereichen sichtbar und hilft, den Patientenfluss zwischen Abteilungen zu optimieren. Warum das wichtig ist Entscheidend für die Identifikation organisatorischer Engpässe und ineffizienter Übergaben. Bezugsquelle Die athenahealth-„departmentid“ wird zum Abteilungsnamen aufgelöst. Beispiele NotaufnahmeInnere MedizinRadiologie
	Name des Leistungserbringers ProviderName	Der Name der medizinischen Fachkraft, die die Aktivität ausführt.
Beschreibung Identifiziert den zuständigen Arzt, die zuständige Pflegekraft oder den zuständigen Techniker. Dieses Attribut ist zentral für die Analyse der Ressourcennutzung. Damit lassen sich Leistungskennzahlen wie Durchsatz und Durchlaufzeit zwischen verschiedenen Mitarbeitenden vergleichen, um Schulungsbedarf oder unausgewogene Arbeitslasten zu erkennen. Warum das wichtig ist Wichtig für die „Ressourcennutzungsrate“ und die Analyse von Übergaben. Bezugsquelle Die athenahealth-„providerid“ wird zum Namen aus dem Verzeichnis der Leistungserbringer aufgelöst. Beispiele Dr. SmithNurse JonesTech Adams
	Patienten-ID PatientId	Eine eindeutige Kennung für den Patienten, anonymisiert oder gehasht.
Beschreibung Identifiziert den Kunden, also den Patienten im Patientenpfad, eindeutig. Obwohl die Kennung der Case-Kennung ähnelt, kann ein Patient im Laufe der Zeit mehrere Episoden durchlaufen. Sie wird verwendet, um wiederholte Besuche zu verknüpfen und Wiederaufnahmeraten zu analysieren. Für die KPI „Prozentsatz ungeplanter Wiederaufnahmen“ ist sie entscheidend. Warum das wichtig ist Erforderlich, um Wiederaufnahmen und die Patientenhistorie über mehrere Episoden hinweg zu verfolgen. Bezugsquelle Feld „patientid“ in athenahealth. Beispiele PAT-100234PAT-559201PAT-992210
	Primärer Diagnosecode PrimaryDiagnosisCode	Der primäre ICD-10-Code, der mit der Episode verknüpft ist.
Beschreibung Klassifiziert den klinischen Grund für den Patientenpfad. Damit entsteht der Kontext für den Vergleich von Patientenpfaden nach Altersgruppe und Diagnose. Analysten verwenden dieses Attribut, um Patientenpfade nach Erkrankung zu segmentieren, etwa Lungenentzündung im Vergleich zu Fraktur, da sich erwartete Abläufe und Durchlaufzeiten je nach Erkrankung stark unterscheiden. Warum das wichtig ist Ermöglicht den Vergleich gleichartiger Fälle, da die Durchlaufzeiten je nach Diagnose stark variieren. Bezugsquelle Diagnosefelder des Kontakts oder Abrechnungsfalls (ICD-10). Beispiele J18.9I10E11.9
	Wiederaufnahme IsReadmission	Kennzeichen dafür, ob diese Episode eine ungeplante Rückkehr darstellt.
Beschreibung Boolesches Kennzeichen, das angibt, ob der Patient innerhalb eines festgelegten Zeitraums, beispielsweise 30 Tage, nach einer früheren Entlassung ins Krankenhaus zurückgekehrt ist. Dies unterstützt direkt die KPI „Prozentsatz ungeplanter Wiederaufnahmen“. Durch die Filterung nach diesem Attribut können Analysten die Ursachen von Wiederaufnahmen untersuchen und Muster in den ursprünglichen Behandlungspfaden erkennen. Warum das wichtig ist Unterstützt direkt die KPI zur Wiederaufnahmerate. Bezugsquelle Wird während des ETL-Prozesses durch den Vergleich des Aufnahmedatums mit dem Datum der vorherigen Entlassung berechnet. Beispiele truefalse
	Auftragstyp OrderType	Kategorie des Auftrags, etwa Labor, Bildgebung oder Rezept.
Beschreibung Klassifiziert klinische Aufträge, die während der Episode erteilt wurden. Dies ist entscheidend für das Dashboard „Durchlaufzeit diagnostischer Untersuchungen“. Damit können Analysten die Durchlaufzeiten für Labor und Bildgebung getrennt messen, da sich Service-Level-Vereinbarungen und Engpässe häufig unterscheiden. Warum das wichtig ist Segmentiert den diagnostischen Prozess für eine gezielte Analyse der Durchlaufzeiten. Bezugsquelle „ordertype“ oder „class“ in der athenahealth Orders API. Beispiele LaborBildgebungVerordnungVerfahren
	Gesamter Abrechnungsbetrag TotalChargeAmount	Der Geldbetrag, der für die Aktivität oder Episode berechnet wird.
Beschreibung Der finanzielle Wert der Aktivität oder der Gesamtbetrag des Anspruchs. Dies ermöglicht kostenbasiertes Process Mining und die Analyse finanzieller Auswirkungen. Wird verwendet, um kostenintensive Varianten von Behandlungspfaden zu erkennen und die Prozesseffizienz mit finanziellen Ergebnissen in Beziehung zu setzen. Warum das wichtig ist Ergänzt die Prozessanalyse um eine finanzielle Dimension. Bezugsquelle athenahealth-„amount“ oder „totalcharge“ in Anspruchs- oder Abrechnungstabellen. Beispiele 150.002500.5045.00
	Nacharbeit IsRework	Kennzeichen dafür, ob es sich bei dieser Aktivität um eine Wiederholung handelt.
Beschreibung Boolesches Kennzeichen, das den Wert „true“ annimmt, wenn die Aktivität innerhalb desselben Cases mehr als einmal aufgetreten ist. Dies unterstützt das Dashboard „Aktivitätshäufigkeit und Nacharbeitsschleifen“. Damit lassen sich Cases mit Nacharbeit unmittelbar isolieren und die KPI „Häufigkeit von Nacharbeitsaktivitäten“ berechnen. Warum das wichtig ist Erkennt Prozessineffizienzen und überflüssige Schritte. Bezugsquelle Wird während des ETL-Prozesses auf Grundlage der Aktivitätsvorkommen pro CaseId berechnet. Beispiele truefalse
	Status des Anspruchs ClaimStatus	Der Status des mit der Behandlung verbundenen finanziellen Anspruchs.
Beschreibung Zeigt den Stand des Abrechnungsanspruchs an, beispielsweise „Eingereicht“, „Abgelehnt“ oder „Bezahlt“. Dies ist für die Aktivität „Anspruch eingereicht“ und den finanziellen Durchsatz relevant. Hilft zu erkennen, ob Probleme bei der klinischen Dokumentation zu Verzögerungen in der nachgelagerten Finanzabwicklung führen. Warum das wichtig ist Verknüpft die klinische Effizienz mit der Leistung des Erlöszyklus. Bezugsquelle athenahealth-Feld „claimstatus“. Beispiele ABGERECHNETZURÜCKGESTELLTABGEBROCHEN
	Status des Diagnoseergebnisses DiagnosticResultStatus	Der Ergebnisstatus einer diagnostischen Anordnung, beispielsweise „Positiv“ oder „Normal“.
Beschreibung Erfasst das übergeordnete Ergebnis eines Tests. Dies liefert Kontext für die „Durchlaufzeit diagnostischer Tests“ und nachfolgende Behandlungsentscheidungen. Wird verwendet, um zu analysieren, ob auffällige Ergebnisse im Vergleich zu normalen Ergebnissen zu schnelleren Folgemaßnahmen führen. Warum das wichtig ist Verknüpft den Prozessablauf mit klinischen Ergebnissen. Bezugsquelle athenahealth-Felder für Laborergebnisbeobachtungen. Beispiele NormalAbnormalKritisch

Erforderlich Empfohlen Optional

Aktivitäten des Patientenpfads

Dies sind die entscheidenden Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung und Optimierung der Patientenerfahrung in Ihrem Event Log erfassen sollten.

7 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Diagnose bestätigt	Ein Kliniker weist dem aktuellen Kontakt offiziell eine Diagnose für den Zustand des Patienten zu oder bestätigt sie. Dies kann aus dem Erstellungs- oder „zuletzt aktualisiert“-Timestamp des primären Diagnosecodes, etwa ICD-10, abgeleitet werden, der mit dem Patientenkontakt verknüpft ist.
Warum das wichtig ist Dies ist ein zentraler Meilenstein, der den weiteren Behandlungspfad bestimmt. Die Analyse von Abweichungen bei den Aktivitäten nach diesem Zeitpunkt hilft dabei, Versorgungsprotokolle zu verstehen und zu standardisieren. Bezugsquelle Abgeleitet aus der Problemliste des Patienten oder den Diagnosedaten des Kontakts. Eine Änderung oder Finalisierung des Diagnosecodes zusammen mit dem zugehörigen Timestamp signalisiert dieses Ereignis. Erfassen Ermitteln Sie den Timestamp, zu dem die primäre Diagnose für den Kontakt hinzugefügt oder aktualisiert wurde. Ereignistyp inferred
	Eingriff durchgeführt	Ein klinischer Eingriff, etwa eine Operation oder eine spezialisierte Therapie, wird am Patienten durchgeführt. Dies ist ein ausdrückliches Ereignis in der klinischen Dokumentation, häufig mit dokumentierten Start- und Endzeiten in einer Eingriffsdokumentation.
Warum das wichtig ist Eingriffe sind wichtige Meilensteine in der Behandlung eines Patienten. Die Analyse der Aktivitäten vor und nach einem Eingriff hilft dabei, präoperative und postoperative Abläufe zu optimieren. Bezugsquelle Der Eintrag befindet sich in Eingriffsdokumentationen oder bestimmten klinischen Flowsheets in athenaClinicals. Der Ereignis-Timestamp wird aus der dokumentierten Start- oder Endzeit des Eingriffs abgeleitet. Erfassen Eine Eingriffsdokumentation oder ein Protokoll wird mit einem Timestamp für den Zeitpunkt des Eingriffs angelegt. Ereignistyp explicit
	Entlassungsauftrag erstellt	Ein Arzt oder autorisierter Leistungserbringer erstellt einen offiziellen Auftrag zur Entlassung des Patienten aus der Versorgung. Dies ist ein ausdrückliches, mit Timestamp versehenes Ereignis, das im CPOE-Modul des EHR angelegt wird.
Warum das wichtig ist Diese Aktivität leitet den Entlassungsprozess ein. Die Zeit zwischen diesem Auftrag und der tatsächlichen Entlassung ist eine wichtige Kennzahl für die „Durchlaufzeit der Entlassungsplanung“. Bezugsquelle Der Eintrag befindet sich in der Auftragstabelle. Das Ereignis wird anhand eines bestimmten Auftragstyps „Discharge“ und seines Erstellungs-Timestamps identifiziert. Erfassen In der Auftragstabelle wird ein neuer Datensatz mit dem Auftragstyp „Discharge“ angelegt. Ereignistyp explicit
	Erste Untersuchung abgeschlossen	Bezeichnet den Abschluss der ersten klinischen Untersuchung, etwa der Triage oder einer pflegerischen Einschätzung, bei der Vitalwerte und die wichtigsten Beschwerden erfasst werden. Häufig wird dieses Ereignis aus dem Timestamp der ersten signierten klinischen Notiz oder eines abgeschlossenen Untersuchungsformulars für den Kontakt abgeleitet.
Warum das wichtig ist Dieser Meilenstein markiert den Beginn der klinischen Versorgung. Die Zeit vom Check-in bis zu dieser Aktivität ist eine wichtige Kennzahl für die anfängliche Wartezeit des Patienten und die Reaktionsfähigkeit der Ressourcen. Bezugsquelle Abgeleitet aus dem Erstellungs- oder Signatur-Timestamp bestimmter klinischer Dokumente oder Flowsheets in athenaClinicals. Dafür müssen die relevanten Dokumenttypen für Triage oder Aufnahme identifiziert werden. Erfassen Identifizieren Sie den ersten Timestamp in einer klinischen Notiz, einem Flowsheet für Vitalwerte oder einem bestimmten Aufnahmeformular für den Kontakt. Ereignistyp inferred
	Patient eingecheckt	Diese Aktivität bezeichnet die Ankunft des Patienten und den formellen Check-in für den geplanten Termin oder Besuch. In der Regel wird sie als ausdrückliche Statusänderung des Termindatensatzes in athenaClinicals oder athenaCommunicator erfasst.
Warum das wichtig ist Damit beginnt der Aufenthalt des Patienten vor Ort. Dieser Zeitpunkt ist ein wichtiger Ausgangspunkt für die Messung von Wartezeiten und der gesamten Durchlaufzeit eines klinischen Kontakts. Bezugsquelle Die Erfassung erfolgt als Statusaktualisierung in den Termin- oder Kontakt-Tabellen. Suchen Sie nach dem Status „Checked-In“ und dem zugehörigen Timestamp. Erfassen Eine Statusänderung am Termin- oder Kontaktobjekt wird mit einem Timestamp protokolliert. Ereignistyp explicit
	Patient entlassen	Der Patient wurde offiziell entlassen, und der Aufenthalt innerhalb der Einrichtung ist abgeschlossen. Dies ist das letzte ADT-Ereignis eines stationären Kontakts und wird mit einem präzisen Timestamp erfasst.
Warum das wichtig ist Dieses Ereignis markiert das Ende des Hauptpfads des Patienten. Es bildet den Endpunkt für die Messung der gesamten „Durchlaufzeit des Patientenpfads“ und ist für die Analyse von Wiederaufnahmen unerlässlich. Bezugsquelle Dies ist ein ausdrückliches Ereignis im ADT-System oder in der Tabelle für Patientenkontakte. Es setzt den abschließenden Status des Kontakts auf „Discharged“ und enthält einen Timestamp. Erfassen Der Status des Patientenkontakts wird auf „Discharged“ aktualisiert und ein ADT-Ereignis protokolliert. Ereignistyp explicit
	Untersuchungsergebnisse eingegangen	Die Ergebnisse einer diagnostischen Untersuchung sind finalisiert und in der Patientenakte verfügbar. In der Regel wird dies erfasst, wenn das Labor- oder Bildgebungssystem die Ergebnisse an athenahealth übermittelt und dort einen Datensatz mit Timestamp anlegt.
Warum das wichtig ist Der Eingang der Ergebnisse ist ein wichtiger Auslöser für nachfolgende klinische Entscheidungen, etwa Diagnose und Behandlungsplanung. Dieses Ereignis bildet den Endpunkt für die Messung diagnostischer Durchlaufzeiten. Bezugsquelle Der Eintrag befindet sich in der Ergebnis- oder Diagnostiktabelle und ist mit dem ursprünglichen Auftrag verknüpft. Maßgeblich ist der Timestamp, zu dem das Ergebnis in der Patientenakte abgelegt wurde oder eingegangen ist. Erfassen Ein neuer Ergebnisdatensatz wird mit einem Timestamp angelegt, häufig über eine Schnittstelle zu einem LIS oder RIS. Ereignistyp explicit
	Abrechnungsfall übermittelt	Ein Abrechnungsfall für die während des Patientenkontakts erbrachten Leistungen wird erstellt und an den Kostenträger übermittelt. Dies ist ein ausdrückliches Ereignis im Revenue-Cycle-Management-Modul athenaCollector.
Warum das wichtig ist Obwohl es sich um einen administrativen Schritt handelt, ist diese Aktivität für die Analyse des parallel zum klinischen Pfad verlaufenden Abrechnungsprozesses entscheidend. Sie hilft, Verzögerungen zwischen Versorgung und Abrechnung zu erkennen. Bezugsquelle Der Eintrag befindet sich in den Tabellen für Abrechnungsfälle oder Abrechnung. Maßgeblich ist der Erstellungs- oder Übermittlungs-Timestamp des Abrechnungsfalls. Erfassen Ein Abrechnungsfalldatensatz wird angelegt und sein Status mit einem Timestamp auf „Submitted“ aktualisiert. Ereignistyp explicit
	Behandlungsplan erstellt	Bezeichnet die formelle Erstellung und Dokumentation des Behandlungsplans eines Patienten durch einen Kliniker. Erfasst werden kann dies durch das Anlegen oder Signieren eines bestimmten Dokuments wie „Plan of Care“ oder einer Gruppe zugehöriger Behandlungsaufträge.
Warum das wichtig ist Diese Aktivität legt den vorgesehenen klinischen Behandlungspfad fest. Sie ist ein wichtiger Bezugspunkt für die Messung der Übereinstimmung mit Standardprotokollen und die Analyse von Versorgungsabweichungen. Bezugsquelle Der Eintrag befindet sich voraussichtlich in den Tabellen für klinische Dokumente oder Aufträge. Das Ereignis entspricht dem Timestamp einer signierten Notiz zum Versorgungsplan oder der Übermittlung einer abgestimmten Gruppe von Behandlungsaufträgen. Erfassen Das Ereignis entspricht dem Erstellungs- oder Finalisierungs-Timestamp eines bestimmten Behandlungsplandokuments oder Auftragssatzes. Ereignistyp explicit
	Diagnostische Untersuchung angeordnet	Ein Leistungserbringer ordnet eine diagnostische Untersuchung an, etwa eine Laboruntersuchung, einen bildgebenden Scan oder einen anderen Eingriff. Dies ist ein ausdrückliches, mit Timestamp versehenes Ereignis, das über die CPOE-Funktion (Computerized Provider Order Entry) in athenaClinicals angelegt wird.
Warum das wichtig ist Dies ist ein entscheidender Entscheidungspunkt, der einen diagnostischen Teilprozess einleitet. Die Nachverfolgung dieser Aktivität ist unerlässlich, um die KPI „Durchlaufzeit diagnostischer Untersuchungen“ von der Anordnung bis zum Ergebnis zu analysieren. Bezugsquelle Der Eintrag befindet sich in der Auftragstabelle. Jeder Auftrag enthält eine Patientenkennung, eine Auftragsbezeichnung, einen Auftragsstatus und einen Erstellungs-Timestamp. Erfassen In der Auftragstabelle des Systems wird mit einem Timestamp ein neuer Datensatz angelegt. Ereignistyp explicit
	Medikament verabreicht	Ein Medikament wird dem Patienten durch klinisches Personal tatsächlich verabreicht. Dies wird im Modul Medication Administration Record (MAR) von athenaClinicals ausdrücklich erfasst, mit einem präzisen Timestamp für jede Dosis.
Warum das wichtig ist Diese Aktivität stellt eine direkte therapeutische Intervention dar. Die Analyse ihres Zeitpunkts hilft bei der Messung der „Zeit bis zur ersten Behandlung“ und stellt die Einhaltung von Medikamentenplänen sicher. Bezugsquelle Der Eintrag befindet sich in den MAR-Datentabellen. Jedes Verabreichungsereignis enthält eine Patienten-ID, eine Medikamenten-ID, die Dosierung und den Timestamp der Verabreichung. Erfassen Jedes Mal, wenn die Verabreichung eines Medikaments dokumentiert wird, legt das MAR einen Datensatz mit Timestamp an. Ereignistyp explicit
	Nachsorgetermin vereinbart	Nach der Hauptbehandlung oder Entlassung wird ein Nachsorgetermin für den Patienten vereinbart. Dieses Ereignis wird ausdrücklich erfasst, wenn im Terminplanungsmodul athenaCommunicator ein neuer Termin angelegt wird.
Warum das wichtig ist Diese Aktivität ist entscheidend für das Verständnis der Koordination der Nachsorge und ihrer Auswirkungen auf Ergebnisse wie Wiederaufnahmeraten. Sie zeigt die Kontinuität der Versorgung. Bezugsquelle Die Erfassung erfolgt in der Termintabelle. Das Ereignis wird durch den Erstellungs-Timestamp eines Termins identifiziert, der nach dem Entlassungsdatum stattfindet. Erfassen Im Terminplanungssystem wird ein neuer Termindatensatz angelegt. Ereignistyp explicit
	Patient verlegt	Der Patient wird von einer Versorgungseinheit oder Abteilung in eine andere verlegt, etwa von der Notaufnahme auf eine Station. Dies wird im EHR ausdrücklich als Admission-, Discharge- oder Transfer-Ereignis (ADT) erfasst.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Analyse von Übergaben zwischen Abteilungen und des Patientenflusses innerhalb einer Einrichtung. Sie hilft, Engpässe bei der „Zeit für die Patientenübergabe“ und der Ressourcenzuweisung zu erkennen. Bezugsquelle Die Erfassung erfolgt im ADT Event Log oder in Tabellen zur Patientenverfolgung. Jedes Verlegungsereignis enthält den Patienten, den Ausgangs- und Zielort sowie einen Timestamp. Erfassen Bei der Verlegung des Patienten wird eine ADT-Mitteilung oder ein Eintrag im Event Log mit Timestamp erzeugt. Ereignistyp explicit
	Probe entnommen	Bezeichnet die Entnahme einer biologischen Probe, etwa Blut oder Urin, beim Patienten für eine Laboruntersuchung. In der Regel wird dieses Ereignis ausdrücklich im Labormodul oder als Aktualisierung des Auftragsstatus protokolliert.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein im diagnostischen Untersuchungsprozess. Die Zeit zwischen Anordnung, Entnahme und Ergebnis kann erhebliche Engpässe in Laborabläufen sichtbar machen. Bezugsquelle Dieses Ereignis ist als Statusänderung des Laborauftrags oder als eigenständiges Ereignis in einem an athenahealth angebundenen Laborinformationssystem zu finden. Suchen Sie nach dem Status „Collected“ und dem zugehörigen Timestamp. Erfassen Das Ereignis wird als Aktualisierung des Laborauftragsstatus oder in einem eigenen Modul zur Probenverfolgung protokolliert. Ereignistyp explicit
	Termin vereinbart	Bezeichnet die Buchung eines Termins für einen Patienten. Dieses Ereignis wird ausdrücklich erfasst, wenn ein Benutzer im Terminplanungsmodul athenaCommunicator einen neuen Termin anlegt und bestätigt.
Warum das wichtig ist Diese Aktivität markiert für viele Patientenpfade den ersten Kontaktpunkt. Die Analyse der Zeit zwischen Terminvereinbarung und Check-in hilft dabei, den Zugang zur Versorgung und die Effizienz vor dem Besuch zu bewerten. Bezugsquelle Dies ist ein ausdrücklich in den Termin- oder Planungstabellen protokolliertes Ereignis. In der Regel ist es mit einem Erstellungszeitpunkt und einer Patienten-ID verknüpft. Erfassen Das Ereignis wird erfasst, sobald im Terminplanungsmodul ein Termindatensatz angelegt wird. Ereignistyp explicit

Anleitungen zur Datenextraktion

So erhalten Sie Ihre Daten aus athenahealth

Schritte

Melden Sie sich mit Ihren sicheren Zugangsdaten im athenaNet-Portal an.
Öffnen Sie über das Hauptmenü das Modul Reports. Sie finden es in der Regel unter „Reports“ > „Report Builder“ oder „Custom Reports“.
Klicken Sie auf „Create New Report“ und wählen Sie „Encounters“ oder „Patient Visit“ als primäre Berichtskategorie. So basiert der Bericht auf granularen Daten zur jeweiligen Patientenepisode.
Suchen Sie im Bereich „Columns“ oder „Fields“ nach dem Patient Identifier (Patient ID) und dem Encounter Identifier (Encounter ID), und fügen Sie beide als Case Identifier hinzu.
Ergänzen Sie die für Attribute benötigten demografischen und kontextbezogenen Spalten, etwa Department, Provider Name, Patient Age und Primary Diagnosis Code.
Fügen Sie die Timestamp-Spalten für die Aktivitäten hinzu. Möglicherweise müssen Sie dazu verschiedene Feldgruppen durchsuchen, zum Beispiel „Scheduling“ für Appointment Scheduled, „Check-in“ für Check-in Time und „Billing“ für Claim Submitted. Wählen Sie, sofern verfügbar, das Format „Date and Time“ und nicht nur „Date“.
Legen Sie Filter für die Berichtskonfiguration fest. Definieren Sie für „Encounter Date“ den gewünschten Analysezeitraum, zum Beispiel „Last 6 Months“, und schließen Sie „Cancelled“- oder „No Show“-Termine aus, damit nur abgeschlossene Patientenreisen berücksichtigt werden.
Klicken Sie auf „Run Report“, um eine Vorschau der Daten anzuzeigen. Prüfen Sie, ob die Spalten Werte enthalten und nicht vollständig null sind.
Wählen Sie „Export“ und anschließend „CSV“ (Comma Separated Values) als Format. Verwenden Sie keine Excel-/XLSX-Formatierungsfunktionen, da sie die Verarbeitung erschweren.
Speichern Sie die Datei lokal unter dem Namen „athena_raw_export.csv“.
Da der Bericht pro Encounter eine Zeile mit mehreren Datumsspalten exportiert (Wide Format), müssen Sie ihn in ein Event Log im Long Format umwandeln. Verwenden Sie dafür das im Abschnitt Query bereitgestellte Python-Skript.
Führen Sie das Skript aus, um die finale Datei „process_mining_event_log.csv“ zu erzeugen, und laden Sie diese Datei in ProcessMind hoch.

Konfiguration

Berichtskategorie: Wählen Sie „Encounter Activity“ oder „Clinicals“ als Basiskategorie, um möglichst viele Schritte des klinischen Workflows zu erfassen.
Datumsbereich: Begrenzen Sie die erste Extraktion auf 3 bis 6 Monate, um Timeouts oder Zeilenlimits des Berichts zu vermeiden. In Standardansichten liegt das Limit typischerweise bei etwa 50.000 Zeilen.
Spaltenauswahl: Stellen Sie sicher, dass explizite Timestamp-Felder ausgewählt sind. Verwenden Sie statt berechneter Felder wie „Days since check-in“ absolute Angaben wie „Check-in Date/Time“.
Umgang mit Nullwerten: Konfigurieren Sie den Bericht so, dass fehlende Daten als leere Zellen und nicht als benutzerdefinierter Text wie „N/A“ angezeigt werden. Das erleichtert die Verarbeitung durch das Skript.
Filter nach Abteilung: Wenn die Organisation groß ist, filtern Sie nach bestimmten Service Locations oder Departments, zum Beispiel „Cardiology“ oder „Orthopedics“, damit der Datensatz überschaubar bleibt.
Berechtigungen: Für den Zugriff auf den Custom Report Builder benötigt der Benutzer in athenaNet die Berechtigung „Report Creator“ oder „Clinical Reporting“.

a Beispielabfrage python

import pandas as pd
import numpy as np
from datetime import datetime

class=class="hl-string">"hl-comment"># Configuration: Input and Output filenames
INPUT_FILE = class="hl-string">'athena_raw_export.csv'
OUTPUT_FILE = class="hl-string">'patient_journey_event_log.csv'

class=class="hl-string">"hl-comment"># Load the raw wide-format report from athenaNet
class=class="hl-string">"hl-comment"># Assumes standard CSV export. Adjust encoding if necessary (e.g., class="hl-string">'utf-8-sig' or class="hl-string">'latin1')
df = pd.read_csv(INPUT_FILE, dtype=str)

class=class="hl-string">"hl-comment"># Define the mapping between Activity Names and the columns in your athenaNet report
class=class="hl-string">"hl-comment"># You must ensure these column names match your Report Builder export headers exactly
activity_mapping = {
    class="hl-string">'Appointment Scheduled': class="hl-string">'APPT_CREATED_TIMESTAMP',
    class="hl-string">'Patient Checked In': class="hl-string">'CHECKIN_TIMESTAMP',
    class="hl-string">'Initial Assessment Completed': class="hl-string">'INTAKE_COMPLETED_TIMESTAMP',
    class="hl-string">'Diagnostic Test Ordered': class="hl-string">'ORDER_ENTRY_TIMESTAMP',
    class="hl-string">'Specimen Collected': class="hl-string">'LAB_COLLECTION_TIMESTAMP',
    class="hl-string">'Test Results Received': class="hl-string">'LAB_RESULT_TIMESTAMP',
    class="hl-string">'Diagnosis Confirmed': class="hl-string">'DIAGNOSIS_ENTRY_TIMESTAMP',
    class="hl-string">'Treatment Plan Developed': class="hl-string">'PLAN_NOTE_TIMESTAMP',
    class="hl-string">'Medication Administered': class="hl-string">'MED_ADMIN_TIMESTAMP',
    class="hl-string">'Procedure Performed': class="hl-string">'PROCEDURE_END_TIMESTAMP',
    class="hl-string">'Patient Transferred': class="hl-string">'TRANSFER_TIMESTAMP',
    class="hl-string">'Discharge Order Written': class="hl-string">'DISCHARGE_ORDER_TIMESTAMP',
    class="hl-string">'Patient Discharged': class="hl-string">'DISCHARGE_TIMESTAMP',
    class="hl-string">'Follow-Up Appointment Scheduled': class="hl-string">'NEXT_APPT_CREATED_TIMESTAMP',
    class="hl-string">'Claim Submitted': class="hl-string">'CLAIM_SUBMISSION_TIMESTAMP'
}

class=class="hl-string">"hl-comment"># Define attribute columns to carry over to every event row
attribute_columns = {
    class="hl-string">'ENCOUNTER_ID': class="hl-string">'PatientEpisodeId',
    class="hl-string">'PATIENT_ID': class="hl-string">'PatientId',
    class="hl-string">'PROVIDER_NAME': class="hl-string">'ProviderName',
    class="hl-string">'DEPARTMENT_NAME': class="hl-string">'DepartmentName',
    class="hl-string">'PRIMARY_DIAGNOSIS_CODE': class="hl-string">'PrimaryDiagnosisCode',
    class="hl-string">'PATIENT_AGE': class="hl-string">'PatientAgeGroup',
    class="hl-string">'ENCOUNTER_TYPE': class="hl-string">'EncounterType',
    class="hl-string">'DISCHARGE_DISPOSITION': class="hl-string">'DischargeDisposition',
    class="hl-string">'IS_READMISSION': class="hl-string">'IsReadmission'
}

class=class="hl-string">"hl-comment"># Initialize list to hold event rows
event_log_data = []

class=class="hl-string">"hl-comment"># Transformation Loop
for index, row in df.iterrows():
    episode_id = row.get(class="hl-string">'ENCOUNTER_ID')
    
    class=class="hl-string">"hl-comment"># Skip rows without a valid identifier
    if pd.isna(episode_id) or str(episode_id).strip() == class="hl-string">'':
        continue

    class=class="hl-string">"hl-comment"># Iterate through each defined activity
    for activity_name, col_name in activity_mapping.items():
        timestamp_val = row.get(col_name)
        
        class=class="hl-string">"hl-comment"># Only create an event if a valid timestamp exists
        if pd.notna(timestamp_val) and str(timestamp_val).strip() != class="hl-string">'':
            
            class=class="hl-string">"hl-comment"># Create base event object
            event = {
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp_val,
                class="hl-string">'SourceSystem': class="hl-string">'athenahealth',
                class="hl-string">'LastDataUpdate': datetime.now().strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
            }
            
            class=class="hl-string">"hl-comment"># Add attributes
            for csv_col, target_col in attribute_columns.items():
                event[target_col] = row.get(csv_col, None)
            
            event_log_data.append(event)

class=class="hl-string">"hl-comment"># Create DataFrame from the list of events
event_log_df = pd.DataFrame(event_log_data)

class=class="hl-string">"hl-comment"># Standardize Date Format (ISO 8601 Recommended)
class=class="hl-string">"hl-comment"># Adjust the format string matches the raw CSV format (e.g., class="hl-string">'%m/%d/%Y %H:%M')
event_log_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log_df[class="hl-string">'EventTimestamp'], errors=class="hl-string">'coerce')

class=class="hl-string">"hl-comment"># Remove rows where timestamp parsing failed
event_log_df = event_log_df.dropna(subset=[class="hl-string">'EventTimestamp'])

class=class="hl-string">"hl-comment"># Sort by Episode and Time
event_log_df = event_log_df.sort_values(by=[class="hl-string">'PatientEpisodeId', class="hl-string">'EventTimestamp'])

class=class="hl-string">"hl-comment"># Output to CSV
event_log_df.to_csv(OUTPUT_FILE, index=False)

print(fclass="hl-string">"Transformation complete. Processed {len(df)} encounters into {len(event_log_df)} events.")
print(fclass="hl-string">"File saved to: {OUTPUT_FILE}")

Schritte

API-Anwendung registrieren: Melden Sie sich im athenahealth Developer Portal an und registrieren Sie eine neue Anwendung, um Ihre Client ID und Ihr Client Secret zu erhalten. Stellen Sie sicher, dass die Anwendung über Scopes für Appointments, Clinicals (Charts), Orders und Billing (Claims) verfügt.
Python-Umgebung konfigurieren: Installieren Sie die benötigten Python-Bibliotheken (requests, pandas) mit pip install requests pandas in Ihrer Ausführungsumgebung.
Authentifizieren: Implementieren Sie den OAuth-2.0-Flow „Client Credentials“, um ein Access Token abzurufen. Dieses Token muss bei allen nachfolgenden API-Aufrufen im Authorization-Header als Bearer Token enthalten sein.
Geltungsbereich festlegen: Definieren Sie die Practice ID und den Zeitraum für die Extraktion. Die Athenahealth-APIs sind praxisbezogen. Wenn Sie mehrere Praxen verwalten, müssen Sie daher die jeweiligen Practice IDs nacheinander verarbeiten.
Appointments extrahieren: Rufen Sie den Endpunkt /appointments/booked oder /appointments/changed auf, um die grundlegenden Encounters abzurufen. Ordnen Sie die Appointment ID der PatientEpisodeId zu. Ermitteln Sie „Appointment Scheduled“ aus dem Erstellungsdatum und „Patient Checked In“ aus der Check-in-Zeit.
Encounters auf klinische Ereignisse prüfen: Rufen Sie für jede Appointment ID beziehungsweise jeden Encounter die klinischen Unterendpunkte auf. Verwenden Sie /chart/{encounterId}/vitals für „Initial Assessment Completed“. Verwenden Sie /chart/{encounterId}/orders für „Diagnostic Test Ordered“, „Specimen Collected“ (abhängig vom Status) und „Discharge Order Written“.
Ergebnisse und Diagnosen abrufen: Rufen Sie /chart/{encounterId}/analyteresults oder /chart/{encounterId}/labresults für „Test Results Received“ auf. Verwenden Sie /chart/{encounterId}/diagnoses für „Diagnosis Confirmed“.
Behandlungen und Verfahren extrahieren: Rufen Sie /chart/{encounterId}/plan für „Treatment Plan Developed“, /chart/{encounterId}/procedures für „Procedure Performed“ und /chart/{encounterId}/medications/admin für „Medication Administered“ auf.
ADT und Claims identifizieren: Verwenden Sie die Statushistorie des Appointments oder, sofern verfügbar, spezielle Krankenhausendpunkte, um „Patient Transferred“ und „Patient Discharged“ zu erfassen. Rufen Sie /claims für das Appointment auf, um „Claim Submitted“ zu extrahieren.
Nachsorgetermine verknüpfen: Identifizieren Sie „Follow-Up Appointment Scheduled“, indem Sie nach später angelegten Appointments für dieselbe Patient ID innerhalb des Zeitraums des Encounters suchen.
Umwandeln und abflachen: Verarbeiten Sie die verschachtelten JSON-Antworten zu einer flachen Liste von Event-Dictionaries. Konvertieren Sie alle Timestamps in das ISO-8601-Format. Ordnen Sie die Felder ActivityName, PatientEpisodeId und EventTimestamp zu.
Daten exportieren: Laden Sie die Liste der Dictionaries in einen pandas DataFrame, führen Sie die abschließende Bereinigung durch, einschließlich des Umgangs mit Nullwerten, und exportieren Sie eine für die ProcessMind-Aufnahme geeignete CSV-Datei.

Konfiguration

API-Zugangsdaten: Erfordert eine gültige Client ID und ein gültiges Secret aus dem athenahealth Developer Portal mit Produktionszugriff.
Practice ID: Die eindeutige numerische Kennung für den Kontext der medizinischen Praxis. Wenn Sie Daten für ein Netzwerk extrahieren, muss das Skript pro Praxis ausgeführt werden.
Datumsbereich: Aufgrund des Umfangs der granularen klinischen Daten wird ein Extraktionszeitraum von 3 bis 6 Monaten empfohlen.
Rate Limiting: Für die athenaOne API gelten strenge Ratenlimits, zum Beispiel 5 Aufrufe pro Sekunde. Das Skript enthält eine Sleep-Funktion. Bei Extraktionen im Unternehmensmaßstab sollten Sie zusätzlich ein exponentielles Backoff-Verfahren implementieren.
Scopes: Stellen Sie sicher, dass das Token über Scopes für athena/service/Athenanet.MDP.* oder über spezifische granulare Scopes für Appointments, Charts und Finanzdaten verfügt.
Pagination: Die meisten Endpunkte liefern eine begrenzte Anzahl von Datensätzen, standardmäßig 1.000. Das Skript muss die Parameter next oder offset verarbeiten.
Filter nach Abteilung: Wenn Sie bestimmte Abläufe analysieren, zum Beispiel Emergency im Vergleich zu Outpatient, filtern Sie beim Abruf der Appointments nach der Department ID.

a Beispielabfrage python

import requests
import pandas as pd
import time
from datetime import datetime, timedelta
import base64

class=class="hl-string">"hl-comment"># Configuration
API_KEY = class="hl-string">'YOUR_CLIENT_ID'
API_SECRET = class="hl-string">'YOUR_CLIENT_SECRET'
PRACTICE_ID = class="hl-string">'195900'  class=class="hl-string">"hl-comment"># Replace with your Practice ID
BASE_URL = class="hl-string">'https://api.athenahealth.com/preview1'  class=class="hl-string">"hl-comment"># Use production URL for live data
START_DATE = class="hl-string">'01/01/2023'
END_DATE = class="hl-string">'01/31/2023'
OUTPUT_FILE = class="hl-string">'athena_patient_journey.csv'

def get_access_token():
    url = fclass="hl-string">'{BASE_URL}/oauth2/v1/token'
    auth_str = fclass="hl-string">'{API_KEY}:{API_SECRET}'
    b64_auth = base64.b64encode(auth_str.encode()).decode()
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {b64_auth}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials', class="hl-string">'scope': class="hl-string">'athena/service/Athenanet.MDP.*'}
    response = requests.post(url, headers=headers, data=data)
    if response.status_code == 200:
        return response.json()[class="hl-string">'access_token']
    else:
        raise Exception(fclass="hl-string">'Auth failed: {response.text}')

def fetch_paginated(url, headers, params):
    results = []
    while True:
        response = requests.get(url, headers=headers, params=params)
        if response.status_code == 429:
            time.sleep(2)
            continue
        if response.status_code != 200:
            print(fclass="hl-string">'Error fetching {url}: {response.status_code}')
            break
        data = response.json()
        if class="hl-string">'totalcount' in data and data[class="hl-string">'totalcount'] == 0:
            break
        class=class="hl-string">"hl-comment"># Handle different response structures (key might be appointments, orders, etc.)
        keys = [k for k in data.keys() if k not in [class="hl-string">'totalcount', class="hl-string">'next', class="hl-string">'previous']]
        if keys:
            results.extend(data[keys[0]])
        
        if class="hl-string">'next' in data and data[class="hl-string">'next']:
             class=class="hl-string">"hl-comment"># Athena pagination often uses offset or a link
             class=class="hl-string">"hl-comment"># Adjust based on specific endpoint logic if next is not a full URL
             params[class="hl-string">'offset'] = params.get(class="hl-string">'offset', 0) + len(data[keys[0]])
        else:
            break
    return results

def extract_events():
    token = get_access_token()
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}'}
    events = []

    class=class="hl-string">"hl-comment"># 1. Fetch Appointments (Patient Episodes)
    class=class="hl-string">"hl-comment"># Using /appointments/booked for the range
    print(class="hl-string">'Fetching appointments...')
    appt_params = {
        class="hl-string">'startdate': START_DATE,
        class="hl-string">'enddate': END_DATE,
        class="hl-string">'showclaimdetail': class="hl-string">'true',  class=class="hl-string">"hl-comment"># optimize to get claim info early
        class="hl-string">'ignorepartners': class="hl-string">'true'
    }
    appointments = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/appointments/booked', headers, appt_params)

    for appt in appointments:
        episode_id = str(appt.get(class="hl-string">'appointmentid'))
        patient_id = appt.get(class="hl-string">'patientid')
        dept_id = appt.get(class="hl-string">'departmentid')
        provider_id = appt.get(class="hl-string">'providerid')
        
        class=class="hl-string">"hl-comment"># Base Activity: Appointment Scheduled
        if appt.get(class="hl-string">'date'): class=class="hl-string">"hl-comment"># capturing creation/scheduled date requires parsing history or booking info
            class=class="hl-string">"hl-comment"># Fallback to date if created date unavailable, but typically we want class="hl-string">'scheduleddatetime'
            sched_time = appt.get(class="hl-string">'scheduleddatetime', appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'starttime'))
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Appointment Scheduled',
                class="hl-string">'EventTimestamp': sched_time,
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id,
                class="hl-string">'DepartmentName': dept_id
            })

        class=class="hl-string">"hl-comment"># Activity: Patient Checked In
        if appt.get(class="hl-string">'startcheckin'):
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Patient Checked In',
                class="hl-string">'EventTimestamp': appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'startcheckin'), class=class="hl-string">"hl-comment"># combining date and time
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id
            })
            
        class=class="hl-string">"hl-comment"># Activity: Patient Discharged (Ambulatory Checkout)
        if appt.get(class="hl-string">'stopcheckin'):
            events.append({
                class="hl-string">'PatientEpisodeId': episode_id,
                class="hl-string">'ActivityName': class="hl-string">'Patient Discharged',
                class="hl-string">'EventTimestamp': appt.get(class="hl-string">'date') + class="hl-string">' ' + appt.get(class="hl-string">'stopcheckin'),
                class="hl-string">'SourceSystem': class="hl-string">'athenaOne',
                class="hl-string">'PatientId': patient_id,
                class="hl-string">'DischargeDisposition': class="hl-string">'Home' class=class="hl-string">"hl-comment"># Default for ambulatory
            })

        class=class="hl-string">"hl-comment"># Activity: Claim Submitted
        if class="hl-string">'claimid' in appt:
             class=class="hl-string">"hl-comment"># Ideally query /claims/{claimId} for exact submission timestamp
             class=class="hl-string">"hl-comment"># Using appointment date as proxy if detailed claim fetch skipped
             class=class="hl-string">"hl-comment"># Here we assume we fetch claim details:
             claim_res = requests.get(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/claims/{appt["claimid"]}', headers=headers)
             if claim_res.status_code == 200:
                 claim_data = claim_res.json()
                 if claim_data.get(class="hl-string">'billedservicedate'):
                     events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Claim Submitted',
                        class="hl-string">'EventTimestamp': claim_data.get(class="hl-string">'createddate', claim_data.get(class="hl-string">'billedservicedate')) + class="hl-string">' 12:00:00',
                        class="hl-string">'SourceSystem': class="hl-string">'athenaCollector',
                        class="hl-string">'PatientId': patient_id
                     })

        class=class="hl-string">"hl-comment"># Clinical Data Extraction (Requires Encounter Context)
        encounter_id = appt.get(class="hl-string">'encounterid')
        if encounter_id:
            class=class="hl-string">"hl-comment"># Activity: Initial Assessment (Vitals)
            vitals = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/vitals', headers, {})
            if vitals:
                class=class="hl-string">"hl-comment"># Take the first vital sign entry time
                first_vital = sorted(vitals, key=lambda x: x.get(class="hl-string">'date') or class="hl-string">'')[0]
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Initial Assessment Completed',
                    class="hl-string">'EventTimestamp': first_vital.get(class="hl-string">'date') + class="hl-string">' ' + (first_vital.get(class="hl-string">'time') or class="hl-string">'00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals',
                    class="hl-string">'PatientId': patient_id
                })

            class=class="hl-string">"hl-comment"># Activity: Diagnoses
            diagnoses = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/diagnoses', headers, {})
            for diag in diagnoses:
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Diagnosis Confirmed',
                    class="hl-string">'EventTimestamp': diag.get(class="hl-string">'lastmodifieddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals',
                    class="hl-string">'PrimaryDiagnosisCode': diag.get(class="hl-string">'diagnosiscode')
                })

            class=class="hl-string">"hl-comment"># Activity: Orders (Labs, Procedures, Discharge)
            orders = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/orders', headers, {})
            for order in orders:
                order_type = order.get(class="hl-string">'documentationtype', class="hl-string">'')
                created_time = order.get(class="hl-string">'createddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00')
                
                if class="hl-string">'LAB' in order_type.upper() or class="hl-string">'IMAGING' in order_type.upper():
                    events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Diagnostic Test Ordered',
                        class="hl-string">'EventTimestamp': created_time,
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })
                    class=class="hl-string">"hl-comment"># Activity: Specimen Collected (Inferred from status or specific fields if available)
                    if order.get(class="hl-string">'status') in [class="hl-string">'COMPLETED', class="hl-string">'REVIEW']:
                         events.append({
                            class="hl-string">'PatientEpisodeId': episode_id,
                            class="hl-string">'ActivityName': class="hl-string">'Specimen Collected',
                            class="hl-string">'EventTimestamp': order.get(class="hl-string">'lastmodifieddatetime', created_time), class=class="hl-string">"hl-comment"># Approximation
                            class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                        })
                
                if class="hl-string">'SURGERY' in order_type.upper() or class="hl-string">'PROCEDURE' in order_type.upper():
                     events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Procedure Performed',
                        class="hl-string">'EventTimestamp': order.get(class="hl-string">'performdate', created_time),
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })

                if class="hl-string">'DISCHARGE' in order_type.upper():
                    events.append({
                        class="hl-string">'PatientEpisodeId': episode_id,
                        class="hl-string">'ActivityName': class="hl-string">'Discharge Order Written',
                        class="hl-string">'EventTimestamp': created_time,
                        class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                    })

            class=class="hl-string">"hl-comment"># Activity: Test Results Received
            results = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/analyteresults', headers, {})
            for res in results:
                events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Test Results Received',
                    class="hl-string">'EventTimestamp': res.get(class="hl-string">'analytedatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                })

            class=class="hl-string">"hl-comment"># Activity: Treatment Plan
            class=class="hl-string">"hl-comment"># Check for Care Plan document or assessment note
            notes = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/progressnotes', headers, {})
            if notes:
                 events.append({
                    class="hl-string">'PatientEpisodeId': episode_id,
                    class="hl-string">'ActivityName': class="hl-string">'Treatment Plan Developed',
                    class="hl-string">'EventTimestamp': notes[0].get(class="hl-string">'lastmodifieddatetime', appt.get(class="hl-string">'date') + class="hl-string">' 12:00:00'),
                    class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                })

            class=class="hl-string">"hl-comment"># Activity: Medication Administered
            class=class="hl-string">"hl-comment"># Look for administration records
            meds = fetch_paginated(fclass="hl-string">'{BASE_URL}/{PRACTICE_ID}/chart/{encounter_id}/medications', headers, {})
            for med in meds:
                 if med.get(class="hl-string">'events'): class=class="hl-string">"hl-comment"># Check if administration events exist
                     for event in med[class="hl-string">'events']:
                         if event.get(class="hl-string">'type') == class="hl-string">'ADMINISTERED':
                             events.append({
                                class="hl-string">'PatientEpisodeId': episode_id,
                                class="hl-string">'ActivityName': class="hl-string">'Medication Administered',
                                class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventdate'),
                                class="hl-string">'SourceSystem': class="hl-string">'athenaClinicals'
                             })

            class=class="hl-string">"hl-comment"># Activity: Patient Transferred (Inferred from Hospital Stay/ADT data if available)
            class=class="hl-string">"hl-comment"># Mocking logic: If department ID changes in encounter history (requires fetching history)
            class=class="hl-string">"hl-comment"># For standard API, we check if class="hl-string">'admissionstatus' indicates transfer
            pass class=class="hl-string">"hl-comment"># Complexity high for standard extraction without Hospital scope

            class=class="hl-string">"hl-comment"># Activity: Follow-Up Appointment Scheduled
            class=class="hl-string">"hl-comment"># We check if this patient has a FUTURE appointment created around this time
            class=class="hl-string">"hl-comment"># This requires a separate query or processing the full appointment list post-loop
            class=class="hl-string">"hl-comment"># Simplified: Logic placeholder
            pass 

    class=class="hl-string">"hl-comment"># Post-processing for Follow-Ups (simplified)
    class=class="hl-string">"hl-comment"># Sort all appts by patient and date, check next appt creation date
    
    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(events)
    df[class="hl-string">'LastDataUpdate'] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Final Validation and Export
    if not df.empty:
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df.sort_values(by=[class="hl-string">'PatientEpisodeId', class="hl-string">'EventTimestamp'], inplace=True)
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">'Successfully exported {len(df)} rows to {OUTPUT_FILE}')
    else:
        print(class="hl-string">'No events extracted.')

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

Bereit für den Start?

Beginnen Sie jetzt mit der Optimierung Ihrer Patientenversorgung. Dieses Template ist Ihr erster Schritt, um wertvolle Erkenntnisse zu gewinnen und die Ergebnisse der Gesundheitsversorgung zu verbessern.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Ihre Patientenreise jetzt und beseitigen Sie Engpässe

Ermitteln Sie Ineffizienzen in athenahealth und verkürzen Sie die Durchlaufzeit der Patientenreise um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.

Ihr Daten-Template für die Patientenreise

Ihr Daten-Template für die Patientenreise

Attribute des Patientenpfads

Aktivitäten des Patientenpfads

Anleitungen zur Datenextraktion

Benutzerdefinierter CSV-Export mit dem athenaNet Report Builder

Schritte

Konfiguration

a Beispielabfrage python

Event-Extraktion über die athenaOne API mit Python

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie Ihre Patientenreise jetzt und beseitigen Sie Engpässe

Ihr Daten-Template für die Patientenreise

Ihr Daten-Template für die Patientenreise

Attribute des Patientenpfads

Aktivitäten des Patientenpfads

Anleitungen zur Datenextraktion

Benutzerdefinierter CSV-Export mit dem athenaNet Report Builder

Schritte

Konfiguration

a Beispielabfrage python

Event-Extraktion über die athenaOne API mit Python

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie Ihre Patientenreise jetzt und beseitigen Sie Engpässe

Ihre Privatsphäre ist uns wichtig