Ihr Daten-Template für die Patientenreise
Ihr Daten-Template für die Patientenreise
- Empfohlene klinische Attribute
- Wichtige Prozessmeilensteine
- Anleitung zur MEDITECH-Datenextraktion
Attribute der Patientenreise
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Die konkrete klinische oder administrative Aktivität, die ausgeführt wird. | ||
| Beschreibung Dieses Attribut bezeichnet den Namen des Ereignisses oder der Task, die im Patientenverlauf stattfindet. Es erfasst einzelne Schritte wie „Patient Registered“, „Medication Administered“ oder „Discharge Order Written“. Die korrekte Identifizierung von Aktivitäten ist entscheidend für die Abbildung des Prozessflusses. Die Werte werden häufig aus Transaktionscodes, Auftragsstatus oder dokumentierten Interventionen in der elektronischen Patientenakte abgeleitet. Warum das wichtig ist Definiert die Prozessschritte und wird benötigt, um die Prozessübersicht zu visualisieren. Bezugsquelle Abgeleitet aus verschiedenen Transaktionsprotokollen (OE Orders, NUR Interventions, ADM Events). Beispiele Patient registriertTriage abgeschlossenMedikament verabreichtDiagnostisches Ergebnis verifiziert | |||
| Event-Timestamp EventTimestamp | Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst den exakten Zeitpunkt einer Aktivität. Es dient dazu, Ereignisse chronologisch zu ordnen und Zeitdauern zwischen Prozessschritten zu berechnen. Timestamps mit hoher Genauigkeit sind für eine präzise Analyse von Wartezeiten erforderlich, etwa für die Zeitspanne zwischen Triage und Einschätzung oder die Durchlaufzeit diagnostischer Ergebnisse. Warum das wichtig ist Erforderlich, um Ereignisse zu ordnen sowie Durchlaufzeiten und Durchsatz zu berechnen. Bezugsquelle Spalten mit Transaktionsdatum und -zeit in den Quelltabellen. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:45:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, zu dem die Daten zuletzt extrahiert oder aktualisiert wurden. | ||
| Beschreibung Zeigt an, wann der Datensatz zuletzt verarbeitet oder in das Process-Mining-Tool geladen wurde. Dies unterstützt die Prüfung der Aktualität und stellt sicher, dass die Analyse den aktuellen Systemstand widerspiegelt. Das Attribut unterscheidet sich vom Event-Timestamp, da es den Zeitpunkt der technischen Datenpipeline und nicht den Zeitpunkt des klinischen Ereignisses angibt. Warum das wichtig ist Entscheidend für Data Governance und eine Analyse auf Grundlage aktueller Daten. Bezugsquelle Systemdatum zum Zeitpunkt der ETL-Ausführung. Beispiele 2023-11-01T00:00:00Z2023-11-02T12:00:00Z | |||
| Patientenfall PatientEpisode | Die eindeutige Kennung für einen bestimmten Zeitraum der Patientenversorgung oder einen Besuch. | ||
| Beschreibung Der Patient Episode dient als zentrale Case-Kennung für die Prozessanalyse. Er fasst alle klinischen, administrativen und finanziellen Ereignisse eines einzelnen stationären Aufenthalts oder ambulanten Besuchs zu einem zusammenhängenden Verlauf zusammen. In MEDITECH-Systemen entspricht er häufig der Kontonummer oder Visit ID. Dieses Attribut ist grundlegend für die Rekonstruktion des Patientenverlaufs von der Registrierung bis zur Entlassung. Es ermöglicht die Berechnung der Verweildauer und die Analyse klinischer Behandlungspfade. Warum das wichtig ist Er ist der erforderliche Case-Schlüssel, um unterschiedliche Ereignisse zu einer einzigen Prozessinstanz zu verknüpfen. Bezugsquelle MEDITECH-Admissions- oder Registrierungsmodul, üblicherweise das Feld Account Number. Beispiele V100938475AC29384755E993847211O229384711 | |||
| Quellsystem SourceSystem | Die Kennung des Systems, aus dem die Daten stammen. | ||
| Beschreibung Identifiziert die MEDITECH-Instanz oder das spezifische Modul, aus dem die Ereignisdaten extrahiert wurden. In Umgebungen mit mehreren Krankenhäusern hilft dieses Attribut dabei, Daten aus unterschiedlichen Einrichtungen oder Systemversionen zu unterscheiden. Bei einer Extraktion aus einem einzelnen System bleibt dieses Attribut statisch. Beim Zusammenführen von Daten ist es jedoch entscheidend, um eine einheitliche Sicht über ein Krankenhausnetzwerk hinweg zu erstellen. Warum das wichtig ist Stellt Datenherkunft und Nachvollziehbarkeit in Umgebungen mit mehreren Systemen sicher. Bezugsquelle Bei der Extraktion oder Konfiguration der System-ID fest hinterlegt. Beispiele MEDITECH_ExpanseMEDITECH_6.1Hospital_A_Main | |||
| Behandelnder Leistungserbringer AttendingProvider | Der primäre Kliniker oder Leistungserbringer, der für die Aktivität verantwortlich ist. | ||
| Beschreibung Erfasst den Namen oder die ID des Arztes, der Pflegekraft oder des Technikers, der die Aufgabe ausführt oder die Versorgung überwacht. Dieses Attribut unterstützt das Dashboard „Geschwindigkeit der Behandlungsplanerstellung“, indem es Kennzahlen zu Geschwindigkeit und Effizienz bestimmten Mitarbeitenden oder Rollen zuordnet. Es ermöglicht die Ressourcenanalyse, um Arbeitslasten auszugleichen und Schulungsbedarf beim klinischen Personal zu erkennen. Warum das wichtig ist Ermöglicht die Analyse der Ressourcenleistung und den Ausgleich der Arbeitslast. Bezugsquelle Provider- oder User-Felder in Aktivitätsprotokollen. Beispiele Dr. SmithRN JonesTech Adams | |||
| Dringlichkeitsstufe der Triage TriageAcuityLevel | Die Dringlichkeitsbewertung, die einem Patienten während der Triage zugewiesen wird. | ||
| Beschreibung Gibt die Dringlichkeit des Patientenzustands an, üblicherweise anhand einer Skala, beispielsweise von 1 bis 5, wobei 1 für kritisch steht. Dieses Attribut ist zentral für die „Ablaufanalyse der Notaufnahme“. Damit können Analysten Wartezeiten mit dem Schweregrad des Patientenzustands in Beziehung setzen und prüfen, ob besonders kritische Patienten wirksam priorisiert werden. Warum das wichtig ist Entscheidend für die Analyse der Priorisierung in der Notaufnahme und die Einhaltung von Sicherheitsvorgaben. Bezugsquelle Bildschirme für die pflegerische Einschätzung in der Notaufnahme oder Triage. Beispiele 1 - Reanimation2 - Dringender Notfall3 - Dringend4 - Weniger dringend | |||
| Entlassungsstatus DischargeDisposition | Das Ziel oder der Status des Patienten bei der Entlassung. | ||
| Beschreibung Gibt an, wohin der Patient nach der Episode gegangen ist, beispielsweise nach Hause, in eine qualifizierte Pflegeeinrichtung oder in die häusliche Pflege, beziehungsweise ob der Patient verstorben ist. Dies ist eine wichtige Ergebniskennzahl für das Dashboard „Optimierung der Entlassungsplanung“. Die Analyse zeigt, ob Verzögerungen bei der Organisation der nachstationären Versorgung zu längeren Aufenthaltsdauern beitragen. Warum das wichtig ist Wichtige Ergebniskennzahl für die Analyse von Aufenthaltsdauer und Wiederaufnahmerisiko. Bezugsquelle Bildschirme für Entlassungskodierung oder Registrierung. Beispiele Nach Hause entlassenIn ein allgemeines Kurzzeitkrankenhaus verlegtVerstorbenAuf eigenen Wunsch entgegen ärztlichem Rat gegangen | |||
| Hauptdiagnose PrimaryDiagnosis | Die wichtigste medizinische Erkrankung, die für die Patientenepisode festgestellt wurde. | ||
| Beschreibung Enthält den ICD-10-Code oder die Beschreibung des primären Grundes für die Behandlung. Dieses Attribut bildet die Grundlage für die „Analyse von Varianten klinischer Behandlungspfade“. Durch die Gruppierung von Cases nach Hauptdiagnose können klinische Verantwortliche die tatsächlichen Behandlungspfade mit dem idealen klinischen Pfad für die jeweilige Erkrankung vergleichen. Warum das wichtig ist Unverzichtbar für die Gruppierung von Cases zur Analyse klinischer Behandlungspfade. Bezugsquelle Modul für medizinische Datensätze oder Kodierung. Beispiele J18.9 - LungenentzündungI21.9 - Akuter MyokardinfarktS72.0 - Oberschenkelbruch | |||
| Ist Wiederaufnahme IsReadmission | Kennzeichen dafür, ob diese Episode innerhalb von 30 Tagen nach einer früheren Entlassung stattgefunden hat. | ||
| Beschreibung Ein boolesches Attribut, das den Wert „true“ zurückgibt, wenn das aktuelle Registrierungsdatum innerhalb von 30 Tagen nach dem Entlassungsdatum einer früheren Episode liegt. Dieses Attribut unterstützt das Dashboard „Wiederaufnahme und Versorgungsqualität“. Durch die Identifizierung von Wiederaufnahmen können Analysten die vorherige Episode zurückverfolgen und Lücken bei der Entlassungsplanung oder Nachsorge ermitteln. Warum das wichtig ist Zentrale Qualitätskennzahl mit Auswirkungen auf Vergütung und Behandlungsergebnisse. Bezugsquelle Berechnet durch den Vergleich von StartTime der aktuellen Episode mit Case EndTime des vorherigen Cases für dieselbe MedicalRecordNumber. Beispiele truefalse | |||
| Krankenhausabteilung HospitalDepartment | Die konkrete Station oder Abteilung, in der die Aktivität stattgefunden hat. | ||
| Beschreibung Identifiziert die zuständige Funktionseinheit, beispielsweise „Notaufnahme“, „Radiologie“, „ICU“ oder „Allgemeinstation“. Dieses Attribut ist für das Dashboard „Ressourcendurchsatz nach Abteilung“ von zentraler Bedeutung. Damit lassen sich Leistungskennzahlen nach Einheit aufschlüsseln. So können Engpässe bei internen Verlegungen und der Ressourcennutzung gezielt ermittelt werden. Warum das wichtig ist Wichtig für die Organisationsanalyse und die Ermittlung von Engpässen in bestimmten Einheiten. Bezugsquelle Felder für Standort oder Abteilung in Transaktionstabellen. Beispiele NotaufnahmeRadiologieIntensivstationChirurgische Station 3 | |||
| Medizinische Datensatznummer MedicalRecordNumber | Eine eindeutige Kennung für den Patienten über alle Besuche hinweg. | ||
| Beschreibung Die medizinische Datensatznummer (MRN) identifiziert einen Patienten innerhalb der Gesundheitseinrichtung eindeutig und unterscheidet sich von der episodenbezogenen ID. Sie ermöglicht es Analysten, mehrere Episoden desselben Patienten im Zeitverlauf zu verknüpfen. Dieses Attribut ist für das Dashboard „Wiederaufnahme und Versorgungsqualität“ unverzichtbar. Damit lassen sich Patienten erkennen, die innerhalb von 30 Tagen nach ihrer Entlassung erneut ins Krankenhaus kommen. Warum das wichtig ist Ermöglicht die Analyse über mehrere Episoden hinweg sowie patientenzentrierte Ansichten. Bezugsquelle Patientenstammindex oder Registrierungstabelle. Beispiele MRN-100293MRN-55928388291002 | |||
| Patiententyp PatientType | Kategorisierung des Patientenbesuchs, beispielsweise stationär, ambulant oder als Notfall. | ||
| Beschreibung Klassifiziert die Art des Krankenhausbesuchs. Häufige Werte sind „Stationär“, „Ambulant“, „Notfall“ oder „Beobachtung“. Diese Klassifizierung ist grundlegend für das Filtern und Vergleichen von Prozessen, da sich Versorgungsstandard und erwartete Dauer je nach Typ deutlich unterscheiden. Dieses Feld unterstützt das Dashboard „Optimierung der Entlassungsplanung“, indem es die erwartete Aufenthaltsdauer nach Patiententyp aufschlüsselt. Warum das wichtig ist Grundlegende Segmentierung für den Prozessvergleich, etwa stationär gegenüber ambulant. Bezugsquelle Aufnahme- oder Besuchstabellen, beispielsweise AdmVisits.Status. Beispiele StationärNotfallAmbulante ChirurgieBeobachtung | |||
| Abrechnungsbetrag ChargeAmount | Der finanzielle Wert, der einer bestimmten Aktivität oder Leistung zugeordnet ist. | ||
| Beschreibung Stellt die für ein bestimmtes Event, etwa eine Untersuchung oder eine Zimmerleistung, gebuchten Kosten oder Gebühren dar. Obwohl das Attribut primär finanzieller Natur ist, gibt es Aufschluss über den Ressourcenaufwand. In aggregierter Form hilft es, die finanziellen Auswirkungen von Prozessvarianten zu verstehen. Der Schwerpunkt der angeforderten Ansicht liegt jedoch auf dem klinischen Ablauf. Warum das wichtig ist Ergänzt die Prozessanalyse um eine finanzielle Dimension. Bezugsquelle Modul für Abrechnung oder BAR (Billing/Accounts Receivable). Beispiele 150.001200.5045.00 | |||
| Aufnahmequelle AdmitSource | Herkunft des Patienten, beispielsweise Zuhause, Verlegung oder Überweisung. | ||
| Beschreibung Beschreibt die Herkunft der Patientenaufnahme, beispielsweise „Ärztliche Überweisung“, „Notaufnahme“ oder „Verlegung aus einem anderen Krankenhaus“. Dadurch wird nachvollziehbar, wie Patienten in das System gelangen. Diese Information hilft, Aufnahmemuster und deren Auswirkungen auf die „Ablaufanalyse der Notaufnahme“ sowie die Ressourcenplanung zu verstehen. Warum das wichtig ist Liefert Kontext zu Patientenzufluss und Nachfragekanälen. Bezugsquelle Registrierungsdaten zu Aufnahmen. Beispiele NotaufnahmeÜberweisung aus einer KlinikVerlegung aus einer Pflegeeinrichtung | |||
| Auftragskategorie OrderCategory | Klassifizierung klinischer Aufträge, beispielsweise Labor, Radiologie oder Konsil. | ||
| Beschreibung Gruppiert Aufträge in übergeordnete Kategorien wie „Labor“, „Radiologie“, „Ernährung“ oder „Konsil“. Dies ist für das Dashboard „Durchlaufzeit diagnostischer Leistungen“ unverzichtbar. Damit lassen sich Workflows getrennt analysieren, um Durchlaufzeiten für Bildgebung und Blutuntersuchungen zu vergleichen, da dort häufig unterschiedliche Engpässe auftreten. Warum das wichtig ist Unterteilt diagnostische und therapeutische Workflows. Bezugsquelle Kategoriefelder des Order-Entry-Moduls (OE). Beispiele LaborRadiologiePflegeApotheke | |||
| Ist Compliance-Verstoß IsAdherenceViolation | Kennzeichen dafür, ob der Case vom standardisierten klinischen Behandlungspfad abweicht. | ||
| Beschreibung Ein boolesches Kennzeichen, das auf „true“ gesetzt wird, wenn die Abfolge der Aktivitäten nicht mit dem definierten Referenzmodell für die Hauptdiagnose des Patienten übereinstimmt. Dieses Attribut unterstützt die „Analyse von Varianten klinischer Behandlungspfade“. Damit lassen sich „nicht konforme“ Cases schnell filtern und die Gründe untersuchen, aus denen der Versorgungsstandard nicht eingehalten wurde. Warum das wichtig ist Identifiziert Prozessabweichungen und Varianten schnell. Bezugsquelle Wird durch Algorithmen zur Konformitätsprüfung berechnet. Beispiele truefalse | |||
| Medikamentenname MedicationName | Der Name des verabreichten Arzneimittels. | ||
| Beschreibung Erfasst das konkrete Arzneimittel in Events vom Typ „Medikament verabreicht“. Dieses Attribut wird für das Dashboard „Compliance bei der Medikamentengabe“ benötigt. Damit kann die Pflegeleitung prüfen, ob bestimmte risikoreiche oder zeitkritische Medikamente, etwa Antibiotika bei Sepsis, innerhalb des vorgesehenen therapeutischen Zeitfensters verabreicht werden. Warum das wichtig ist Erforderlich für die Analyse klinischer Compliance und Patientensicherheit. Bezugsquelle Module für die Apotheke (PHA) oder die Verifikation am Patientenbett (BMV). Beispiele ParacetamolVancomycinHeparinInsulin | |||
| Wartezeit bis zur Triage TriageWaitTime | Zeitspanne zwischen Registrierung und Abschluss der Triage. | ||
| Beschreibung Die berechnete Dauer zwischen dem Event „Patient registriert“ und dem Event „Triage abgeschlossen“. Sie fließt direkt in die KPI „Durchschnittliche Durchlaufzeit der Triage“ ein. Durch die Überwachung dieser Dauer können Verantwortliche der Notaufnahme die Personalbesetzung zu Spitzenzeiten anpassen und die Sicherheitsstandards für Patienten einhalten. Warum das wichtig ist Wichtige operative Kennzahl für Notaufnahmen. Bezugsquelle Berechnete Differenz zwischen den Timestamps bestimmter Aktivitäten. Beispiele 15 Minuten1 Stunde 20 Minuten | |||
Aktivitäten der Patientenreise
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Auftrag erteilt | Erfasst die Anforderung einer Leistung, eines Medikaments oder einer diagnostischen Untersuchung durch einen Kliniker. Dieses Ereignis löst nachgelagerte klinische Aktivitäten aus. | ||
| Warum das wichtig ist Dient als Ausgangspunkt für die KPI „Diagnostic Services Turnaround“. Der Vergleich mit dem Ausführungszeitpunkt macht Verzögerungen bei der Leistungserbringung sichtbar. Bezugsquelle MEDITECH-OE-Modul (Order Entry). Erfasst aus der Tabelle „OeOrders“ anhand des Feldes „Order Date/Time“. Erfassen Wird protokolliert, wenn die Transaktion Order Enter ausgeführt wird Ereignistyp explicit | |||
| Diagnose dokumentiert | Der Zeitpunkt, an dem ein Kliniker eine codierte Diagnose (ICD-10) in der Patientenakte erfasst. Dies löst häufig bestimmte klinische Behandlungspfade aus. | ||
| Warum das wichtig ist Ermöglicht die „Clinical Pathway Variant Analysis“, indem der Fall kategorisiert wird. Entscheidend für die Bildung von Vergleichsgruppen. Bezugsquelle MEDITECH-ABS-Modul (Abstracting) oder Medical Records. Erfasst, wenn Diagnosecodes dem Konto zugeordnet werden. Erfassen Wird protokolliert, wenn die Transaktion Diagnosis Enter ausgeführt wird Ereignistyp explicit | |||
| Diagnostisches Ergebnis verifiziert | Kennzeichnet, dass eine diagnostische Untersuchung im Labor oder in der Radiologie durchgeführt und das Ergebnis von einem Techniker oder Radiologen freigegeben wurde. Damit ist der diagnostische Auftrag im Wesentlichen abgeschlossen. | ||
| Warum das wichtig ist Endpunkt für die Messung von „Diagnostic Services Turnaround“. Unverzichtbar für die Analyse von Engpässen in unterstützenden Abteilungen. Bezugsquelle MEDITECH-LAB- oder ITS-Module (Imaging and Therapeutic Services). Erfasst anhand von Statusänderungen des Ergebnisses in Verified oder Signed. Erfassen Wird protokolliert, wenn sich das Statusfeld in Verified ändert Ereignistyp explicit | |||
| Entlassungsauftrag erstellt | Der Timestamp, zu dem der Arzt den Auftrag zur Genehmigung der Entlassung unterzeichnet. Damit beginnt die Phase der Entlassungsplanung. | ||
| Warum das wichtig ist Dient als Ausgangspunkt für „Discharge Planning Lead Time“. Die Zeitspanne bis zum tatsächlichen Verlassen der Einrichtung zeigt operative Ineffizienz. Bezugsquelle MEDITECH-OE-Modul (Order Entry). Aufträge nach Category = Discharge filtern. Erfassen Wird protokolliert, wenn die Transaktion Order Enter ausgeführt wird Ereignistyp explicit | |||
| Medikament verabreicht | Erfasst die tatsächliche Verabreichung eines Medikaments an den Patienten durch das Pflegepersonal. Die Erfassung erfolgt üblicherweise per Barcode-Scan am Patientenbett. | ||
| Warum das wichtig ist Unterstützt die Analyse der „Medication Administration Compliance“. Macht Sicherheitsrisiken und Unterbrechungen in den Abläufen der Pflegeeinheiten sichtbar. Bezugsquelle MEDITECH-PHA-Modul (Pharmacy) oder eMAR (Electronic Medication Administration Record). Das Feld „AdminDateTime“ in der Verabreichungshistorie. Erfassen Wird protokolliert, wenn die Transaktion Med Admin ausgeführt wird Ereignistyp explicit | |||
| Patient entlassen | Der administrative Abschluss des Besuchs. Der Patient hat die Einrichtung physisch verlassen und das Bett wird freigegeben. | ||
| Warum das wichtig ist Das formale Ende des Prozesses. Wird zur Berechnung der endgültigen Verweildauer und zur Definition des 30-Tage-Zeitraums für Wiederaufnahmen verwendet. Bezugsquelle MEDITECH-ADM-Modul (Admissions). Das Feld „DischargeDateTime“ im Besuchsdatensatz. Erfassen Wird protokolliert, wenn die Transaktion Discharge Patient ausgeführt wird Ereignistyp explicit | |||
| Patient registriert | Dieses Ereignis kennzeichnet die administrative Erstellung des Patientenfalls oder Besuchsdatensatzes im System. Es erfasst den ersten Eintrittspunkt in das MEDITECH-ADM-Modul (Admissions). | ||
| Warum das wichtig ist Definiert den Beginn des Patientenverlaufs und der Berechnung der Durchlaufzeit. Unverzichtbar für die Berechnung der Gesamtverweildauer. Bezugsquelle MEDITECH-ADM-Modul. Quelle ist die Tabelle „Admissions“, insbesondere das Feld „AdmitDateTime“ oder der Timestamp zur Erstellung des Transaktionsprotokolls. Erfassen Wird protokolliert, wenn die Transaktion New Visit ausgeführt wird Ereignistyp explicit | |||
| Patient verlegt | Kennzeichnet die physische Verlegung eines Patienten von einem Standort (Station, Zimmer oder Bett) an einen anderen. Erfasst den Weg durch das Krankenhaus. | ||
| Warum das wichtig ist Wichtig für die Analyse von Engpässen bei internen Verlegungen. Lange Verlegungszeiten weisen auf konkurrierende Ressourcennutzung oder Verzögerungen beim Patiententransport hin. Bezugsquelle MEDITECH-ADM-Modul (Admissions). Erfasst aus der „Location History“ oder den Transaktionsprotokollen von „RoomBed“. Erfassen Wird protokolliert, wenn die Transaktion Transfer Patient ausgeführt wird Ereignistyp explicit | |||
| Triage abgeschlossen | Kennzeichnet den Abschluss der ersten pflegerischen Einschätzung in der Notaufnahme. Dabei werden die Dringlichkeitsstufe und der Schweregrad des Patienten bestimmt. | ||
| Warum das wichtig ist Entscheidend für das Dashboard zur Analyse des Notaufnahmeablaufs, um Durchsatz und Wartezeiten zu messen. Bezugsquelle MEDITECH-EDM-Modul (Emergency Department Management). Abgeleitet aus Statusänderungen im EDM-Tracker oder dem Timestamp des Dokuments zur Triage-Einschätzung. Erfassen Wird protokolliert, wenn sich das Statusfeld in Triaged ändert Ereignistyp explicit | |||
| Konsil abgeschlossen | Der Abschluss der fachärztlichen Einschätzung. Er wird häufig anhand der Ablage eines bestimmten Dokumenttyps abgeleitet, beispielsweise „Cardiology Consult Note“. | ||
| Warum das wichtig ist Endpunkt für die Messung der Reaktionszeit von Fachärzten. Entscheidend für einen zeitgerechten Fortschritt der Versorgung. Bezugsquelle MEDITECH-PCM-Modul (Provider Order Management) oder EMR. Abgeleitet aus Timestamps der Dokumenterstellung mit bestimmten Titeln. Erfassen Statusfeld vorher und nachher vergleichen Ereignistyp inferred | |||
| Konsilanfrage gesendet | Eine spezielle Auftragsart zur Anforderung einer fachärztlichen Einschätzung. Damit beginnt die Zeitmessung für das Dashboard „Specialist Consultation Response“. | ||
| Warum das wichtig ist Macht Engpässe bei der Koordination interdisziplinärer Versorgung sichtbar. Lange Wartezeiten verlängern hier die Verweildauer. Bezugsquelle MEDITECH-OE-Modul (Order Entry). Identifiziert durch Filterung von „OeOrders“ nach Category = Consult. Erfassen Wird protokolliert, wenn die Transaktion Order Enter ausgeführt wird Ereignistyp explicit | |||
| Nachsorgetermin gebucht | Die Terminierung eines zukünftigen Patiententermins. Diese Aktivität unterstützt die kontinuierliche Versorgung nach der Entlassung. | ||
| Warum das wichtig ist Unterstützt die Analyse der „Follow-up Appointment Scheduling“. Steht in Zusammenhang mit niedrigeren Wiederaufnahmeraten. Bezugsquelle MEDITECH-SCH-Modul (Scheduling). Abgeleitet durch die Verknüpfung eines neuen Termindatensatzes, der nahe am Entlassungsdatum erstellt wurde, mit der Patienten-ID. Erfassen Durch den Vergleich der Felder Appointment Created Date und Discharge Date ableiten Ereignistyp inferred | |||
| Probe entnommen | Kennzeichnet die physische Entnahme einer biologischen Probe für die Laboranalyse. Diese Aktivität bildet die Verbindung zwischen Anforderung und Verarbeitung. | ||
| Warum das wichtig ist Ein detaillierter Prozessschritt, der häufig für Verzögerungen im diagnostischen Ablauf verantwortlich ist. Er hilft dabei, Verzögerungen in der Pflege von Verzögerungen im Labor zu unterscheiden. Bezugsquelle MEDITECH-LAB-Modul. Wird üblicherweise erfasst, wenn ein Phlebotomist den Barcode scannt oder den Probenstatus in Collected ändert. Erfassen Wird protokolliert, wenn die Transaktion Collect Specimen ausgeführt wird Ereignistyp explicit | |||
| Versorgungsplan gestartet | Bezeichnet die Erstellung oder Zuweisung eines spezifischen pflegerischen oder interdisziplinären Versorgungsplans. Dies entspricht dem Konzept „Treatment Plan Developed“. | ||
| Warum das wichtig ist Misst „Treatment Plan Development Velocity“. Verzögerungen an dieser Stelle weisen auf Lücken bei klinischen Entscheidungsprozessen hin. Bezugsquelle MEDITECH-PCS-Modul (Patient Care System) oder Care Manager. Timestamp der Anwendung eines standardisierten Versorgungsplans auf den Patienten. Erfassen Wird protokolliert, wenn die Transaktion Care Plan Add ausgeführt wird Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
Server des Data Repository identifizieren: Ermitteln Sie die Microsoft-SQL-Server-Instanz, auf der Ihr MEDITECH Data Repository (DR) gehostet wird. Sie unterscheidet sich von der transaktionalen M-AT- oder dateibasierten Datenbank. Sie benötigen schreibgeschützte Zugangsdaten, in der Regel für ein Servicekonto.
Schemaversion bestimmen: Die Strukturen des MEDITECH DR unterscheiden sich geringfügig zwischen Magic, Client/Server (6.x) und Expanse. Die folgende Abfrage verwendet standardmäßige Namenskonventionen, zum Beispiel AdmVisits und OeOrders. Überprüfen Sie diese Tabellennamen im Object Explorer Ihres lokalen SQL Server Management Studio (SSMS).
Umfang festlegen: Identifizieren Sie die primäre Tabelle für Patientenbesuche. Je nach DR-Konfiguration heißt sie meist AdmVisits, RegAcct oder AbstractData. Die Abfrage verwendet AdmVisits als Anker für den Patient Episode.
SQL-Umgebung vorbereiten: Öffnen Sie SSMS und verbinden Sie sich mit dem DR. Öffnen Sie ein neues Abfragefenster. Stellen Sie sicher, dass Sie mit der richtigen Datenbank verbunden sind, die häufig livedb oder ähnlich heißt.
Parameter konfigurieren: Ersetzen Sie im bereitgestellten SQL-Skript die Platzhalter für Datumsbereiche, zum Beispiel „2023-01-01“, sowie die Einrichtungs-Identifier, falls Ihr DR Daten mehrerer Standorte enthält.
Extraktion ausführen: Führen Sie das vollständige T-SQL-Skript aus. Es verwendet Common Table Expressions (CTEs), um zunächst die relevante Population zu definieren und anschließend mehrere Datenquellen mit UNION ALL zu einem standardisierten Event Log zusammenzuführen.
NULL-Attribute behandeln: Die Abfrage enthält eine Logik zur Behandlung möglicher NULL-Werte in Timestamps, unter anderem mit COALESCE, und stellt sicher, dass wichtige Verknüpfungsschlüssel (SourceID/VisitID) vorhanden sind.
Triage- und Notfalldaten prüfen: MEDITECH speichert ED-Daten in bestimmten Modulen. Stellen Sie sicher, dass die Tabellen EdVisits oder NurInterventions befüllt sind, wenn Sie Abläufe in der Notaufnahme analysieren.
Auftragskategorien validieren: Die Abfrage trennt allgemeine Aufträge, Konsile und Entlassungsaufträge anhand von Category-URNs oder Mnemonics. Möglicherweise müssen Sie die WHERE-Klauseln an das spezifische Mnemonic-Verzeichnis Ihrer Einrichtung anpassen.
Daten exportieren: Klicken Sie nach Abschluss der Abfrage im Ergebnisraster von SSMS mit der rechten Maustaste und wählen Sie „Save Results As CSV“. Stellen Sie sicher, dass die Kopfzeilen enthalten sind.
Formatierung abschließen: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Datumsformate dem ISO-8601-Format YYYY-MM-DD HH:MM:SS entsprechen, bevor Sie die Datei in ProcessMind importieren.
Konfiguration
- Datenbankzugriff: Erfordert db_datareader-Berechtigungen für die MEDITECH-DR-SQL-Datenbank.
- Datumsbereich: Für die Extraktion werden 3 bis 6 Monate entlassener Patienten empfohlen, damit abgeschlossene Zyklen erfasst werden.
- Einrichtungsfilter: Wenn das DR Daten mehrerer Einrichtungen enthält, filtern Sie die BaseVisits-CTE nach FacilityID oder SourceSystemID.
- Definition des Patient Episode: Das Skript verwendet die eindeutige VisitID, die häufig als Account Number oder Episode Number bezeichnet wird, als Case ID.
- Performance: Die Abfrage verwendet eine CTE als Anker, um den Scanbereich zu begrenzen. Stellen Sie für eine gute Performance sicher, dass in der Tabelle AdmVisits Indizes für AdmitDate und DischargeDate vorhanden sind.
- Latenz: Übertragungen in das Data Repository können je nach Standortkonfiguration zwischen 15 Minuten und 24 Stunden verzögert sein. Prüfen Sie den Timestamp LastDataUpdate.
a Beispielabfrage sql
/* MEDITECH Data Repository T-SQL Extraction for ProcessMind */
/* Process: Patient Journey */
/* Dialect: T-SQL */
WITH BaseVisits AS (
/* Define the population: Discharged patients within a date range */
SELECT
V.VisitID,
V.PatientID,
V.AccountNumber AS MedicalRecordNumber,
V.AdmitDateTime,
V.DischargeDateTime,
V.FacilityID,
V.PatientType,
V.AttendingProviderID,
V.DischargeDisposition,
NULLIF(DATEDIFF(MINUTE, V.AdmitDateTime, V.DischargeDateTime), 0) / 1440.0 AS LengthOfStay,
/* Flag readmissions logic would go here, simplified as 0 for base script */
0 AS IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmVisits] V
WHERE
V.DischargeDateTime >= '2023-01-01'
AND V.DischargeDateTime < '2023-04-01'
AND V.Status = 'DIS' /* Discharged Status */
),
PatientDiagnoses AS (
/* Helper CTE for Primary Diagnosis to avoid duplicates in joins */
SELECT
D.VisitID,
MAX(D.ICDCode) AS PrimaryDiagnosis
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] D
WHERE
D.Rank = 1 /* Primary Diagnosis Rank */
GROUP BY
D.VisitID
),
TriageData AS (
/* Helper CTE for Triage Acuity */
SELECT
T.VisitID,
MAX(T.AcuityLevel) AS TriageAcuityLevel
FROM
[YourDatabaseName].[dbo].[EdTriage] T
GROUP BY
T.VisitID
)
/* 1. Patient Registered */
SELECT
V.VisitID AS PatientEpisode,
'Patient Registered' AS ActivityName,
V.AdmitDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.AdmitDateTime IS NOT NULL
UNION ALL
/* 2. Triage Completed */
SELECT
V.VisitID AS PatientEpisode,
'Triage Completed' AS ActivityName,
ED.TriageDateTime AS EventTimestamp,
'MEDITECH_ED' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Emergency Department' AS HospitalDepartment,
ED.TriageNurseID AS AttendingProvider,
V.PatientType,
ED.AcuityLevel AS TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[EdTriage] ED
INNER JOIN BaseVisits V ON ED.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
WHERE
ED.TriageDateTime IS NOT NULL
UNION ALL
/* 3. Order Placed (General) */
SELECT
V.VisitID AS PatientEpisode,
'Order Placed' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category NOT IN ('CONSULT', 'DISCHARGE') /* Exclude specific types handled elsewhere */
UNION ALL
/* 4. Specimen Collected */
SELECT
V.VisitID AS PatientEpisode,
'Specimen Collected' AS ActivityName,
L.CollectionDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
L.CollectedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabSpecimens] L
INNER JOIN BaseVisits V ON L.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
L.CollectionDateTime IS NOT NULL
UNION ALL
/* 5. Diagnostic Result Verified */
SELECT
V.VisitID AS PatientEpisode,
'Diagnostic Result Verified' AS ActivityName,
R.VerifiedDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
R.VerifiedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabResults] R
INNER JOIN BaseVisits V ON R.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
R.VerifiedDateTime IS NOT NULL
UNION ALL
/* 6. Diagnosis Documented */
SELECT
V.VisitID AS PatientEpisode,
'Diagnosis Documented' AS ActivityName,
DX.EntryDateTime AS EventTimestamp,
'MEDITECH_ABS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
DX.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] DX
INNER JOIN BaseVisits V ON DX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
DX.EntryDateTime IS NOT NULL
UNION ALL
/* 7. Care Plan Initiated */
SELECT
V.VisitID AS PatientEpisode,
'Care Plan Initiated' AS ActivityName,
N.CreateDateTime AS EventTimestamp,
'MEDITECH_NUR' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
N.NurseUnit AS HospitalDepartment,
N.NurseID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[NurPlan] N
INNER JOIN BaseVisits V ON N.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
N.CreateDateTime IS NOT NULL
UNION ALL
/* 8. Medication Administered */
SELECT
V.VisitID AS PatientEpisode,
'Medication Administered' AS ActivityName,
M.AdminDateTime AS EventTimestamp,
'MEDITECH_PHA' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
M.AdminLocation AS HospitalDepartment,
M.AdministeredBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[PhaMedAdmin] M
INNER JOIN BaseVisits V ON M.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
M.Status = 'ADMINISTERED'
UNION ALL
/* 9. Consult Request Sent */
SELECT
V.VisitID AS PatientEpisode,
'Consult Request Sent' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
UNION ALL
/* 10. Consultation Completed */
SELECT
V.VisitID AS PatientEpisode,
'Consultation Completed' AS ActivityName,
O.CompletedDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
AND O.Status = 'COMPLETED'
AND O.CompletedDateTime IS NOT NULL
UNION ALL
/* 11. Patient Transferred */
SELECT
V.VisitID AS PatientEpisode,
'Patient Transferred' AS ActivityName,
TX.TransferDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
TX.ToLocation AS HospitalDepartment,
NULL AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmRoomTx] TX
INNER JOIN BaseVisits V ON TX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
TX.TransferDateTime IS NOT NULL
UNION ALL
/* 12. Discharge Order Written */
SELECT
V.VisitID AS PatientEpisode,
'Discharge Order Written' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'DISCHARGE'
OR O.Mnemonic LIKE '%DISCHARGE%'
UNION ALL
/* 13. Patient Discharged */
SELECT
V.VisitID AS PatientEpisode,
'Patient Discharged' AS ActivityName,
V.DischargeDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.DischargeDateTime IS NOT NULL
UNION ALL
/* 14. Follow-up Booked */
SELECT
V.VisitID AS PatientEpisode,
'Follow-up Booked' AS ActivityName,
S.BookDateTime AS EventTimestamp,
'MEDITECH_SCH' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
S.ApptDepartment AS HospitalDepartment,
S.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[SchAppt] S
INNER JOIN BaseVisits V ON S.PatientID = V.PatientID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
S.BookDateTime > V.AdmitDateTime
AND S.BookDateTime <= DATEADD(day, 30, V.DischargeDateTime) /* Logic to link appt to episode */
AND S.Status NOT IN ('CANCELLED', 'NOSHOW'); Bereit für den Start?
Beginnen Sie noch heute damit, Ihre klinischen Abläufe zu verbessern, indem Sie dieses Template auf Ihre MEDITECH-Daten anwenden. Unser Team unterstützt Sie dabei, Ihre Datenextraktion für eine möglichst effiziente Krankenhausversorgung zu verfeinern.
Optimieren Sie jetzt den Patientenpfad und verkürzen Sie Verzögerungen
Verkürzen Sie Durchlaufzeiten um 30 Prozent und steigern Sie die Effizienz Ihres Krankenhauses
Keine Kreditkarte erforderlich. Starten Sie in wenigen Minuten.