MII-Initiative

Medizininformatik Initiative - Modul Fall - ImplementationGuide

Beschreibung Modul FALL


Einleitung

Im Modul FALL des MII KDS benutzen wir den Begriff Fall nur als ungenauen Oberbegriff und folgen darin dem Leitfaden Basis DE (R4), dem ImplementationGuide der Deutschen FHIR Basisprofile des HL7 Deutschland e.V. Dort wird die differenzierte Verwendung der FHIR Begriffe EpisodeOfCare, Encounter und Account vorgeschlagen:

Der Begriff "Fall" gruppiert im Sprachgebrauch verschiedene Konzepte, die in FHIR durch unterschiedliche Ressourcen repräsentiert werden:

  1. Aufenthalt/Besuch: Der stationäre Aufenthalt oder ambulante Besuch eines Patienten in einer Einrichtung wird in FHIR durch die Ressource Encounter abgebildet.

  2. Abrechnungsfall: Der Fall im Sinne einer Gruppierung von medizinischen Leistungen, die in einem gemeinsamen Kontext abgerechnet werden, sind in FHIR durch die Ressource Account repräsentiert. Ein Abrechnungsfall kann mehrere Encounter umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationärer Besuch).

  3. Medizinischer Fall: Der medizinische Fall gruppiert Informationen, die im Kontext einer gemeinsamen (Dauer-)Diagnose stehen und wird in FHIR durch die EpisodeOfCare dargestellt.

Im Mittelpunkt des vorliegenden IG stehen die Aufenthalte und Besuche von Patient*innen bei Gesundheitseinrichtungen. Aufenthalte und Besuche werden nachfolgend unter dem Begriff Kontakt zusammengefasst und durch verschiedene Beiworte differenziert.

Anders als es die schlanke Zuweisung der FHIR-Ressource Encounter zu stationären Aufenthalt und ambulanten Besuchen suggeriert, kann die Darstellung der Versorgung in Gesundheitseinrichtungen in einem Modul FALL beinahe beliebig komplex gestaltet werden.

Zum einen ist zu berücksichtigen, dass Patienten bei einem „stationären Aufenthalt“ in einem Krankenhaus auf eine komplexe hierarchische Organisation treffen. Der Behandlungsvertrag wird mit der Einrichtung (obere Hierarchieebene) geschlossen. Zahlreiche Pflichten und Rechte werden an die medizinischen Fachabteilungen (mittlere Hierarchieebene) delegiert – zum Teil durch die Einrichtungen, zum Teil qua Gesetz (z.B. strukturelle und prozedurale Qualitätsanforderungen, teilweise Eigenforschungsprivilegien). Die eigentliche Versorgung aber findet durch die handelnden Personen in den Versorgungsstellen (untere Hierarchieebene) statt. Im ambulanten Sektor, der im Wesentlichen durch Arztpraxen und die „ambulanten Besuche“ der Patient*innen darin repräsentiert wird, sind die Strukturen und Prozesse in der Regel weniger komplex. Das hilft aber bei der Modellierung wenig, da der stationäre und der ambulante Sektor gemeinsam im Modell der Medizininformatik-Initative abgebildet werden soll.

Zum anderen soll die Modellierung und FHIR-Profilierung des Moduls FALL eine Reihe verschiedener Anwendungsszenarien in der Versorgung und der Forschung unterstützen, bei denen es um die Zuordnung von Rechten und Pflichten (z.B. Zugriff auf Patientendaten und Eigenforschungsprivilegien), um Kontakte zum Personal (z.B. Hygienemaßnahmen und Infektionsnachverfolgung), um aktuelle Aufenthaltsorte (z.B. Zusendung von Medikamenten und Material), um historische Aufenthaltsorte (z.B. Analyse von Infektionsketten) oder um innerbetriebliche Kosten- und Leistungsrechnung gehen kann.

Zu beachten ist, dass es bei den Referenzprojekten International Patient Summary (IPS) und Medizinische Informationsobjekte der Kassenärztlichen Bundesvereinigung (MIO, KBV) kein Modul FALL gibt, weil die Anwendungsziele anders sind. Daher kann beim Modul FALL nicht auf Vergleichsmodelle und Vergleichsprofile zurückgegriffen werden.

