Ihr Daten-Template für den Patientenverlauf
Ihr Daten-Template für den Patientenverlauf
- Empfohlene klinische Attribute
- Wichtige Prozessmeilensteine
- Anleitung zur MEDITECH-Datenextraktion
Attribute zum Patientenverlauf
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Die konkrete klinische oder administrative Handlung. | ||
| Beschreibung Dieses Attribut bezeichnet das Ereignis oder die Aufgabe im Behandlungsverlauf. Es erfasst einzelne Schritte wie 'Patient registriert', 'Medikament verabreicht' oder 'Entlassungsanordnung erstellt'. Die korrekte Erfassung der Aktivitäten ist entscheidend für die Darstellung des Prozessablaufs. Die Werte stammen häufig aus Transaktionscodes, Auftragsstatus oder dokumentierten Maßnahmen in der elektronischen Patientenakte. Warum das wichtig ist Definiert die Prozessschritte und ist erforderlich, um die Prozessübersicht zu visualisieren. Woher beziehen Abgeleitet aus verschiedenen Transaktionsprotokollen (OE Orders, NUR Interventions, ADM Events). Beispiele Patient registriertTriage abgeschlossenMedikament verabreichtDiagnostisches Ergebnis bestätigt | |||
| Ereigniszeitstempel EventTimestamp | Datum und Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt einer Aktivität. Es dient dazu, Ereignisse chronologisch zu ordnen und Zeitspannen zwischen Prozessschritten zu berechnen. Präzise Zeitstempel sind erforderlich, um Wartezeiten zuverlässig zu analysieren, etwa die Zeit zwischen Triage und Untersuchung oder die Durchlaufzeit diagnostischer Ergebnisse. Warum das wichtig ist Erforderlich, um Ereignisse zu ordnen und Zykluszeiten sowie Durchsatz zu berechnen. Woher beziehen Datums- und Uhrzeitspalten in den Quelltabellen. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:45:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Extraktion oder Aktualisierung der Daten. | ||
| Beschreibung Gibt an, wann der Datensatz zuletzt verarbeitet oder in das Process-Mining-Tool geladen wurde. So lässt sich die Aktualität der Daten prüfen und sicherstellen, dass die Analyse den aktuellen Systemstand widerspiegelt. Dieser Wert unterscheidet sich vom Ereignis-Timestamp: Er gibt den Zeitpunkt in der technischen Datenpipeline wieder, nicht den Zeitpunkt des klinischen Ereignisses. Warum das wichtig ist Entscheidend für die Data Governance und dafür, dass die Analyse auf aktuellen Daten basiert. Woher beziehen Systemdatum zum Zeitpunkt der ETL-Ausführung. Beispiele 2023-11-01T00:00:00Z2023-11-02T12:00:00Z | |||
| Patient Episode PatientEpisode | Die eindeutige Kennung für einen bestimmten Zeitraum der Patientenversorgung oder einen Besuch. | ||
| Beschreibung Der Patient Episode dient als zentrale Case-ID für die Prozessanalyse. Er fasst alle klinischen, administrativen und finanziellen Ereignisse eines Krankenhausaufenthalts oder ambulanten Besuchs zu einem zusammenhängenden Behandlungsverlauf zusammen. In MEDITECH-Systemen entspricht er häufig der Kontonummer oder Visit ID. Dieses Attribut ist entscheidend, um den Behandlungsverlauf von der Registrierung bis zur Entlassung zu rekonstruieren. So lassen sich die Verweildauer berechnen und klinische Behandlungspfade analysieren. Warum das wichtig ist Dies ist der erforderliche Case-Schlüssel, mit dem sich einzelne Ereignisse zu einer Prozessinstanz verknüpfen lassen. Woher beziehen MEDITECH-Modul Admissions oder Registration, in der Regel das Feld Account Number. Beispiele V100938475AC29384755E993847211O229384711 | |||
| Quellsystem SourceSystem | Die Kennung des Systems, aus dem die Daten stammen. | ||
| Beschreibung Gibt die MEDITECH-Instanz oder das spezifische Modul an, aus dem die Ereignisdaten extrahiert wurden. In Umgebungen mit mehreren Krankenhäusern lassen sich damit Daten aus verschiedenen Einrichtungen oder Systemversionen unterscheiden. Bei einer Extraktion aus einem einzelnen System ist dieses Attribut statisch. Beim Zusammenführen von Daten aus mehreren Systemen ist es jedoch entscheidend, um eine einheitliche Sicht auf das Krankenhausnetzwerk zu erhalten. Warum das wichtig ist Sichert die Datenherkunft und Rückverfolgbarkeit in Umgebungen mit mehreren Systemen. Woher beziehen Wird bei der Extraktion oder in der System-ID-Konfiguration fest codiert. Beispiele MEDITECH_ExpanseMEDITECH_6.1Hospital_A_Main | |||
| Behandelnde Fachkraft AttendingProvider | Die primär für die Aktivität verantwortliche Ärztin, der verantwortliche Arzt oder die zuständige Fachkraft. | ||
| Beschreibung Erfasst den Namen oder die ID der Ärztin, des Arztes, der Pflegekraft oder der technischen Fachkraft, die die Aufgabe ausführt oder die Versorgung betreut. Dieses Attribut unterstützt das Dashboard „Geschwindigkeit der Behandlungsplanerstellung“, indem es Kennzahlen zu Geschwindigkeit und Effizienz bestimmten Mitarbeitenden oder Rollen zuordnet. Die Ressourcenanalyse hilft dabei, Arbeitslasten auszugleichen und den Schulungsbedarf des klinischen Personals zu ermitteln. Warum das wichtig ist Ermöglicht die Analyse der Ressourcenleistung und den Ausgleich der Arbeitslast. Woher beziehen Felder für Behandelnde oder Benutzer in Aktivitätsprotokollen. Beispiele Dr. SmithRN JonesTech Adams | |||
| Entlassungsstatus DischargeDisposition | Ziel oder Status des Patienten bei der Entlassung. | ||
| Beschreibung Gibt an, wohin der Patient nach dem Fall entlassen wurde, zum Beispiel nach Hause, in eine Pflegeeinrichtung oder in die häusliche Pflege, oder ob der Patient verstorben ist. Diese Kennzahl ist ein wichtiger Bestandteil des Dashboards „Optimierung der Entlassungsplanung“. Die Analyse zeigt, ob Verzögerungen bei der Suche nach einer Anschlussversorgung zu längeren Aufenthalten beitragen. Warum das wichtig ist Wichtige Ergebniskennzahl für die Analyse der Aufenthaltsdauer und des Wiederaufnahmerisikos. Woher beziehen Erfassungsmasken für Entlassungskodierung oder Registrierung. Beispiele Nach Hause entlassenIn ein Akutkrankenhaus verlegtVerstorbenGegen ärztlichen Rat entlassen | |||
| Hauptdiagnose PrimaryDiagnosis | Die wichtigste medizinische Diagnose für den Patientenfall. | ||
| Beschreibung Enthält den ICD-10-Code oder die Beschreibung des Hauptgrunds für die Behandlung. Sie bildet die Grundlage für die „Variantenanalyse klinischer Behandlungspfade“. Wenn klinische Verantwortliche Fälle nach Hauptdiagnose gruppieren, können sie die tatsächlichen Behandlungsverläufe mit dem idealen klinischen Behandlungspfad für die jeweilige Erkrankung vergleichen. Warum das wichtig ist Unverzichtbar, um Fälle für die Analyse klinischer Behandlungspfade zu gruppieren. Woher beziehen Modul für medizinische Akten oder Kodierung. Beispiele J18.9 - PneumonieI21.9 - Akuter MyokardinfarktS72.0 - Oberschenkelbruch | |||
| Krankenhausabteilung HospitalDepartment | Die konkrete Station oder Abteilung, in der die Aktivität stattgefunden hat. | ||
| Beschreibung Gibt die zuständige Organisationseinheit für die Aktivität an, zum Beispiel „Notaufnahme“, „Radiologie“, „Intensivstation“ oder „Allgemeinstation“. Dieses Attribut ist für das Dashboard „Ressourcendurchsatz nach Abteilung“ wichtig. Es ermöglicht, Leistungskennzahlen nach Organisationseinheit aufzuschlüsseln und Engpässe bei internen Verlegungen und der Ressourcennutzung zu erkennen. Warum das wichtig ist Wichtig für die Organisationsanalyse und das Erkennen von Engpässen in bestimmten Organisationseinheiten. Woher beziehen Felder für Standort oder Abteilung in Transaktionstabellen. Beispiele NotaufnahmeRadiologieIntensivstationChirurgische Station 3 | |||
| Medizinische Patientennummer MedicalRecordNumber | Eine eindeutige Kennung für den Patienten über alle Besuche hinweg. | ||
| Beschreibung Die Medical Record Number (MRN) identifiziert einen Patienten innerhalb der Gesundheitseinrichtung eindeutig und unterscheidet sich von der fallbezogenen ID. Mit ihr können Analysten mehrere Fälle desselben Patienten über einen längeren Zeitraum verknüpfen. Dieses Attribut ist für das Dashboard „Wiederaufnahme und Versorgungsqualität“ unverzichtbar. Es ermöglicht, Patienten zu erkennen, die innerhalb von 30 Tagen nach ihrer Entlassung erneut ins Krankenhaus kommen. Warum das wichtig ist Ermöglicht fallübergreifende Analysen und patientenbezogene Ansichten. Woher beziehen Patientenstamm oder Registrierungstabelle. Beispiele MRN-100293MRN-55928388291002 | |||
| Patientenart PatientType | Kategorisierung des Patientenbesuchs, zum Beispiel stationär, ambulant oder Notfall. | ||
| Beschreibung Klassifiziert die Art des Krankenhausbesuchs. Häufige Werte sind „Stationär“, „Ambulant“, „Notfall“ oder „Beobachtung“. Diese Klassifizierung ist grundlegend, um Prozesse zu filtern und zu vergleichen, da sich Behandlungsstandards und erwartete Dauer je nach Patientenart deutlich unterscheiden. Im Dashboard „Optimierung der Entlassungsplanung“ lässt sich damit die erwartete Aufenthaltsdauer nach Patientenart aufschlüsseln. Warum das wichtig ist Grundlage für den Prozessvergleich, etwa zwischen stationärer und ambulanter Behandlung. Woher beziehen Aufnahme- oder Besuchstabellen, zum Beispiel AdmVisits.Status. Beispiele StationärNotfallAmbulante OperationBeobachtung | |||
| Triage-Dringlichkeitsstufe TriageAcuityLevel | Die Dringlichkeitsstufe, die einem Patienten bei der Triage zugewiesen wird. | ||
| Beschreibung Gibt die Dringlichkeit des Patientenzustands an, üblicherweise anhand einer Skala, zum Beispiel von 1 bis 5, wobei 1 für kritisch steht. Dieses Attribut ist zentral für die „Ablaufanalyse der Notaufnahme“. Analysten können damit Wartezeiten mit dem Schweregrad des Patientenzustands vergleichen und prüfen, ob besonders kritische Patienten angemessen priorisiert werden. Warum das wichtig ist Entscheidend für die Analyse der Priorisierung in der Notaufnahme und die Einhaltung von Sicherheitsvorgaben. Woher beziehen Erfassungsmasken der Notaufnahme oder der Triagepflege. Beispiele 1 - Wiederbelebung2 - Sofortiger Behandlungsbedarf3 - Dringend4 - Weniger dringend | |||
| Wiederaufnahme IsReadmission | Kennzeichen dafür, ob dieser Fall innerhalb von 30 Tagen nach einer vorherigen Entlassung auftrat. | ||
| Beschreibung Ein boolesches Attribut, das den Wert „true“ zurückgibt, wenn das aktuelle Registrierungsdatum des Patienten innerhalb von 30 Tagen nach dem Entlassungsdatum eines vorherigen Falls liegt. Es unterstützt das Dashboard „Wiederaufnahme und Versorgungsqualität“. Anhand erkannter Wiederaufnahmen können Analysten den vorherigen Fall nachvollziehen und Lücken in der Entlassungsplanung oder Nachsorge untersuchen. Warum das wichtig ist Eine kritische Qualitätskennzahl mit Auswirkungen auf die Kostenerstattung und die Behandlungsergebnisse. Woher beziehen Berechnet durch den Vergleich der aktuellen StartTime mit der EndTime des vorherigen Falls für dieselbe MedicalRecordNumber. Beispiele truefalse | |||
| Abrechnungsbetrag ChargeAmount | Der finanzielle Wert einer bestimmten Aktivität oder Leistung. | ||
| Beschreibung Gibt die Kosten oder den abgerechneten Betrag für ein bestimmtes Ereignis an, zum Beispiel für eine Untersuchung oder die Nutzung eines Zimmers. Der Wert ist in erster Linie finanzieller Art, steht aber auch mit dem Ressourcenaufwand in Zusammenhang. In aggregierter Form zeigt er die finanziellen Auswirkungen unterschiedlicher Prozessverläufe. Im angeforderten Bericht liegt der Schwerpunkt jedoch auf dem klinischen Ablauf. Warum das wichtig ist Ergänzt die Prozessanalyse um eine finanzielle Dimension. Woher beziehen Abrechnungsmodul oder BAR-Modul (Billing/Accounts Receivable). Beispiele 150.001200.5045.00 | |||
| Abweichung von Vorgaben IsAdherenceViolation | Kennzeichen dafür, ob der Fall vom klinischen Standardpfad abwich. | ||
| 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. Es unterstützt die „Variantenanalyse klinischer Behandlungspfade“. Damit lassen sich Fälle, die nicht den Vorgaben entsprechen, schnell filtern und die Gründe für Abweichungen vom Behandlungsstandard untersuchen. Warum das wichtig ist Erkennt Prozessabweichungen und Unterschiede schnell. Woher beziehen Wird mithilfe von Algorithmen zur Konformitätsprüfung berechnet. Beispiele truefalse | |||
| Aufnahmequelle AdmitSource | Herkunft des Patienten, zum Beispiel Zuhause, Verlegung oder Überweisung. | ||
| Beschreibung Beschreibt, woher der Patient bei der Aufnahme kommt, zum Beispiel durch eine ärztliche Überweisung, aus der Notaufnahme oder durch eine Verlegung aus einem anderen Krankenhaus. So wird nachvollziehbar, auf welchem Weg Patienten in das System gelangen. Das Attribut hilft, Zugangsmuster und deren Auswirkungen auf die „Ablaufanalyse der Notaufnahme“ und die Ressourcenplanung zu verstehen. Warum das wichtig ist Zeigt, über welche Wege Patienten und die damit verbundene Nachfrage in die Einrichtung gelangen. Woher beziehen Registrierungsdaten zu Aufnahmen. Beispiele NotaufnahmeÜberweisung durch eine KlinikVerlegung aus einer Pflegeeinrichtung | |||
| Auftragskategorie OrderCategory | Klassifizierung klinischer Aufträge, zum Beispiel Labor, Radiologie oder Konsil. | ||
| Beschreibung Ordnet Aufträge übergeordneten Kategorien wie „Labor“, „Radiologie“, „Ernährung“ oder „Konsil“ zu. Diese Einteilung ist für das Dashboard „Durchlaufzeiten diagnostischer Leistungen“ wichtig. Sie ermöglicht, Workflows getrennt auszuwerten und Zykluszeiten für bildgebende Verfahren und Blutuntersuchungen zu vergleichen, bei denen häufig unterschiedliche Engpässe auftreten. Warum das wichtig ist Gliedert diagnostische und therapeutische Workflows nach Kategorien. Woher beziehen Kategoriefelder im Modul Order Entry (OE). Beispiele LaborRadiologiePflegePharmazie | |||
| Medikamentenname MedicationName | Der Name des verabreichten Arzneimittels. | ||
| Beschreibung Erfasst das konkrete Arzneimittel bei Ereignissen vom Typ „Medikament verabreicht“. Dieses Attribut wird für das Dashboard „Einhaltung der Vorgaben zur Medikamentengabe“ benötigt. Die Pflegeleitung kann damit 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 der klinischen Compliance und Patientensicherheit. Woher beziehen Module für Pharmazie (PHA) oder Verabreichungsprüfung am Patientenbett (BMV). Beispiele ParacetamolVancomycinHeparinInsulin | |||
| Triage-Wartezeit TriageWaitTime | Zeitspanne zwischen Registrierung und Abschluss der Triage. | ||
| Beschreibung Berechnete Zeitspanne zwischen dem Ereignis „Patient registriert“ und dem Ereignis „Triage abgeschlossen“. Dieser Wert fließt direkt in die KPI „Durchschnittliche Durchlaufzeit der Triage“ ein. Anhand dieser Zeitspanne können Verantwortliche der Notaufnahme die Personalbesetzung in Spitzenzeiten anpassen und so die Einhaltung der Patientensicherheitsstandards unterstützen. Warum das wichtig ist Wichtige operative Kennzahl für Notaufnahmen. Woher beziehen Berechnet als Differenz zwischen den Timestamps bestimmter Aktivitäten. Beispiele 15 Minuten1 Stunde 20 Minuten | |||
Aktivitäten im Patientenverlauf
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Auftrag erteilt | Erfasst die Anforderung einer Leistung, eines Medikaments oder einer diagnostischen Untersuchung durch einen Arzt. Dieses Ereignis löst nachfolgende klinische Aktivitäten aus. | ||
| Warum das wichtig ist Dient als Ausgangspunkt für die KPI 'Durchlaufzeit diagnostischer Leistungen'. Der Vergleich mit dem Ausführungszeitpunkt macht Verzögerungen bei der Leistungserbringung sichtbar. Woher beziehen MEDITECH-OE-Modul (Order Entry). Erfasst aus der Tabelle 'OeOrders' anhand des Feldes Order Date/Time. Erfassung Wird erfasst, wenn die Transaktion Order Enter ausgeführt wird Ereignistyp explicit | |||
| Diagnose dokumentiert | Der Zeitpunkt, an dem ein Arzt eine codierte Diagnose (ICD-10) in die Patientenakte einträgt. Dadurch werden häufig bestimmte klinische Behandlungspfade ausgelöst. | ||
| Warum das wichtig ist Ermöglicht die 'Analyse von Varianten klinischer Behandlungspfade', indem der Behandlungsfall kategorisiert wird. Wichtig für den Vergleich von Patientengruppen. Woher beziehen MEDITECH-ABS-Modul (Abstracting) oder Medical Records. Erfasst, wenn Diagnosecodes dem Konto zugeordnet werden. Erfassung Wird erfasst, wenn die Transaktion Diagnosis Enter ausgeführt wird Ereignistyp explicit | |||
| Diagnostisches Ergebnis bestätigt | Kennzeichnet den Abschluss einer diagnostischen Untersuchung (Labor oder Radiologie) und die Bestätigung des Ergebnisses durch einen Techniker oder Radiologen. Damit ist der Auftrag zur diagnostischen Untersuchung abgeschlossen. | ||
| Warum das wichtig ist Endpunkt für die Messung der 'Durchlaufzeit diagnostischer Leistungen'. Wichtig für die Analyse von Engpässen in unterstützenden Abteilungen. Woher beziehen MEDITECH-LAB- oder ITS-Module (Imaging and Therapeutic Services). Erfasst anhand von Ergebnisstatusänderungen auf Verified oder Signed. Erfassung Wird erfasst, wenn sich das Statusfeld in Verified ändert Ereignistyp explicit | |||
| Entlassungsanordnung erstellt | Zeitstempel, zu dem der Arzt die Entlassungsanordnung unterzeichnet. Damit beginnt die Phase der Entlassungsplanung. | ||
| Warum das wichtig ist Dient als Ausgangspunkt für die Messung der 'Vorlaufzeit der Entlassungsplanung'. Die Zeit bis zur tatsächlichen Entlassung zeigt betriebliche Ineffizienzen auf. Woher beziehen MEDITECH-OE (Order Entry). Aufträge nach Category = Discharge filtern. Erfassung Wird erfasst, 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. Wird üblicherweise durch Scannen eines Barcodes am Patientenbett dokumentiert. | ||
| Warum das wichtig ist Unterstützt die Analyse der 'Einhaltung von Vorgaben zur Medikamentenverabreichung'. Macht Sicherheitsrisiken und Unterbrechungen im Workflow auf den Pflegestationen sichtbar. Woher beziehen MEDITECH-PHA (Pharmacy) oder eMAR (Electronic Medication Administration Record). Das Feld 'AdminDateTime' im Verabreichungsverlauf. Erfassung Wird erfasst, wenn die Transaktion Med Admin ausgeführt wird Ereignistyp explicit | |||
| Patient entlassen | Der Besuch wird administrativ abgeschlossen. Der Patient hat die Einrichtung verlassen und das Bett wird wieder verfügbar. | ||
| Warum das wichtig ist Formeller Abschluss des Prozesses. Dient zur Berechnung der endgültigen Verweildauer und zur Festlegung des Zeitraums für Wiederaufnahmen innerhalb von 30 Tagen. Woher beziehen MEDITECH-ADM (Admissions). Das Feld 'DischargeDateTime' im Besuchsdatensatz. Erfassung Wird erfasst, wenn die Transaktion Discharge Patient ausgeführt wird Ereignistyp explicit | |||
| Patient registriert | Dieses Ereignis kennzeichnet die administrative Anlage des Patientenfalls oder Besuchs im System. Es erfasst den ersten Eintrag im MEDITECH-ADM-Modul (Admissions). | ||
| Warum das wichtig ist Legt den Beginn des Behandlungsverlaufs fest und dient als Grundlage für die Berechnung der Zykluszeit. Unverzichtbar für die Berechnung der gesamten Verweildauer. Woher beziehen MEDITECH-ADM-Modul. Quelle ist die Tabelle 'Admissions', insbesondere das Feld 'AdmitDateTime' oder der Erstellungszeitstempel des Transaktionsprotokolls. Erfassung Wird erfasst, wenn die Transaktion New Visit ausgeführt wird Ereignistyp explicit | |||
| Patient verlegt | Kennzeichnet die tatsächliche Verlegung eines Patienten von einem Standort (Station/Zimmer/Bett) zu einem anderen. Erfasst den Weg durch das Krankenhaus. | ||
| Warum das wichtig ist Wichtig für die Analyse interner Verlegungsengpässe. Lange Verlegungszeiten weisen auf konkurrierenden Ressourcenbedarf oder Verzögerungen beim Patiententransport hin. Woher beziehen MEDITECH-ADM (Admissions). Erfasst aus den Transaktionsprotokollen 'Location History' oder 'RoomBed'. Erfassung Wird erfasst, wenn die Transaktion Transfer Patient ausgeführt wird Ereignistyp explicit | |||
| Triage abgeschlossen | Kennzeichnet den Abschluss der ersten pflegerischen Untersuchung in der Notaufnahme. Dabei werden die Dringlichkeitsstufe und der Schweregrad des Patienten festgelegt. | ||
| Warum das wichtig ist Wichtig für das Dashboard zur Analyse der Abläufe in der Notaufnahme, das Durchsatz und Wartezeiten misst. Woher beziehen MEDITECH-EDM-Modul (Emergency Department Management). Abgeleitet aus Statusänderungen im EDM-Tracker oder dem Zeitstempel des Dokuments zur Triage-Untersuchung. Erfassung Wird erfasst, wenn sich das Statusfeld in Triaged ändert Ereignistyp explicit | |||
| Konsultation abgeschlossen | Abschluss der fachärztlichen Untersuchung. Wird häufig anhand der Ablage eines bestimmten Dokumenttyps ermittelt, zum Beispiel einer 'Cardiology Consult Note'. | ||
| Warum das wichtig ist Endpunkt für die Messung der Reaktionszeit von Fachärzten. Wichtig für einen zeitgerechten Behandlungsverlauf. Woher beziehen MEDITECH-PCM (Provider Order Management) oder EMR. Wird anhand der Erstellungszeitstempel von Dokumenten mit bestimmten Titeln ermittelt. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred | |||
| Konsultation angefordert | Ein spezieller Auftrag, mit dem die Einschätzung eines Facharztes angefordert wird. Damit beginnt die Zeitmessung für das Dashboard 'Reaktionszeit bei Facharztkonsultationen'. | ||
| Warum das wichtig ist Macht Engpässe bei der interdisziplinären Versorgungskoordination sichtbar. Lange Wartezeiten verlängern hier die Verweildauer. Woher beziehen MEDITECH-OE (Order Entry). Wird ermittelt, indem 'OeOrders' nach Category = Consult gefiltert wird. Erfassung Wird erfasst, wenn die Transaktion Order Enter ausgeführt wird Ereignistyp explicit | |||
| Nachsorgetermin vereinbart | Ein zukünftiger Termin für den Patienten wird vereinbart. Diese Aktivität unterstützt die kontinuierliche Versorgung nach der Entlassung. | ||
| Warum das wichtig ist Unterstützt die Analyse der 'Vereinbarung von Nachsorgeterminen'. Steht mit niedrigeren Wiederaufnahmeraten in Zusammenhang. Woher beziehen MEDITECH-SCH (Scheduling). Wird ermittelt, indem ein neuer, kurz vor dem Entlassungsdatum erstellter Appointment-Datensatz mit der Patienten-ID verknüpft wird. Erfassung Durch Vergleich der Felder Appointment Created Date und Discharge Date ermitteln Ereignistyp inferred | |||
| Probe entnommen | Kennzeichnet die Entnahme einer biologischen Probe zur Laboranalyse. Diese Aktivität liegt zwischen der Anforderung und der Verarbeitung. | ||
| Warum das wichtig ist Ein detaillierter Prozessschritt, der häufig zu Verzögerungen im diagnostischen Ablauf führt. Hilft dabei, Verzögerungen in der Pflege von Verzögerungen im Labor zu unterscheiden. Woher beziehen MEDITECH-LAB-Modul. Wird in der Regel erfasst, wenn ein Mitarbeiter der Blutentnahme den Barcode scannt oder den Probenstatus auf Collected setzt. Erfassung Wird erfasst, wenn die Transaktion Collect Specimen ausgeführt wird Ereignistyp explicit | |||
| Versorgungsplan begonnen | Kennzeichnet die Erstellung oder Zuweisung eines bestimmten Pflegeplans oder interdisziplinären Versorgungsplans. Entspricht dem Konzept 'Behandlungsplan erstellt'. | ||
| Warum das wichtig ist Misst die 'Geschwindigkeit der Behandlungsplanerstellung'. Verzögerungen an dieser Stelle können auf Lücken bei klinischen Entscheidungen hindeuten. Woher beziehen MEDITECH-PCS (Patient Care System) oder Care Manager. Zeitstempel, zu dem ein standardisierter Versorgungsplan für den Patienten aktiviert wird. Erfassung Wird erfasst, wenn die Transaktion Care Plan Add ausgeführt wird Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
Ermitteln Sie den Data-Repository-Server: Suchen Sie die Microsoft-SQL-Server-Instanz, auf der Ihr MEDITECH Data Repository (DR) gehostet wird. Dabei handelt es sich nicht um die transaktionale M-AT- oder dateibasierte Datenbank. Sie benötigen Anmeldedaten mit Lesezugriff, in der Regel für ein Dienstkonto.
Ermitteln Sie die Schemaversion: Die Strukturen des MEDITECH DR unterscheiden sich geringfügig zwischen Magic, Client/Server (6.x) und Expanse. Die folgende Abfrage verwendet gängige Namenskonventionen, zum Beispiel AdmVisits und OeOrders. Prüfen Sie die Tabellennamen im Objekt-Explorer Ihrer lokalen SQL Server Management Studio-Instanz (SSMS).
Legen Sie den Umfang fest: Ermitteln 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 Ausgangspunkt für den Patientenfall.
Bereiten Sie die SQL-Umgebung vor: Öffnen Sie SSMS und stellen Sie eine Verbindung zum DR her. Öffnen Sie ein neues Abfragefenster und vergewissern Sie sich, dass die richtige Datenbank ausgewählt ist, häufig livedb oder ein ähnlich benannter Datenbankname.
Konfigurieren Sie die Parameter: Ersetzen Sie im bereitgestellten SQL-Skript die Platzhalter für den Datumsbereich, zum Beispiel „2023-01-01“, sowie gegebenenfalls die Einrichtungskennungen, wenn Ihr DR mehrere Standorte umfasst.
Führen Sie die Extraktion aus: Starten Sie das vollständige T-SQL-Skript. Es verwendet Common Table Expressions (CTEs), um zunächst die relevante Patientengruppe festzulegen und anschließend mehrere Datenquellen mit UNION ALL zu einem standardisierten Event Log zusammenzuführen.
Behandeln Sie NULL-Attribute: Die Abfrage berücksichtigt mögliche NULL-Werte in Zeitstempeln, indem sie bei Bedarf COALESCE verwendet. Außerdem stellt sie sicher, dass wichtige Verknüpfungsschlüssel wie SourceID und VisitID vorhanden sind.
Prüfen Sie Triage- und Notfalldaten: MEDITECH speichert Daten aus der Notaufnahme in bestimmten Modulen. Wenn Sie Notaufnahme-Workflows analysieren, prüfen Sie, ob die Tabellen EdVisits oder NurInterventions Daten enthalten.
Prüfen Sie die Bestellkategorien: Die Abfrage unterscheidet allgemeine Bestellungen, Konsile und Entlassungsanordnungen anhand von Kategorie-URNs oder Mnemonics. Passen Sie gegebenenfalls die WHERE-Klauseln an das Mnemonic-Verzeichnis Ihrer Einrichtung an.
Exportieren Sie die Daten: Sobald die Ergebnisse angezeigt werden, klicken Sie im SSMS-Ergebnisraster mit der rechten Maustaste und wählen Sie „Save Results As CSV“. Achten Sie darauf, dass die Spaltenüberschriften enthalten sind.
Prüfen Sie das Format: Öffnen Sie die CSV-Datei und kontrollieren Sie vor dem Import, ob die Datumsangaben dem ISO-8601-Format YYYY-MM-DD HH:MM:SS entsprechen.
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 Prozessverläufe erfasst werden.
- Filterung nach Einrichtung: Wenn das DR Daten mehrerer Einrichtungen enthält, filtern Sie die BaseVisits-CTE nach FacilityID oder SourceSystemID.
- Definition des Patientenfalls: Das Skript verwendet die eindeutige VisitID, häufig als Account Number oder Episode Number bezeichnet, als Case-ID.
- Leistung: Die Abfrage verwendet eine CTE als Ausgangspunkt, um den Scanbereich einzugrenzen. Für eine optimale Leistung sollten in der Tabelle AdmVisits Indizes für AdmitDate und DischargeDate vorhanden sein.
- Datenverzögerung: Je nach Standortkonfiguration kann die Übertragung aus dem Data Repository 15 Minuten bis 24 Stunden dauern. Prüfen Sie den Zeitstempel LastDataUpdate.
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'); Möchten Sie beginnen?
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, die Datenextraktion so anzupassen, dass Ihr Krankenhaus effizienter arbeiten kann.
Optimieren Sie jetzt den Behandlungsverlauf Ihrer Patienten und verkürzen Sie Verzögerungen
Verkürzen Sie die Durchlaufzeiten um 30 Prozent und steigern Sie die Effizienz Ihres Krankenhauses
Keine Kreditkarte erforderlich. In wenigen Minuten startklar.