Umgekehrt wird auch in der Medizininformatik-Initiative nicht in jedem Anwendungsfall das vollständige Spektrum der Kontaktdetails benötigt. Es gibt auch in der MII Konstellationen, in denen nur einfaches Modell FALL (z.B. zur Ermittlung der Qualitätssicherungsverantwortung oder der Eigenforschungsprivilegien) benötigt wird oder die Datenlage nur ein einfaches Modul FALL erlaubt (z.B. Generierung aus dem Datensatz gemäß § 21 KHEntgG). Daher unterscheidet der vorliegende IG zwischen zwei Modellentwicklungsphasen:

Im ersten Kapitel des vorliegenden IG wird nur das einfache Aufbaumodell und seine Verwandtschaft mit den Tabellen FALL und FAB des Datensatzes gemäß § 21 KHEntgG beschrieben. Das komplexe Ausbaumodell des Moduls FALL erfordert, dass zunächst ein Strukturmodell für die Einrichtungen erarbeitet wird. Daher wird es im vorliegenden IG erstmal nur skizziert.

Gemeinsam ist dem vorgestellten einfachen Aufbaumodell und dem skizzierten komplexen Ausbaumodell die vorläufig dreistufige Hierarchie mit der Unterscheidung der Organisationseinheiten Einrichtung, Abteilung und Versorgungsstelle in der Darstellung der Organisationsstrukturen und der komplementären Kontakttypen Einrichtungskontakt, Abteilungskontakt und Versorgungsstellenkontakt in der Darstellung des Rückgrates der Versorgungsprozesse.

Bereits das rudimentäre Aufbaumodell erlaubt in Ansätzen die Ergänzung der Angabe von Versorgungsorten. Sinnvoll ist die Lokalisierung der Versorgung aber erst im komplexen Ausbaumodell, in dem auch die Organisationseinheiten wie OP-Dienst, Poliklinik-Dienst, Ambulanzdienst, Röntgenstelle usw. mit den entsprechenden Orten in das Modell aufgenommen werden. Daher findet sich auch die Ergänzung der Angaben zum Versorgungsort erst im Schlusskapitel des vorliegenden IG.

Das MII-KDS-Modul FALL wird vervollständigt durch die Relationen zu anderen Basismodulen wie Diagnose und Prozedur, und zu Erweiterungsmodulen wie dem Modul Strukturdaten, welches die Organisationseinheit und den Versorgungsort der Patienten modelliert. Weitere Informationen hierzu sind im Abschnit Kontext im Gesamtprojekt / Bezüge zu anderen Modulen zu finden.

Eine weitere zentrale Entität des MII-KDS-Moduls Fall ist der Account, das "Konto" des Abrechnungsfalls. Dieser wird jedoch erst im komplexen Ausbaumodell berücksichtigt.


Zielsetzung

Aufgabe des Moduls Fall ist die use-case-orientierte Abbildung der Kontakte (Aufenthalte und Besuche) zwischen Patienten und Einrichtungen mit den Hauptfragen „wer“, „wann“, „bei wem“.

In den Referenzprojekten International Patient Summary (IPS) und Medizinische Informationsobjekte (MIO) haben die Beteiligten für ihre Anwendungsszenarien diese Fragen nicht gestellt und daher auf ein Modul Fall verzichtet. Und auch in der Medizininformatik-Initiative spielt die Nachverfolgung der Kontakte oft keine Rolle, gelegentlich ist es notwendig, die verantwortliche Fachabteilung mit Rechten und Pflichten zu kennen, und nur in einem Anwendungsfall, dem Use Case Infection Control des Konsortiums HiGHmed ist es notwendig, die vollständige Kontaktgeschichte der Behandelten nachzuvollziehen.

Bei Trennung von einfachem Aufbaumodell und komplexem Ausbaumodell kann sich das einfache Modell auf die Kontakte zu den Fachabteilungen konzentrieren. Beispiele für den Bedarf sind in einigen Bundesländern die Zuordnung der Eigenforschungsprivilegien und allgemein das Interesse an Fachabteilungsbezogenen Diagnosestatistiken und ähnlichem.

Bei der Gestaltung der einfachen Aufbauvariante des Moduls Fall, erfolgt eine Orientierung an den Tabellen FALL und FAB des Datensatzes gemäß § 21 KHEntgG, damit aus diesen Datensätzen eine Übergangslösung generiert werden kann.