als PDF-Dokument - Informationssysteme

Serviceflow-basierte Modellierung klinischer
Abteilungsinformationssysteme am Beispiel der
Kardiologie
Der privaten
Universität für Gesundheitswissenschaften, Medizinische Informatik und Technik
vorgelegte
Dissertation
zur Erlangung des akademischen Grades eines
Doktor scientiarum informaticarum biomedicinarum
(Dr.sc.inf.biomed.)
von
Marcel Claus
31. Oktober 2005
Betreuer:
1. Gutachter:
2. Gutachter:
Univ.-Prof. Dr. H.-J. Appelrath
Univ.-Prof. Dr. H. Schuldt
Univ.-Prof. Dr. R. Haux
Zusammenfassung
Zusammenfassung
Die steigende Zahl stetig komplexer werdender diagnostischer und therapeutischer
Verfahren in der Medizin schraubt die Kostenspirale in der Gesundheitsversorgung seit
langem höher. Dies zeigt sich nicht nur in ständig steigenden Beiträgen der Krankenkassen,
sondern auch im Kostendruck auf die Einrichtungen des Gesundheitswesens. Neben
diesem finanziellen Druck wird das medizinische Personal zusätzlich durch administrative
Aufgaben wie Dokumentationspflicht, Qualitätssicherung und Verschlüsselung von
Leistungen für Abrechnung oder Statistiken belastet. Automatisierung von Routineprozessen
und Unterstützung administrativer Aufgaben durch IT-Systeme sollen das medizinische
Personal entlasten, Kosten sparen und die Behandlung des Patienten verbessern.
Gegenstand dieser Arbeit ist die Entwicklung eines möglichst generischen Modells zur
Abbildung medizinischer Fachabteilungen und einer Strategie zu dessen Implementierung
im Sinne einer in der klinischen Praxis einsetzbaren Software. Dabei bildet der in der
Industrie gängige Ansatz der Modellierung betrieblicher Abläufe als Workflows eine
geeignete, aber weiter zu entwickelnde Basis. Eine klinische Abteilung wird im vorgestellten
Ansatz unter Verwendung eines speziell auf medizinische Belange angepassten
Serviceflows abgebildet. Hierbei wird die Dienstleistung am Kunden bzw. Patienten in den
Mittelpunkt gerückt. Alle leistungserbringenden Abteilungen werden zunächst als
eigenständig operierende Einheiten, den sog. Servicepoints, definiert. Diese besitzen
Fähigkeiten in Form angebotener medizinischer Leistungen, die um Vorbedingungen
(Indikationen) erweitert werden und die für die Behandlung notwendigen Voraussetzungen
bilden. Für die Dokumentation der innerhalb des Serviceflows erbrachten Leistungen wird
ein sog. Servicefloat erstellt, welches funktional einer erweiterten digitalen Krankenakte
entspricht. Hier wird festgehalten, was durchgeführt wurde, geplant ist und wie der aktuelle
Status des Patienten ist. Jeder Servicepoint besitzt Modifikatoren zur Aktualisierung des
Servicefloats, was in der Praxis der medizinischen Dokumentation entspricht. Dadurch kann
sich der verantwortliche Arzt jederzeit ein Bild der aktuellen Behandlungssituation machen,
die nächsten Schritte in der Behandlungskette planen und veranlassen.
Durch diesen Ansatz wird eine hohe Flexibilität erreicht, da keine starren Arbeitsabläufe
existieren. Jederzeit kann abhängig vom Status - also dem Krankheitsbild des Patienten auf unvorhergesehene Ereignisse wie z. B. Notfälle reagiert werden. Weiterhin ist eine
einfache und übersichtliche Modellierung durch das "Herunterbrechen" von gesamten
Abteilungen auf kleine autonom arbeitende Einheiten möglich. Dieser Ansatz wird
konzeptionell beschrieben und anhand einer bereits erfolgreich in mehreren Kardiologien
verschiedener Kliniken implementierten Lösung bzgl. seiner praktischen Relevanz
demonstriert.
i
Abstract
Abstract
For a long time, the ever increasing numbers of diagnostic and therapeutic practices in and
approaches to medicine have resulted in spiralling costs within the German health system.
These are leading to higher insurance contributions for patients as well as to mounting
pressures of cost for the health service. Apart from financial pressures, medical personnel
have to take on more and more administrative tasks, such as responsibility for
documentation, quality assurance and the encoding of medical procedures for purposes of
accounting and/or statistical data collection. Computer assisted automation of routine
processes and support for administrative tasks can relieve medical personnel, cut cost, and
improve their primary task – the treatment of patients.
This thesis aims to develop a generic model for medical departments, as well as a software
architecture that allows software-engineers to implement it. Serving as point of departure,
the generally accepted and established Workflow-Management-Model (WfM) will be
expanded and remodelled leading to the introduction of a so-called "Medical Service Flow"
(i. e. a WfM specially designed for the medical profession). Central to this are the
customer/patient and his/her needs for medical treatment. All clinical departments will be
defined as so-called "Service Points", i. e. small, independent, and discrete units catering for
the medical needs and clinical picture of each individual patient to be operated on. For the
purpose of documenting the services rendered within the Serviceflow a so-called
Servicefloat will be produced, functioning as an extended digital medical record. It keeps
track of the treatment received by the patient, treatment planned, as well as his/her past and
current state of health. Corresponding to medical documentation, the Servicefloat can be
updated at each Service Point, enabling the medical practitioner in charge to be fully
informed at all times about the current state of the patient, plan, and carry out the necessary
steps for the successful completion of the treatment.
The model presented is highly flexible as there are no rigid work procedures. It is possible at
all times to react to the patient's current clinical picture and to unforeseen circumstances
(such as an emergency). There are no static workflows or predefined diagrammatic plans
restricting the doctor in his decisions about the best strategy for treating individual patients.
Furthermore, the use of small, self-contained units modeling the medical departments
enables even practitioners not versed in the use of computers, to design a model
representing a more complex clinical structure. To conclude, the study will introduce a
software-architecture based on the "Medical Serviceflow"-model together with an account of
the experiences gained from the practical use of a working prototype. The latter is based on
the software-architecture introduced in this study and has been installed successfully in a
clinical production environment of a large cardiology department.
ii
Inhaltsverzeichnis
Inhaltsverzeichnis
1
1.1
1.2
1.3
Einleitung............................................................................................................ 1
Besonderheiten medizinischer Arbeitsplätze ....................................................... 4
Zielsetzung .......................................................................................................... 6
Aufbau der Arbeit ................................................................................................ 9
2.1
2.2
2.3
2.4
2.5
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.7
Grundlagen ....................................................................................................... 11
Grundlegende Begriffsdefinitionen..................................................................... 11
Entwicklung medizinischer Abteilungsinformationssysteme............................... 13
Modellierung...................................................................................................... 16
Workflow-Management-Systeme....................................................................... 19
Serviceflow........................................................................................................ 25
Standards in der medizinischen Informatik ........................................................ 29
DICOM .......................................................................................................... 30
HL7................................................................................................................ 34
XDT ............................................................................................................... 37
IHE ................................................................................................................ 39
Kardiologische Abteilungsinformationssysteme in Deutschland......................... 41
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.4
3.5
Die klinische kardiologische Fachabteilung................................................... 45
Einbettung in die Klinik ...................................................................................... 46
Die moderne Kardiologie ................................................................................... 51
Die wichtigsten kardiologischen Krankheitsbilder........................................... 53
Kardiologische Ressourcen ........................................................................... 61
Die wichtigsten diagnostischen Verfahren in der Kardiologie ......................... 67
Die wichtigsten therapeutischen Verfahren in der Kardiologie ....................... 81
Die kardiologische Behandlungskette................................................................ 88
Aktueller Stand kardiologischer Leistungen in Deutschland............................... 90
Zusammenfassung ............................................................................................ 92
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Serviceflows zur Modellierung klinischer Behandlungs-ketten.................... 97
Übersicht der Definitionen des medizinischen Serviceflows............................... 98
Dreiphasige Struktur von Behandlungsabläufen .............................................. 102
Die DMM im klinischen Kontext ....................................................................... 108
Die strukturierte Krankenakte .......................................................................... 115
Die NLO im klinischen Kontext ........................................................................ 122
Der medizinische Service Point ....................................................................... 127
Der MSP im klinischen Kontext ....................................................................... 133
Der Standardisierte Medizinische Serviceflow ................................................. 140
Darstellung des MSF als endlicher Automat .................................................... 142
Beispiel für einen MSF .................................................................................... 148
2
3
4
iii
Inhaltsverzeichnis
5
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.4
5.5
5.6
5.6.1
5.6.2
Eine Software-Architektur zur Implementierung kardiologischer
Abteilungsinformationssysteme.................................................................... 157
Architektur ....................................................................................................... 158
Das Datenschema ........................................................................................... 162
Die Komponentenarchitektur............................................................................ 165
Steuerkomponenten..................................................................................... 171
Document-View-basierte GUI-Komponenten ............................................... 174
Property-basierte GUI-Komponenten ........................................................... 178
Hintergrundkomponenten............................................................................. 184
Umsetzung des MSF-Konzepts ....................................................................... 185
Erweiterungsmöglichkeiten .............................................................................. 189
GO# - Eine Implementierung des MSF-Modells ............................................... 193
Betrachtung von GO# aus Sicht der Anwendungsentwickler........................ 193
Betrachtung von GO# aus Sicht der Anwender............................................ 194
6.1
6.2
Zusammenfassung und Ausblick .................................................................. 199
Zusammenfassung .......................................................................................... 199
Ausblick ........................................................................................................... 201
6
Anhang A:
Literaturnachweis.................................................................................... 203
Anhang B:
Abkürzungen und Glossar...................................................................... 213
Anhang C:
Definitionen zum MSF-Beispiel aus Kapitel 4........................................ 219
Anhang D:
Definitionen zum PS aus Kapitel 5 ......................................................... 230
Anhang E:
Definitionen zu OSCD aus Kapitel 5....................................................... 234
Anhang F:
Fragebogen zur Bewertung von GO# .................................................... 239
Anhang G:
Abbildungsverzeichnis ........................................................................... 241
Anhang H:
Tabellenverzeichnis ................................................................................ 243
iv
Einleitung
1 Einleitung
Die steigende Zahl stetig komplexer werdender diagnostischer und therapeutischer
Verfahren in der Medizin schraubt die Kostenspirale vor allem in Deutschland immer höher.
Dies zeigt sich nicht nur in gestiegenen Beiträgen der Krankenkassen, sondern auch beim
Kostendruck auf die Einrichtungen des Gesundheitswesens. Neben diesem finanziellen
Druck seitens der Gesundheitsträger wird das medizinische Personal zusätzlich durch
administrative Aufgaben wie Dokumentationspflicht, Qualitätssicherung und Verschlüsselung von Leistungen für Abrechnung oder Statistiken belastet.
Nach [Neu05] vervielfachten sich die Leistungsausgaben der gesetzlichen Krankenkassen
von 1970 bis 2004 um 975%. Im selben Zeitraum wuchs das Bruttoinlandsprodukt jedoch
nur um 527%. Der größte Teil der Kosten entfällt mit 35,3 % der Gesamtausgaben im
Gesundheitswesen auf Behandlungen durch Krankenhäuser.
Für die leistungserbringenden medizinischen Institutionen in Deutschland bedeutet dies
häufig, dass sie ihre Effizienz steigern, Fusionen eingehen oder sogar schließen müssen.
Dies gilt insbesondere für kleinere Krankenhäuser und niedergelassene Fachärzte, die eine
teure Spezialausstattung benötigen. So sank nach Angaben des Statistischen Bundesamtes
([SBD05]) die Zahl der Krankenhäuser von 2.411 im Jahr 1991 um 8,88 % auf 2.197 im Jahr
2003. Die Zahl der Krankenhausbetten verringerte sich im selben Zeitraum sogar um 18,6 %
von 665.565 auf 541.901. Dies liegt an Verkleinerungen der Krankenhäuser durch
Outsourcing sowie Schließungen und Zusammenlegungen von Abteilungen. Dabei sind auf
Grund der Bevölkerungsentwicklung Institutionen in den neuen Bundesländern stärker von
Kürzungen betroffen als solche in den alten Bundesländern.
Entgegen dieser Verknappung medizinischer Ressourcen wächst die Anzahl der
Bevölkerungsgruppen, die auf eine medizinische Versorgung angewiesen sind. Dies betrifft
meist chronisch Kranke oder ältere Menschen. So stieg nach [SBD04b] im Zeitraum von
1991 die Zahl der über 65jährigen in Deutschland von 13,7 % der Gesamtbevölkerung auf
18,0 % im Jahr 2003. Die Kosten für die Behandlung von Patienten steigen mit
zunehmendem Alter stark an (vgl. [SBD04a]). Dies gilt insbesondere für Herz-/KreislaufErkrankungen, welche mit Abstand die höchsten Kosten pro Patient und Jahr verursachen
(vgl. [SBD04a]).
Daraus resultiert eine stetig steigende Zahl von Krankenhauseinweisungen (vgl. Tab. 1.1
"Stationäre Fälle"), die wiederum zu einer Mehrbelastung der Ärzte im Krankenhaus führt
(vgl. [Clad1] und [MARB]). Dies belegen auch die absoluten Zahlen des Statistischen
Bundesamtes. Wie in Tab. 1.1 dargestellt ist bei nur leicht rückgängiger Auslastung der
1
Einleitung
Krankenhäuser die Zahl der Pflegetage stark rückläufig, obwohl mehr stationäre
Behandlungsfälle anfallen. Dies kann nur erzielt werden, indem die durchschnittliche
Verweildauer sinkt.
Jahr
Pflegetage
Durchschnittliche
Verweildauer
Stationäre
Fälle
Aufgestellte
Betten
Nutzungsgrad
der Betten
1998
171,8 Mio.
10,2 Tage
16,8 Mio.
571.629
82,4%
1999
169,7 Mio.
9,9 Tage
17,1 Mio.
565.268
82,2%
2000
167,8 Mio.
9,7 Tage
17,2 Mio.
559.651
81,9%
2001
163,5 Mio.
9,4 Tage
17,3 Mio.
552.680
81,1%
2002
159,9 Mio.
9,2 Tage
17,4 Mio.
547.284
80,1%
2003
153,5 Mio.
8,9 Tage
17,3 Mio.
541.901
77,6%
Tab. 1.1:
Entwicklung der Pflegetage und Stationären Fälle in Deutschland im Zeitraum 1998 bis
2000. Bei konstantem Nutzungsgrad, steigender Fallzahl und sinkenden Pflegetagen
muss die durchschnittliche Verweildauer gekürzt werden. Quelle [SBD05]
Dies führt in den Krankenhäusern zu weniger Zeit, die für den Patienten zur Verfügung
steht, nicht nur weil grundsätzlich die Verweildauer sinkt, sondern auch, weil jeder Fall
neben der grundsätzlichen medizinischen Leistung einen zusätzlichen, in der Regel deutlich
gestiegenen, administrativen Aufwand erfordert. Hier fallen zeitintensive Tätigkeiten wie
Erstellen von Verlegungs- und Entlassungsbriefen, Verschlüsseln von Leistungen oder
Dokumentation des Behandlungsverlaufs an. Dies wird meist von Assistenzärzten manuell
ohne geeignete "Unterstützungswerkzeuge", d. h. ohne anwendungs- oder fachspezifische
Software, durchgeführt, was zu erhöhtem Stress und weniger Zufriedenheit an der
durchgeführten Tätigkeit führt.
Dieser Trend ist schon seit längerem im Gesundheitswesen abzusehen. So wurde z. B.
schon 1998 auf dem 101. Ärztetag auf die stetig steigende Belastung des medizinischen
Personals und den für Ärzte zunehmend unattraktiven Arbeitsplatz in der Klinik hingewiesen
(siehe [Jon98]).
Ein Ärztemangel in den Krankenhäusern wird auch weiterhin, insbesondere mit Blick auf
EU-konforme Arbeitszeitregelungen des Bereitschaftsdienstes, befürchtet ([Fli01], [Cla01]).
Nachdem am 03.10.2000 der EuGH (Europäische Gerichtshof) nach der EG-Richtlinie
93/104 einem spanischen Arzt Recht gab, dass der Bereitschaftsdienst zu 100% als
Arbeitszeit angerechnet werden muss, wird erwartet, dass dies auch in deutsches Recht
umgesetzt wird. Dies bedeutet nach Ansicht des Marburger Bundes, dass ca. 15.000
Arztstellen neu geschaffen werden müssen, was zu voraussichtlichen Mehrausgaben für
den Krankenhaussektor in Höhe von bis zu 1 Milliarde € führt. Angesichts der angespannten
Finanzlage würde dies entweder zu einer Beitragserhöhung der Krankenkassen oder zu
weiteren Kürzungen im Gesundheitswesen führen.
2
Einleitung
So drohte Anfang 2002 mit Slogans wie "Medizinische Dokumentation: ja, Fallpauschalen
codieren und Abrechnungsbelege ausfüllen: nein." und "Runter von der 80 Std. Woche –
den Patienten zuliebe" der Marburger Bund mit einem "Computerstreik" ([Kor02]). Die
Forderung der Ärzte nach Konzentration auf das medizinische "Kerngeschäft" wird auf jeden
Fall immer deutlicher erhoben.
Durch den effizienteren Einsatz von Informationssystemen bei der Behandlung von
Patienten kann auch der in Deutschland gegenüber anderen westlichen Ländern
unterentwickelte und seit langem bemängelte Informationsaustausch zwischen
medizinischen Einrichtungen verbessert werden (vgl. [Neu05]). Dadurch kann mehr
Transparenz für Ärzte und Patienten geschaffen, Doppeluntersuchungen vermieden und die
Nicht-Verfügbarkeit medizinischer Dokumente reduziert werden.
Eine Verbesserung kann zukünftig nach Einschätzung von Experten (vgl. [HAHK04]) durch
weitere Rationalisierung und die Bereitstellung effizienter Methoden zur Dokumentation,
Leistungserfassung und Ressourcenplanung in Krankenhäusern erreicht werden. Hier bietet
sich der Einsatz von IT-Systemen an, die aber den besonderen Umständen der klinischen
Arbeitsplätze angepasst sein müssen, um eine tatsächliche Entlastung zu schaffen.
Die vorliegende Arbeit soll hierzu einen Beitrag leisten, indem
•
die besonderen Anforderungen und Probleme an klinischen Arbeitsplätzen am
Beispiel einer kardiologischen Abteilung systematisch ermittelt und dann
generalisiert modelliert werden sowie
•
innovative Methoden und Systemarchitekturen der Informatik aufgegriffen und
anwendungsbezogen weiterentwickelt werden,
um die geschilderten Anforderungen zu erfüllen.
Hierfür werden häufig zur Abbildung der "medizinischen Geschäftslogik" Ansätze aus der
Prozessmodellierung, insbesondere dem Workflow-Management, verwendet. Diese sind
jedoch nicht immer direkt von kommerziell angebotenen Systemen, die in anderen Branchen
wie der Finanzdienstleistung oder industriellen Fertigung erfolgreich sind, auf Institutionen
des Gesundheitswesens übertragbar. Daher wird hier ein Ansatz basierend auf Methoden
des so genannten Serviceflow-Managements als Erweiterung des klassischen WorkflowManagement vorgestellt, deren Mittelpunkt SPs (Servicepoint) darstellen. Diese sind kleine,
eigenständig operierende Einheiten, die die Modellierung der Besonderheiten medizinischer
Arbeitsabläufe unterstützen. Daraus wiederum kann die formale Grundlage für ein
Framework erstellt werden, das die Realisierung von praxisrelevanten Anwendungen
zulässt. Die Eignung der vorgestellten Konzepte soll am konkreten Einsatz in
kardiologischen Fachabteilungen demonstriert und validiert werden.
3
Einleitung
1.1 Besonderheiten medizinischer Arbeitsplätze
Bei der Einführung von IuK-Systemen (Informations- und Kommunikationssystemen) am
klinischen Arbeitsplatz ist es nach [RZ01] "nicht damit getan, einfach die Dokumentation
vom Papier auf den Computer zu übertragen". In der komplexen Landschaft des klinischen
Alltags müssen viele Faktoren berücksichtigt werden, die so in anderen
Anwendungsdomänen
wie
Finanzdienstleistung,
Versicherungen,
Handel
oder
Industrieproduktion nicht auftreten. Diese sind insbesondere:
4
•
Unvorhersehbare
Ereignisse:
Hierunter
fallen
insbesondere
Notfälle,
unvorhersehbare Verläufe in der Behandlung des Patienten und der ständige Druck,
dass Fehler nicht "einfach auszubessern" sind. Wird z. B. während einer
medizinischen Maßnahme versehentlich ein Organ beim Patienten verletzt, kann
dies möglicherweise nicht korrigiert werden. Zusätzlich können während eines
Eingriffes neue Diagnosen gestellt werden, die den Behandlungsablauf entscheidend
ändern. Dadurch wird der klinische Alltag stark und anders als in anderen
Anwendungsdomänen geprägt und führt zu einem für den Außenstehenden schwer
zu durchschauenden, teilweise konfus und planlos wirkenden Arbeitsablauf in einer
Klinik.
•
Hohe Individualität: Eine in der Medizin weit verbreitete Tatsache ist die hohe
Individualität der Kliniken und des dort tätigen Personals. In gleichen Abteilungen
unterschiedlicher Institutionen können verschiedene Arbeitsabläufe vorgefunden
werden. Hierfür gibt es mehrere Gründe. Die wichtigsten sind, dass unterschiedliche
Leistungen angeboten werden. So ist z. B. die Herzkatheteruntersuchung das
zentrale Verfahren, welches von jeder invasiven Kardiologie durchgeführt wird. Ein
breites Spektrum weiterer, auch etablierter Verfahren wie PTAs, EPUs,
Schrittmacherund
Defibrillatorimplationen,
Schirmchenverschlüsse
oder
Klappensprengungen werden aber in beliebigen Kombinationen angeboten oder je
nach Klinik eben auch nicht. Weiterhin ist der Arbeitsablauf geprägt durch die
Ausbildung der zuständigen Chefärzte, die in unterschiedlichen Universitätskliniken
und Ländern stattfindet und somit verschiedene Schwerpunkte und
Vorgehensweisen bei der Behandlungsstrategie setzen. Im Gegensatz zu vielen
anderen Branchen, in denen die interne Vorgehensweise durch rechtliche Vorgaben
oder innerbetriebliche Vorschriften bis ins kleinste geregelt ist, ist die medizinische
Versorgung deutlich individueller.
•
Gesetzliche Verwaltungsvorschriften: Seit 1996 müssen alle in der Klinik
erbrachten Leistungen nach unterschiedlichen Katalogen verschlüsselt werden. Dies
ist im Sozialgesetzbuch festgeschrieben. Diese Kataloge werden etwa einmal
jährlich überarbeitet und weisen gewisse Inkonsistenzen und Lücken auf (z. B. für
die Echokardiographie siehe [CK03]). Dazu kommt seit 2001 eine verpflichtende
Qualitätssicherung für die am häufigsten erbrachten medizinischen Leistungen nach
Einleitung
den Richtlinien der BQS (Bundesgeschäftsstelle Qualitätssicherung gGmbH). Die
Definition der hierfür abzuliefernden Daten wird einmal jährlich überarbeitet und kann
von einer Version zur nächsten deutlichen Änderungen unterworfen sein. Zu diesen
fest vordefinierten Richtlinien kommen noch die gesetzlich vorgeschriebene
Dokumentationspflicht für Ärzte und die einzelnen Archivierungsvorschriften für
spezielle diagnostische und therapeutische Verfahren wie z. B. §28 der RöV
(Röntgenverordnung).
•
Spezielle Standards in der Medizin: Beim Datenaustausch zwischen IuKSystemen im Gesundheitswesen und der Kommunikation mit medizinischen
Informationssystemen kommen Standards zum Einsatz, die sonst in der Informatik
nicht gebräuchlich sind. Die wichtigsten sind:
DICOM: Digital Imaging and Communications in Medicine, [NEMA99]
HL7:
Health Level Seven, [HL7]
XDT:
Oberbegriff von Datenaustauschstandards, die durch die KBV
(Kassenärztliche Bundesvereinigung, [KBV]) definiert wurden, z. B. BDT
(Behandlungsdatentransfer), ADT (Abrechnungsdatentransfer) oder LDT
(Labordatentransfer), [XDT]).
Zusätzlich müssen auch Aspekte der klassischen Informationsverarbeitung beachtet
werden, z. B.
•
Verarbeitung großer Datenmengen pro Datensatz: ein Eintrag zur Dokumentation
eines komplexen medizinischen Eingriffes kann aus mehreren tausend einzelnen
Attributen bestehen. Dabei werden zu unterschiedlichen Eingriffen unterschiedliche
Informationen erfasst, die aber bei der Gesamtsicht eines Krankenhausaufenthalts
zu einem größeren Teil relevant sein können. Dies kann zu großen Datenschemata
mit sehr vielen Attributen pro Datensatz führen
•
Strukturierte Datenerfassung mit benutzungsfreundlichen Erfassungsmasken,
manuelle, teil-automatische und automatische Datenverarbeitung und ergonomische
Visualisierung
•
Unterstützung für Empfang, Konvertierung und Archivierung von multimedialen
Daten
•
Komfortable Suchfunktionen
•
Effiziente Werkzeuge
Auswertungen.
für
sie
Erstellung
von
Reporten
und
statistischen
An der Einführung von IT-Systemen in den klinischen Alltag wird schon seit vielen Jahren in
der Praxis gearbeitet, es bleibt aber unverändert ein spezifischer Forschungsbedarf (vgl.
[AT04]) und vor allem auch ein "Umsetzungsdefizit" bei der professionellen
softwaretechnischen Realisierung von Produkten, die im klinischen Produktionsbetrieb
5
Einleitung
eingesetzt werden können. Bei administrativen Systemen für Abrechnung und Verwaltung
und elektronischen Langzeitarchiven gibt es zwar mehrere etablierte IT-Lösungen am Markt
(vgl. z. B. [Mue97]), es wird jedoch am medizinischen Arbeitsplatz, wenn überhaupt ein ITSystem zur medizinischen Dokumentation vorhanden ist, meistens eine doppelte
Dokumentation in Papierform und im PC geführt. Dies wird vom Personal zu Recht kritisiert,
da es zu einer erheblichen Mehrbelastung führt. Nach [AES03] wird beklagt, dass teilweise
bis zu 40% der Arbeitszeit für die Dokumentation verwendet wird.
1.2 Zielsetzung
Betrachtungen des aktuellen Stands klinischer Abteilungsinformationssysteme am Beispiel
der Kardiologie, weisen für den Anwender meist deutliche Defizite auf. Dies liegt daran, dass
sie nicht den anwendungsspezifischen Bedürfnissen in der Medizin angepasst sind, indem
sie gezielt von Grund auf als Neuentwicklung für den medizinischen Arbeitsplatz entworfen
wurden, sondern häufig Portierungen existierender Anwendungen aus anderen Branchen
sind. So bieten z. B. die medizinischen Arbeitsplätze von Siemens und GWI für den
Anwender nur die Möglichkeit, einfache individualisierte Masken mit Anhakfeldern,
Radiobuttons und Texteingabefeldern zur Datenerfassung zu generieren, deren einzige
Programmlogik die Zuordnung eines Feldes zu Leistungsziffern ist. Diese Masken müssen
zusätzlich vom Anwender selbst entworfen und mit Hilfe eines Editors erstellt werden. Eine
Programmlogik für die Dokumentation in einer klinischen Fachabteilung kann so aber nicht
umgesetzt werden.
Ein weiteres häufig anzutreffendes Problem ist die schlechte Integration unterschiedlicher
Abteilungsinformationssysteme in die "klinische IT-Landschaft". Diese ist meistens auf
mangelnde oder unzureichend implementierte Schnittstellen zu anderen Informationssystemen und medizinischen Großgeräten zurück zu führen (siehe hierzu z. B. Probleme im
DICOM-Umfeld in [Eic02]).
Konkret besteht vor dem dargestellten Hintergrund Forschungs- und Entwicklungsbedarf u.
a. in folgenden Bereichen:
•
6
Analyse der medizinischen Arbeitsplätze
Der klinische Arbeitsablauf und die Strukturen im Krankenhaus müssen
differenzierter untersucht werden, um Software "angepasst" in die tägliche
Routinearbeit zu integrieren. Nur durch Software, die den speziellen Bedürfnissen
des
medizinischen
Personals
gerecht wird,
kann eine tatsächliche
Arbeitserleichterung für diese Zielgruppe und somit eine Akzeptanz in der klinischen
Arbeitsumgebung erreicht werden. Dabei sollte dem Anwender genug Spielraum für
individuelle Konfigurationen gelassen werden, um unterschiedlichen Anforderungen
"vor Ort" gerecht zu werden.
Einleitung
•
Analyse der Anforderungen an ein klinisches Abteilungsinformationssystem
Es muss herausgearbeitet werden, aus welchen Funktionseinheiten eine solche
Software bestehen und welches Leistungsspektrum abgedeckt werden soll. Dabei
spielen nicht nur medizinische Aspekte, sondern auch gesetzliche Vorgaben und die
Integration in die existierende Infrastruktur der Klinik eine Rolle. Es ist zu klären, ob
und wie sich ein neues System unter Nutzung welchen Schnittstellenstandards in ein
klinisches Netzwerk einfügen lässt. Im Vordergrund sollte hier die Vermeidung von
Mehrfacheingaben durch den Anwender und das Ideal einer papierlosen
Krankenakte1 stehen.
•
Methoden zur Visualisierung medizinischer Informationen
Sollte das Ziel einer kompletten digitalen Verfügbarkeit aller klinisch relevanten
Daten eines Patienten erreicht werden, so wird der behandelnde Arzt, insbesondere
bei alten und chronisch kranken Menschen, mit einer unüberschaubaren Flut an
Berichten, Briefen und multimedialen Daten konfrontiert.2 Auf der relativ niedrigen
Ebene eines Abteilungsinformationssystems spielt die Repräsentation der für die
Behandlung relevanten Daten eine wichtige Rolle. Dabei müssen unterschiedliche
Faktoren wie z. B. aktuelle Beschwerden des Patienten, Art und Ausbildungsstand
des Anwenders in der Klinik und räumlicher Standort des Arbeitsplatzes beachtet
werden.
Der Schwerpunkt dieser Arbeit liegt bei der Herleitung eines formalen Modells zur Abbildung
klinischer Arbeitsabläufe und Strukturen. Dieses soll einerseits möglichst flexibel und
hinreichend mächtig sein, um den unterschiedlichen Anforderungen medizinischer
Arbeitsplätze gerecht zu werden andererseits auch komplizierte technische Sachverhalte für
das medizinische Personal möglichst einfach und transparent darstellen. Eine auf diesem
Modell aufbauende komponentenorientierte Software-Architektur soll somit den individuellen
Anforderungen des medizinischen Personals möglichst nahe kommen und dieses bei der
täglichen Routinearbeit entlasten.
Basierend auf den Ergebnissen differenzierter Arbeitsplatzanalysen soll in dieser Arbeit
zunächst ein Modell zur formalen Beschreibung standardisierter medizinischer
Arbeitsabläufe und -plätze entwickelt werden. Hieraus wird ein Konzept zur Implementierung
eines Frameworks abgeleitet. Da ein konkretes Konzept für mehrere oder sogar sämtliche
Fachabteilungen eines Krankenhauses den Rahmen dieser Arbeit deutlich übersteigen und
auch wissenschaftlich keine wesentlich neueren Erkenntnisse bringen würde, wird ein
Modell zur Abbildung klinischer Arbeitsabläufe und darauf aufbauend ein Framework zur
1
Zur genauen Begriffsklärung von Patienten-, Gesundheits- und Krankenakte sei hier auf den ersten
Abschnitt von Kapitel 2 verwiesen
2
Ein prominenter Fall hierfür ist z. B. die Krankenakte von Arafat, die laut Pressemeldung (vgl.
[Spi04]) nur für seinen letzten Aufenthalt in einem französischen Militärhospital Paris über 500 Seiten
umfassen soll.
7
Einleitung
prototypischen Implementierung für eine ausgewählte Abteilung vorgestellt und in der
Zielumgebung getestet. Die Ergebnisse werden dokumentiert, analysiert und kritisch
bewertet, um weitere Verbesserungen in Folgearbeiten zu ermöglichen. Dabei wird Wert auf
eine hinreichend Abstraktion vom Beispiel der Kardiologie gelegt, um die Übertragbarkeit
und (partielle) Widerverwertbarkeit von Konzepten und Realisierungsbausteinen des
Frameworks sicher zustellen.
Als Einsatzfeld für eine praktische Validierung wurde eine kardiologische Abteilung eines
mittelgroßen Krankenhauses der regionalen Vollversorgung mit knapp 800 Betten, konkret
die Kardiologie der Klinikum Oldenburg gGmbH, aus folgenden Gründen gewählt:
•
Sie verfügt mit über 10.000 Aufnahmen und mehr als 30.000 Untersuchungen pro
Jahr über eine bemerkenswerte, zweifellos praxisrelevante Größe.
•
Sie bietet ein breit gefächertes Spektrum unterschiedlicher Untersuchungsmethoden,
die vom körperlichen Untersuchungsbefund bis zur "High-Tech-Medizin" mit HKLaboren (Herzkatheter-Laboren) reicht.
•
In der Kardiologie werden, im Gegensatz zu vielen anderen
Fachabteilungen, sowohl diagnostische als auch therapeutische
angewendet.
•
Kardiologische Patienten sind zu einem Großteil chronisch Kranke, die häufig
wiederkehren und bei denen ein schneller, strukturierter Zugriff auf Vorbefunde
besonders wünschenswert ist.
•
Bei
kardiologischen Untersuchungen fallen
große Datenmengen
unterschiedlichen bildgebenden medizinischen Großgeräten an.
•
In der Kardiologie gibt es in Deutschland bereits viele gesetzliche Vorschriften, die
von der Pflicht zur Therapie- und Diagnoseverschlüsselung über Qualitätssicherung
bis hin zur Röntgenverordnung reichen. Insofern liegen hier komplexere
Rahmenbedingungen als für einen Großteil der anderen Fachabteilungen vor.
•
In der Kardiologie werden sowohl stationäre als auch ambulante Leistungen
erbracht.
klinischen
Verfahren
aus
Zusammenfassend lässt sich also feststellen, dass das gewählte Fachgebiet der Kardiologie
bzgl. Komplexität und Differenzierung besonders anspruchsvoll ist, so dass entsprechende
Lösungen hinreichend umfassend sind, um eine prinzipielle Übertragbarkeit der Konzepte
und Realisierungsbausteine zu unterstützen.
8
Einleitung
1.3 Aufbau der Arbeit
Die nachfolgenden Kapitel der vorliegenden Arbeit sind wie folgt aufgebaut:
•
Grundlagen. In Kapitel 2 werden zunächst grundlegende Begriffsdefinitionen im
Umfeld der medizinischen Informationssysteme, Modellierung, WfMS (WorkflowManagement-Systeme) und des Serviceflows durchgeführt. Weiterhin werden die
relevanten Standards, ihr Aufbau und ihr Einsatzgebiet vorgestellt. Der
Grundlagenteil schließt mit einer Übersicht und Bewertung der am Markt befindlichen
Systeme für eine kardiologische Abteilung.
•
Die klinische kardiologische Fachabteilung. Kapitel 3 beginnt mit einer Übersicht
über die Entwicklung der kardiologischen Abteilung im klinischen Umfeld. Danach
wird ein Überblick über die Komplexität der Arbeitsabläufe und medizinischen
Therapie- und Diagnosemethoden vermittelt. Dabei werden sowohl gesetzliche als
auch medizinische Rahmenbedingungen, wie sie vom Gesetzgeber vorgegeben und
von der Deutschen Gesellschaft für Kardiologie empfohlen werden, vorgestellt.
Abschließend wird in einer Zusammenfassung dargestellt, an welchen Stellen ein ITSystem das medizinische Personal bei seiner Routinetätigkeit unterstützen kann.
•
Serviceflows zur Modellierung klinischer Behandlungsketten. In Kapitel 4 wird
das Modell, welches den zentralen Bestandteil und die formale Grundlage dieser
Arbeit bildet, vorgestellt. Im Mittelpunkt dieses Modells steht der medizinische SP,
der in einen medizinischen Serviceflow eingebettet werden kann. Abschließend wird
an einem Beispiel aus der Kardiologie die prinzipielle Funktionsweise dieses
Ansatzes gezeigt.
•
Eine Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme. Im 5. Kapitel wird eine Software-Architektur vorgestellt, mit
deren Hilfe sich zum einen der Geschäftsprozess basierend auf dem ServiceflowModell aus dem vorherigen Kapitel 4 abbilden lässt und zum anderen die speziellen
in der Medizin geforderten Funktionalitäten implementiert werden können. Es werden
Ergebnisse aus der Installation der ersten Prototypen vorgestellt, die, basierend auf
den in der Arbeit entwickelten Ansätzen, bereits erfolgreich in einer klinischen
Produktionsumgebung eingeführt wurden. Die Darstellung erfolgt aus der
medizinischen Sicht der Ärzte und des Pflegepersonals, die als Pilotanwender mit
der Software arbeiten, und aus der softwaretechnischen Perspektive der Entwickler,
die an der Implementierung der Software-Architektur beteiligt sind.
•
Zusammenfassung und Ausblick. Im 6. Kapitel werden sowohl das Modell als
auch das daraus resultierende Framework kritisch bewertet. Abschließend wird ein
Ausblick auf mögliche weiterführende Arbeiten geworfen.
9
Grundlagen
2 Grundlagen
In diesem Kapitel werden zunächst grundlegende Begriffsdefinitionen eingeführt und danach
die dieser Arbeit zu Grunde liegenden wissenschaftlichen Themengebiete erläutert. Dies
umfasst zum einen den Bereich der WfMS (Workflow-Management-Systeme) mit dem
Schwerpunkt medizinischer Anwendungsdomäne und zum anderen die in der Medizinischen
Informatik zur Anwendung kommenden Standards, insbesondere die Kommunikationsstandards DICOM, HL7 und XDT und die IHE-Initiative.
2.1 Grundlegende Begriffsdefinitionen
In dieser Arbeit werden viele medizinische Fachbegriffe vorgestellt und erläutert.
Vorangestellt sei, dass die Begriffe "medizinische Maßnahme", "medizinisches Verfahren",
"Behandlung" und "Eingriff" synonym verwendet werden. Es wird damit immer ein
medizinischer Eingriff, der diagnostischer oder therapeutischer Art sein kann, und stets an
einem Patienten durchgeführt wird, bezeichnet. Innerhalb eines medizinischen Verfahrens
wird unterschieden zwischen
•
diagnostischen Verfahren, die zur Abklärung dienen, also zum Auffinden oder
Ausschließen von Erkrankungen, meist basierend auf dem Verdacht eines Arztes,
der diese erste Verdachtsdiagnose fast immer auf die Symptome abstützt, die der
Patient zeigt, oder die auf Grund von Ergebnissen aus Voruntersuchungen zur
weiteren Abklärung durchgeführt werden und
•
therapeutischen Verfahren, die zur Behandlung von Erkrankungen oder zur
Bekämpfung von Symptomen dienen und immer durch eine zugehörige Diagnose
induziert sind.
Unter der Therapieempfehlung wird im Folgenden die kurzfristige Empfehlung zur
Weiterbehandlung eines Patienten verstanden. Diese wird durch den zuständigen Facharzt
einer leistungserbringenden Fachabteilung ausgesprochen, nachdem eine medizinische
Maßnahme durchgeführt wurde. Sie enthält Anweisungen für das Stationspersonal welche
Maßnahmen im Rahmen des stationären Aufenthaltes zunächst angewendet werden sollen,
z. B. Anlegen eines Druckverbandes für eine gewisse Dauer, die Kontrolle von Blutwerten
oder die Gabe von speziellen Medikamenten.
11
Grundlagen
Mit dem Procedere wird die längerfristige Weiterbehandlung des Patienten über den
Krankenhausaufenthalt hinaus bezeichnet. Hier wird eine Empfehlung für den
niedergelassenen Facharzt oder den Hausarzt gegeben, die z. B. Durchführung weiterer
medizinischer Maßnahmen, Kontrolle von Blutwerten, Umstellung der Ernährung oder
kontinuierliche Medikamentengabe beinhalten kann.
Mit "medizinische Institution" wird im Folgenden eine Einrichtung des Gesundheitswesen
bezeichnet, die im weitesten Sinne der Versorgung von Patienten dient. Dies kann z. B. eine
Klinik, eine Praxengemeinschaft oder ein Labor sein.
Die folgenden Begriffsdefinitionen erfolgen nach [Pro01]. Im Zusammenhang mit der
elektronischen Dokumentation patientenbezogener Daten werden häufig folgende Begriffe
verwendet:
12
•
EKA (elektronische Krankenakte). Hierin werden alle Informationen, die zu einer
Erkrankung
gehören,
gesammelt.
Die
EKA
bildet
somit
die
Dokumentationsgrundlage innerhalb einer klinischen Abteilung oder Institution, wenn
die Daten in allen Abteilungen derselben abrufbar sind. Aufgabe eines klinischen
Abteilungsinformationssystems ist es daher, die EKA zu einer Menge spezieller
Krankheitsbilder abzubilden.
•
EPA (Elektronische Patientenakte). Die EPA beinhaltet die komplette
Krankengeschichte eines Patienten, also nicht nur die Daten einer medizinischen
Institution, sondern über Institutsgrenzen hinweg sämtliche medizinischen
Informationen aus der Vergangenheit. Im Extremfall seit der Geburt eines Menschen,
bis zum aktuellen Zeitpunkt. Es existieren zwar Systeme, in denen diese
Informationen gesammelt werden können, es wird jedoch nach heutigem Ermessen
nicht möglich sein, die vollständige EPA eines Patienten für einen Arzt zur Verfügung
zu Stellen. Abgesehen von datenschutzrechtlichen Bedenken müsste hierzu eine
zentralisierte, lückenlose Dokumentation durchführbar sein. Ziel eines jeden
medizinischen IT-Systems sollte es aber sein, einen möglichst umfassenden
Ausschnitt der EPA abbilden zu können, also sich nicht nur auf die EKA zu
beschränken, sondern auch die Möglichkeit zur Dokumentation wichtiger
Begleitinformationen, die außerhalb der eigenen Institution angefallen sind, zu
bieten.
•
EGA (Elektronische Gesundheitsakte). Die EGA soll, wie die EPA, auch in der Lage
sein beliebige medizinische Informationen eines Patienten chronologisch abzulegen.
Der Schwerpunkt bei der Definition der EGA zielt aber auf die Kontrolle durch den
"mündigen Bürger". Als Abgrenzung zur EGA fließen in die EPA auch sog.
"Wellnessdaten" (z. B. Lebens-, Ernährungsgewohnheiten oder sportliche
Aktivitäten) und nicht nur Daten, die im Rahmen von Behandlungen durch Ärzte
erhoben wurden, ein.
Grundlagen
Mit dem Begriff KAS (Klinisches Arbeitsplatzsystem), welches synonym auch als
Stationssystem oder Arztarbeitsplatzsystem bezeichnet werden kann, werden Systeme
identifiziert, die Befunde anzeigen und Verwalten können. Diese stammen meistens aus
spezialisierten Informationssystemen für Fachabteilungen. Systeme, die in mehreren
Unterabteilungen einer Fachabteilung oder einen kompletten klinischen Abteilung zum
Einsatz kommen, werden als AIS (Abteilungsinformationssystem) bezeichnet.
Der Begriff KIS (Krankenhausinformationssystem) steht formal gesehen für ein IT-System,
welches alle Belange einer Klinik von der Verwaltung über alle medizinischen Fachbereiche
bis zu Apotheke, Labor und Küche abdeckt. Es hat sich aber etabliert, dass mit KIS das
zentrale IT-System, welches in der Verwaltung, insbesondere zur Patientenaufnahme und
Abrechnung, zum Einsatz kommt, bezeichnet wird. Über dieses IT-System läuft fast immer
der Informationsaustausch mit den AISen.
2.2 Entwicklung medizinischer Abteilungsinformationssysteme
Überlegungen zu IuK-Systemen im Gesundheitswesen unter Stichworten wie "elektronische
Krankenakte" oder "digitale Patientenakte" entstanden schon in den 60er Jahren weit vor
der Entwicklung innovativer Softwareplattformen und leistungsstarker Hardware, wie sie uns
heute zur Verfügung stehen. So werden z. B. in [BMC99] Konzepte von Larry Weed
[Wee68] oder Morrie Collen [Col70] vorgestellt, in denen bereits Überlegungen zur
systematischen Nomenklatur in der Medizin (SNOMED – systemized nomenclature of
medicine) und zur grundsätzlichen Struktur einer elektronischen Krankenakte präsentiert
werden.
Damals standen natürlich Fragen wie etwa Design von grafischen Oberflächen,
prozessorientierte Benutzerführung oder Verfügbarkeit von multimedialen Originaldaten aus
medizinischen Großgeräten noch nicht im Mittelpunkt. Es zeigt sich aber an den älteren
Arbeiten, dass bereits sehr früh Überlegungen zur Ablösung der Krankenakte in Papierform
existierten. Der Medizin haftet hier sicherlich ein etwas konservativer Ruf mit dem
Grundtenor "Das Papier wird bleiben" an, doch zeigt die zunehmende Anzahl von
wissenschaftlichen
und
industriellen
Veranstaltungen
zum
Thema
"IT
im
Gesundheitswesen" und die zunehmende Anzahl an IT-Systemen in Kliniken und Praxen,
dass dieser Ruf längst nicht mehr flächendeckend der Realität entspricht. So werden z. B.
schon seit den 90er Jahren (siehe [BH95]) in Baden-Württemberg durch die
Universitätskliniken Freiburg, Heidelberg, Tübingen und Ulm regelmäßig Symposien zu
diesem Thema abgehalten mit dem Ziel, die IT-Infrastruktur klinikintern und überregional
auszubauen, was auch schrittweise umgesetzt wird.
Zusätzlich werden die Krankenhäuser im Rahmen der Dokumentationspflicht dazu
gezwungen immer mehr Daten zu archivieren. Dies liegt nicht nur am Anstieg der
13
Grundlagen
Behandlungsfälle, sondern auch an immer feineren und ausgefeilteren diagnostischen und
therapeutischen Methoden, bei denen immer mehr und detailliertere Informationen anfallen.
So wird in [Hau95] exemplarisch für ein deutsches Universitätsklinikum als Krankenhaus der
Maximalversorgung das anfallenden Volumen an Akten für die Dokumentation auf 300.000
neue Krankenakten mit 7 Millionen Seiten Papier pro Jahr abgeschätzt. Dies entspricht etwa
1.500 Regalmetern, welche pro Jahr benötigt werden. Von diesen müssen in der Regel 30
Jahrgänge aufgehoben werden und die Tendenz bzgl. des Volumens ist stetig steigend.
Konventionelle Archive für Akten in Papierform beanspruchen sehr viel Fläche und sind
daher teuer. Ein weiteres Problem ist die Sicherheit der Daten. Passiert in einem
konventionellen Archiv ein Unfall mit einer Akte, sei es, dass diese, z. B. durch Feuer,
vernichtet, verlegt oder falsch wegsortiert wird, so sind die Informationen unwiderruflich
verloren, da das Anlegen von Kopien zu teuer und zeitaufwendig ist. Mit digitaler Technik
können kostengünstigere und sicherere Archive erstellt werden, die auch vollautomatisch
kopiert und gesichert werden können.
Es wurde bereits 1996 geschätzt (siehe [Sch96]), dass in einem Universitätsklinikum in
Deutschland jährlich 6 bis 7 Millionen Seiten Papierdokumentation nur durch die
medizinische Dokumentation anfallen. Eine weitere Studie in [Hub00] zeigt für das
Universitätsklinikum Heidelberg einen linearen Zuwachs von jährlich ca. 100.000 mehr
anfallenden Akten als im Vergleichszeitraum des Vorjahres.
Der Trend geht daher zu Systemen, mit denen sich nicht nur einfach Patientendaten
speichern und wieder abrufen lassen, sondern diese auch über lange Zeit archiviert werden
können. Die moderne elektronische Krankenakte soll dem Arzt einen schnellen und
einfachen Zugang sowohl zu aktuellen als auch zu schon länger archivierten Informationen
bieten (vgl. [SOBB98]) und diese durch Integration möglichst vieler digital darstellbarer
Informationen wie Bilder, Filme, Töne, Kurven und Charts anreichern.
Dies gilt insbesondere auch für Abteilungsinformationssysteme in der Kardiologie. So
wurden Überlegungen zur digitalen Erfassung von Ultraschalldaten in der Kardiologie bereits
in den achtziger Jahren angestellt, lange bevor kostengünstige Hardware zur Verarbeitung
von großen Mengen von Filmen und Bildern verfügbar war ([CAKR00], vgl. hierzu auch
Historie der Datenerfassung in der Echokardiographie in [Fei88] und [Fei97]).
Heute werden bereits mehrere Systeme unterschiedlicher Hersteller am Markt angeboten,
die jedoch noch nicht die konventionelle Dokumentation auf Papier abgelöst haben und
auch nicht flächendeckend verwendet werden. Hauptgründe hierfür sind, neben
unzureichender Funktionalität und zu hohem Zeitaufwand für die Bedienung, die Kosten bei
der Erstanschaffung. Z. B. kann für eine Ultraschalluntersuchung in Deutschland im
stationären Bereich kein Entgelt abgerechnet werden. Auch im ambulanten Bereich kann,
selbst bei der Privatliquidation, nur ein geringer Erlös erwirtschaftet werden. Abzüglich der
entstehenden laufenden Kosten für die Untersuchung, bleibt kaum noch Spielraum um die
hohen Anschaffungskosten eines spezialisierten IT-Systems zu finanzieren.
14
Grundlagen
Es muss schon eine signifikante Leistungssteigerung durch ein solches IT-System realisiert
werden, damit sich dieses für eine Klinik oder einen niedergelassenen Arzt amortisiert. Der
Schwerpunkt liegt hier aus wirtschaftlicher Sicht einzig darin, mit dem Gerät bei
bestmöglicher Qualität möglichst viele Untersuchungen in möglichst kurzer Zeit
durchzuführen. Dies ist der Optimierung von Produktionsabläufen, z. B. in
Fertigungsstrassen oder am Fließband, in der Industrie sehr ähnlich. Dokumentation und
Anschaffung von Produkten, die nicht direkt den Durchsatz steigern, sind hier nicht
gewünscht und haben zusätzlich noch den Effekt, dass das medizinische Personal sich eher
in seiner patientenorientierten Arbeit behindert fühlt.
Hier liegt häufig auch das Hauptproblem bei der Einführung von IT-Systemen am
medizinischen Arbeitsplatz, was wiederum die Entwicklung der Systeme bremst. Einige
Hersteller medizinischer Großgeräte entwickeln daher keine eigenen Informationssysteme
für den deutschen Markt (mehr), unter anderem auch um ihre Produkte beim Kunden nicht
direkt mit möglicherweise nicht immer befriedigenden IT-Lösungen zu identifizieren. Es wird
deshalb bevorzugt mit Softwarehäusern kooperiert oder bei diesen Mehrheitsbeteiligungen
eingekauft. So haben z. B. die Firmen Philips und General Electrics kein eigenes
Informationssystem für Herzkatheterlabore, sondern etwa im Falle von Philips mit der Firma
Schwarzer ein Partnerunternehmen, welches ein Informationssystem zur Verfügung stellt.
GE hat die Firma MSP aufgekauft und bietet nun deren Softwarelösung mit den eigenen
Großgeräten an.
Der Vorteil für die großen Firmen liegt klar auf der Hand: Im kurzlebigen Markt der
Softwareentwicklung müssen sie sich nicht festlegen, sondern können den Zulieferer schnell
wechseln, sobald eine andere Firma ein besseres Produkt bietet. Es müssen nur
standardisierte Schnittstellen für den Datenaustausch zwischen medizinischer Modalität
(Herzkatheterlabor, Röntgengerät etc.) und Informationssystem existieren.
In der Praxis sieht dies in Deutschland aber anders aus. Da der Markt für spezielle AISe
sehr klein, der Entwicklungsaufwand sehr groß und zusätzlich hohes medizinisches Knowhow erforderlich ist, ist es ein großes Risiko, solche Systeme neu zu entwickeln. So zog sich
z. B. im Jahr 2002 die Berliner Firma Eskuell AG aus diesem Segment zurück und stellte
Entwicklung und Vertrieb ihres kardiologischen Informationssystems ein, obwohl mit der
Firma Siemens ein großer Produzent von Herzkatheterlaboren als Vertriebspartner
vorhanden war, welcher bei erster Betrachtung einen jährlichen Absatz von Systemen
sichern sollte.
Tatsächlich existieren im deutschen Markt nur eine handvoll Anbieter, deren Produkte schon
länger am Markt sind, und auf Entwicklungs- und Forschungsstand der späten 80er und
90er Jahre basieren. Die Investition in eine komplette Neuentwicklung wird gescheut, da
dies kostenintensiv und der Nutzen fraglich ist. Es ist lukrativer, bestehenden Kunden
Dienstleistungen zu verkaufen, als zu versuchen, mit einer Neuentwicklung der Konkurrenz
Kunden abzuwerben, da die Krankenhäuser bei knapp kalkulierten Budgets auch selten
Mittel für größere Investitionen haben.
15
Grundlagen
Daher ist die Zurückhaltung der Industrie bei der Neuentwicklung solcher "Nischenlösungen"
zu verstehen. Für die großen Firmen zählt in erster Linie der amerikanische und
internationale Markt, deren Produkte aber oft nicht für die speziellen Anforderungen des
deutschen Gesundheitssystems geeignet sind. Den kleinen und mittelständischen Firmen
wiederum fehlen die nötigen Ressourcen um das Risiko, neue Wege zu beschreiten,
abzusichern.
In Deutschland ist derzeit eher eine Stagnation und Konsolidierung (Ende 2004 wurde z. B.
GWI von Agfa aufgekauft, vgl. [AGFA]) im Markt der IT-Lösungen für Kliniken zu
beobachten. Ankündigungen neuer Produkte, wie z. B. Soarian von Siemens (vgl. [SOAR]),
sind eher vage und trotz offizieller Verfügbarkeit, werden statt diesen ältere Produkte,
teilweise unter neuem Namen, verkauft. Dies liegt auch daran, dass in den letzten Jahren
die Hersteller ihre Ressourcen für die Produktentwicklung mit Blick auf den deutschen Markt
für die Umsetzung der neuen Abrechnungsvorschriften nach G-DRG einsetzen mussten.
Dies bringt aber aus Sicht des Anwenders keine neuen Funktionalitäten für die angebotenen
IT-Lösungen.
Vor diesem Hintergrund gibt es noch viel Forschungs- und Entwicklungspotential. Dies gilt
nicht nur für die Weiterentwicklung und Verbesserung bestehender Systeme, sondern auch
für die Neuentwicklung mit dem Ziel, neue Systeme und Einsatzfelder in klinischen
Abteilungen in das Gesamtkonzept einer klinikgerechten IT-Lösung zu integrieren.
2.3 Modellierung
Die Modellierung dient - vereinfacht gesagt - zur abstrakten Darstellung von etwas Realem
und ist unverzichtbarer Bestandteil bei der Entwicklung von Informationssystemen. Nur
durch eine geeignete Repräsentation von Gegenständen und Vorgängen können diese in
einer "digitalen Welt" abgebildet werden.
Eine weitere Aufgabe von Modellen ist die Unterstützung der Kommunikation aller am
Entwicklungsprozess beteiligten Personen. So soll bei der Softwareentwicklung durch das
Modell dem Entwickler die Möglichkeit zur praktischen Implementierung gegeben werden
und der Auftraggeber in die Lage versetzt werden, sein Domänenwissen in einer
hinreichend formalisierten Sicht darzustellen. So kann vermittelt werden, was auf welche
Weise mit welchem Aufwand realisiert werden kann. Dadurch können Personen mit
unterschiedlichen Aufgaben und differenziertem Fachwissen notwendige Informationen über
das Modell austauschen und sich verständigen (vgl. Abb. 2.1). Dies ist auch für die
Projektverantwortlichen wichtig, da durch ein Modell die Abschätzung benötigter
Ressourcen und daraus resultierender Kosten unterstützt werden kann.
16
Grundlagen
Abb. 2.1: Austausch von Informationen über ein Modell: Jeder der an der Entwicklung Beteiligte soll
über das Modell in die Lage versetzt werden, den jeweils Anderen seine Sicht auf ein
Problem zu erläutern.
Modelle können unterschiedliche Ausprägungen und Stadien haben. Diese reichen von der
informellen, noch weitgehend textuellen Beschreibung über semi-formale, oft grafische
Beschreibungen bis hin zu funktionsfähigen Prototypen oder Miniaturmodellen, die schon
Funktionen des Endproduktes simulieren. Für die meisten Modelle gibt es
domänenspezifische Modelltypen, die aus standardisierten oder vordefinierten
Einzelelementen bestehen. So gibt es z. B. bei Bau- oder Schaltplänen feste Symbole für
einzelne Bauteile wie Türen, Tische, Einbauschränke, Widerstände, Kondensatoren oder
Transistoren.
In der klassischen Informatik wird der Begriff des Modells gelegentlich auch für eine
Beschreibungssprache verwendet. Im Bereich der Datenbanken wird mit diesem Begriff
häufig ein Datenmodell oder ER-Modell (Entity Relationship, s. [Che76]) bezeichnet. Hierbei
handelt es sich aber bereits um komplette formale Beschreibungen, die direkt in ausführbare
Kommandos für ein DBMS (Database Management System) umgesetzt werden können.
Bei der Softwareentwicklung kommen in erster Linie abstrakte Modelle zum Einsatz, deren
vorrangiges Ziel es ist, komplexe Vorgänge einfach zu beschreiben. Dies ist sowohl für den
Auftraggeber als auch für den Entwickler entscheidend:
•
Der Entwickler kennt sich häufig mit den Arbeitsabläufen des Endanwenders nicht
aus und muss ein gutes Verständnis für dessen Probleme bekommen, um
konstruktiv Lösungen entwickeln zu können.
•
Der Auftraggeber ist selten in der Lage abzuschätzen, was mit Methoden der
Informatik mit welchem Aufwand zu realisieren ist. Es muss ihm daher ein Gefühl für
die späteren Systemfunktionen, insbesondere Benutzungsoberfläche und
Programmabläufe, vermittelt werden, damit er verifizieren kann, dass seine
Anforderungen umgesetzt werden.
17
Grundlagen
Dieses Erstellen abstrakter Modelle ist als ein etabliertes Standardverfahren bei der
Softwareentwicklung anzusehen (vgl. [Kung89]). Hierfür gibt es Modellierungssprachen und
Metamodelle, die wiederum Methoden zur Beschreibung von Modellen sind. Der Zweig der
Informatik, der sich hiermit beschäftigt, wird meist als "Enterprise Modelling" bezeichnet und
kann auf eine lange Tradition zurückblicken (vgl. z. B. [Fra94] oder [Kim99]).
In der vorliegenden Arbeit steht das Vorgehen beim Übergang vom Modell zum
implementierbaren Informationssystem im Mittelpunkt. Dazu wird zunächst die
Anwendungsdomäne beschrieben, für diese eine spezielle Modellierungssprache vorgestellt
und hieraus schließlich die Grundlage eines implementierbaren Frameworks abgeleitet.
In der Praxis können dazu verschiedene Vorgehen angewendet werden bei denen auch das
Modell im Rahmen des Entwicklungsprozesses verändert und angepasst werden kann.
Dabei wird grundsätzlich zwischen linearen und zyklischen Modellen unterschieden. Der
grundlegende Unterschied liegt darin, dass bei linearem Vorgehen jede Phase
abgeschlossen wird und deren Ergebnisse nicht mehr verändert werden. Es gibt dort eine
klare Reihenfolge von der Anforderungsspezifikation über Entwurf, Implementierung und
Testphase bis zum Produktionseinsatz.
Bei zyklischen Prozessen können nach Abschluss einer Phase wiederum Änderungen in
andern Bereichen vorgenommen werden. So kann z. B. nach dem ersten Einsatz die
Anforderungsspezifikation
überarbeitet
werden,
was
zu
einer
erneuten
Implementierungsphase, einem Test und der Einführung eines überarbeiteten Produktes im
Produktiveinsatz führt.
Lineare Entwicklungsprozesse haben den Nachteil, dass Fehler in abgeschlossenen Phasen
nicht korrigiert werden können. Sie eignen sich für Projekte mit überschaubaren und festen
Anforderung. Dort bieten sie den Vorteil, dass der Aufwand sehr gut abschätzbar ist und
allen Beteiligten ihre Aufgaben und Vorgaben vollständig sehen.
Zyklische Prozesse zeigen ihre Stärken bei der Entwicklung von Systemen, bei denen
vorher bekannt ist, dass sie ständig erweitert werden müssen oder nicht von vorneherein
bekannt ist, wie welche Anforderungen am Besten umzusetzen sind. In der Medizin und
insbesondere der Kardiologie kann davon ausgegangen werden, dass durch die aktive
Forschung neue Erkenntnisse und daraus resultierend neue Behandlungsmethoden und
medizintechnische Produkte etabliert werden. Hieraus ergeben sich auch neue
Anforderungen an Dokumentationssoftware und Archivsysteme um Ergebnisse neu
entwickelter medizinischer Methoden in geeigneter Weise zu speichern und zu
dokumentieren.
Weiterhin ändern sich die Anforderungen des Gesetzgebers. So gab es in Deutschland in
den letzten zehn Jahren zwei vollständige Überarbeitungen des Abrechnungswesen für
Krankenhäuser (Einführung der Fallpauschalen und Sonderentgelte im Jahr 1995 und
Umstellung auf das G-DRG-System 2004) und jährlich kleinere Modifikationen der
Codierungsrichtlinien. Darüber hinaus gab es mit der verpflichtenden Einführung der
18
Grundlagen
Meldung von Qualitätssicherungsdaten
Dokumentationspflicht.
eine
einschneidende
Veränderung
der
Da hier davon ausgegangen werden kann, dass es in Zukunft weitere gravierende
Änderungen geben wird, ist es angebracht zyklische Entwicklungsprozesse für medizinische
Informationssysteme anzuwenden.
2.4 Workflow-Management-Systeme
Die Ursprünge der WfMSe (Workflow-Management-Systeme) können auf das Workgroup
Computing zurückgeführt werden. Dies fällt unter den allgemeinen Begriff des CSCW
(Computer Supported Cooperative Work, vgl. Abb. 2.2), bei dem die Durchführung einer
Gruppenarbeit, die in diesem Kontext auch als Geschäftsprozess bezeichnet wird, durch
mehrere beteiligte Personen unterstützt werden soll.
Abb. 2.2: Einordnung unterschiedlicher Systemklassen innerhalb des CSCW nach [Bau02] und
[Sch01a]
19
Grundlagen
Mit der zunehmenden Vernetzung von Rechnern entstanden zunächst Anwendungen für
asynchrones kooperatives Arbeiten, welche seit Beginn der 90er Jahre immer stärkeren
Einfluss auf die IT-Landschaft nahmen (vgl. z. B. [BHJ91], [Smit91]). Auch im Bereich der
Betriebssysteme wurde der Aspekt der Arbeitsgruppen und des Datenaustausches
zunehmend beachtet. Microsoft brachte 1993 mit "Windows for Workgroups" eine
hauseigene Lösung zur Unterstützung kooperativer Arbeit kleiner Arbeitsgruppen unter
Verwendung vernetzter Computer auf den Markt. Andere Hersteller wie z. B. Apple oder
AT&T hatten schon früher eine weit reichende Unterstützung von Netzwerkdiensten in ihre
Betriebssysteme integriert. Die Microsoftlösung brachte aber letztlich auf Grund der
Marktdominanz von Windows den endgültigen Durchbruch für die vernetzte Arbeit mit
Desktop-PCs.
Im Bereich des Workgroup Computing entstanden Produkte, die unter dem Sammelbegriff
"Groupware" bekannt wurden. Die wichtigsten Aufgaben dieser Systeme sind
•
E-Mail
•
Terminplanung mit gemeinsam nutzbaren Terminkalendern
•
Planung und Belegung
Firmenfahrzeuge
•
Gemeinsame Nutzung von Ressourcen im Netzwerk wie z. B. Drucker und
Faxgeräte
•
Gemeinsame Nutzung und Bearbeitung von Dokumenten.
von
Ressourcen
wie
z. B.
Konferenzräume
oder
Bekannte Produkte aus dem Bereich der Groupware sind "Lotus Notes", "Exchange" oder
"Groupwise".
Das WfM hat in der letzten Dekade sowohl in der Forschung als auch im praktischen Einsatz
ein so hohes Interesse gefunden, dass es als eigenständiges Gebiet innerhalb des CSCW
angesehen werden kann. Es lediglich als eine Ausprägung der Groupware zu sehen, würde
seiner Bedeutung nicht gerecht.
Die Workflow-Management-Coalition definiert auf ihrer Website unter [WFMC] ein WfMS
folgendermaßen:
"A system that completely defines, manages, and executes workflows through the
execution of software whose order of execution is driven by a computer representation
of the workflow logic. The ultimate goal of workflow management is to make sure that
the proper activities are executed by the right person at the right time."
Eine ähnliche Definition nach McCarthy & Bluestein (siehe [MB91]) beschreibt ein WfM so:
"Workflow management software is a proactive computer system which manages the
flow of work among participants according to a defined procedure consisting of a
number of tasks. It coordinates user and system participants, together with appropriate
data resources which may be accessible directly by the system or off-line to achieve
20
Grundlagen
defined objectives by set deadlines. The coordination involves the passing of tasks from
participant to participant in correct sequence ensuring that all fulfil their required
contributions taking default actions when necessary."
Die zentrale Aufgabe von WfMS ist also die Modellierung, Koordinierung und
Automatisierung von Arbeitsabläufen. Dabei geht es aber nicht um eine vollständige
Automatisierung von Arbeitsschritten. Vielmehr sind auch Benutzerinteraktionen in den
Modellen vorgesehen.
Wie beim Enterprise Modelling bietet sich für die Modellierung der Anwendungsdomäne mit
Hilfe von WfMS eine Unterteilung in Aufbauorganisation, wie z. B. die Mitarbeiterstruktur,
und Ablauforganisation, welche die Geschäftsprozesse darstellt, an. Für eine rein informelle
Sicht können erstere als Organigramme und letztere als Flussdiagramme dargestellt
werden. In Abb. 2.3 ist ein einfaches Organigramm und in Abb. 2.4 ein Flussdiagramm
abgebildet.
In diesem Beispiel fällt auf, dass einfache "statische" Diagramme zur Abbildung von
Organisationen unzureichend sind:
•
Im Organigramm fehlt die Weisungsbefugnis zwischen Arzt und Pflegepersonal. Hier
ist zu beachten, dass der Chefarzt nicht direkter Vorgesetzter des Pflegepersonals
ist. Dies ist die Pflegedienstleitung. Jedoch sind alle Ärzte gegenüber dem
Pflegepersonal weisungsbefugt.
•
Es lassen sich keine Mitarbeitergruppen bilden. Bei der Angabe des zuständigen
Personals im Flussdiagramm in Abb. 2.4 wurden Personalgruppen verwendet,
obwohl diese gar nicht im Organigramm definiert sind. Intuitiv ist zwar klar, was
gemeint ist, formal ist dies aber nicht spezifiziert.
Abb. 2.3: Beispiel für ein einfaches Organigramm
21
Grundlagen
Abb. 2.4: Behandlung von Patienten in einer Klinik: Jeder Schritt soll in der zentralen Datenbank
dokumentiert werden.
Daher gibt es im Bereich der WfMS unterschiedliche Ansätze und Werkzeuge mit einer
Vielzahl an nicht immer exakt spezifizierten Symbolen und Transaktionen, d. h. ohne eine
formal spezifizierte Semantik. Drei grundsätzlich unterschiedliche Ansätze mit zugehörigen
Beispielen seien hier genannt.
22
•
Werkzeuge, deren Fokus auf der Visualisierung der einzelnen Arbeitsschritte liegen:
Diese dienen der standardisierten Darstellung aller an einem Prozess beteiligten
Ressourcen (sowohl Personen als auch Daten, Informationen, Geräte und
Organisationsstrukturen) und der Repräsentation in einer Form, die sowohl aus
Entwickler- als auch aus Anwendersicht leicht zu verstehen ist. Eines der
bekanntesten Produkte dieses Ansatzes ist ARIS (siehe [IDS]).
•
Beschreibungssprachen für Arbeitsabläufe: Diese Sprachen sind für die formale
Definition von Arbeitsabläufen entworfen worden. Ziel ist die Standardisierung der
Darstellung von Geschäftsprozessen, die auf unterschiedlichen Applikationen,
Grundlagen
Datenformaten, Organisationseinheiten, Firmen und Geschäftspartnern basieren,
sowohl hinter der Firewall als auch im Internet. Diese sind häufig in
Softwareprodukte eingebettet, wie dies z. B. bei BizTalk von Microsoft der Fall ist.
Weiterhin gibt es mit BPML (Business Process Modelling Language, siehe [BPMI]),
deren erste Version 2001 vorgestellt wurde, auch schon eine standardisierte
Sprache.
•
Integrierte Systeme: Hier wird versucht, die beiden oben genannten Ansätze in
einem Werkzeug zu vereinen. Sie verfügen zum einen über eine Möglichkeit zur
Visualisierung der modellierten Geschäftsprozesse, die auch von Anwendern
verstanden werden können, basieren zum anderen aber auf formalen Modellen, die
eine direkte Umsetzung des Modells in algorithmische Strukturen zulässt. Ein
Beispiel hierfür ist ADEPT (vgl. [DKRB95], [ADEPT]), welches über eigene
Softwarewerkzeuge zur Modellierung und Simulation von Arbeitsabläufen verfügt.
Es stellt sich jedoch die Frage, ob WfMS, wie sie derzeit in der Praxis, insbesondere in
bekannten Umsetzungen als Basis integrierter ERP-Systeme (Enterprise-ResourcePlanning) wie SAP R/3 in Banken, Handel oder Industrie eingesetzt werden, für die
Modellierung klinischer Arbeitsabläufe geeignet sind. So kommt die Ulmer Arbeitsgruppe
nach [DRK97] zu der Ansicht, dass diese klinischen Abläufe "Killer-Applikationen" für
prozessorientierte Systeme seien. Auch an anderen Stellen, z. B. in [BKMJ04] und
[MLMJ04], wird auf Nachteile beim Einsatz von WfMSen im klinischen Umfeld hingewiesen
und diesen eher skeptisch begegnet.
Der am häufigsten angeführte Nachteil ist die geringe Flexibilität von WfMSen.
Arbeitsabläufe sind starr an Ablaufdiagramme gebunden, die zwar für jeden möglichen Fall,
der eintreten kann, Verzweigungen erlauben. Für jede dieser Verzweigungen muss aber ein
Entscheidungsknoten in jedes Ablaufdiagramm eingefügt werden. Bei der großen Zahl
möglicher Komplikationen und unvorhersehbaren Ereignissen in der Medizin würde dies zu
sehr großen und unübersichtlichen Diagrammen führen.
Um diesen Nachteilen von WfMSen im klinischen Umfeld zu begegnen, wurden in der
Vergangenheit verschiedene Erweiterungen für das WfM vorgestellt. Zu den bekanntesten
Ansätzen zählt hier ADEPT, welches nachfolgend als Beispiel für erweiterte WfMSe kurz
vorgestellt werden soll. Die im Folgenden aufgeführten Angaben zu ADEPT stammen
größtenteils aus [ADEPT], [DKRB95], [RR02] und [RRD03]. Dort können weitere, detaillierte
Informationen zu ADEPT eingesehen werden.
Ein Schwerpunkt adaptiver WfMSe ist die adäquate Unterstützung spontaner Abweichungen
vom modellierten Ablauf zur Laufzeit. Solche "Ad-Hoc"-Änderungen können z. B. das
Einfügen, Löschen oder Verschieben von Aktivitäten während der Abarbeitung von
Geschäftsprossen sein. Hier muss sich das WfMS den Änderungen anpassen. Deshalb
werden erweiterte WfMSe, die dies ermöglichen, als "adaptiv" bezeichnet. ADEPT ist ein
23
Grundlagen
solches adaptives WfMS, welches formal Erweiterungen für WfMSe beschreibt, die
insbesondere "Ad-Hoc"-Änderungen zulassen.
Zentrale Aspekte von ADEPT, dessen Ursprünge auf das Jahr 1996 zurückgehen, sind die
formale Modellierung von
•
zeitlichen Vorgaben, mit deren Hilfe minimale und maximale Abarbeitungszeiten von
Aktivitäten definiert werden können,
•
Behandlungen von Ausnahmen im Arbeitsablauf, die dynamisch während der
Laufzeit das Ablaufdiagramm modifizieren können,
•
Reaktion auf "Ad-Hoc"-Änderungen,
•
Evolutionen von Workflow-Schemata, zur Nachvollziehbarkeit von Änderungen, die
im Laufe der Zeit an einem Modell durchgeführt wurden, sowie
•
Spezifikation und Synchronisation von Aktivitäten, die auch nebenläufig oder in
Arbeitsabläufen, die mit unterschiedlichen WfM-Diagrammen modelliert sind,
definiert wurden.
Neben grundlegenden konzeptionellen Arbeiten wurden im ADEPT-Projekt auch
Softwarewerkzeuge entwickelt, die dem Anwender die Möglichkeit zur Modellierung seiner
Geschäftsprozesse und Simulationen der erstellten Modelle ermöglichen. Diese
Simulationen betreffen insbesondere die Reaktion der modellierten Arbeitsabläufe auf das
Eintreten von außergewöhnlichen Ereignissen. Hier kann der Anwender nachvollziehen, ob
das Modell sich diesen neuen Rahmenbedingungen korrekt anpasst (also “adaptiert“) und
das gewünschte Resultat liefert.
Mit ADEPT liegt somit ein mächtiges und äußerst komplexes Werkzeug als Erweiterung
klassischer WfMSe vor, welches flexible, zeitgesteuerte und synchronisierte Aktivitäten in
WfMSen definiert und ihre Verarbeitung zur Laufzeit ermöglicht. Wie bei klassischen WfMModellen steht auch bei ADEPT der Ablauf von Geschäftsprozessen im Mittelpunkt.
Im Gegensatz dazu werden in dieser Arbeit nicht die Prozesse, sondern der Patient und die
für diesen erbrachte Dienstleistung, also die Behandlung von Erkrankungen, in den
Mittelpunkt gestellt. Dabei wird mit dem Konzept des im Folgenden noch näher
beschriebenen Serviceflow ein Modell geschaffen, das der Sichtweise des medizinischen
Personals entspricht. Dieses Modell versteht sich somit als Alternative, die einen anderen
Ansatz bei der Betrachtung klinischer Strukturen aufzeigt, aber das WfM und darauf
aufbauende Arbeiten wie ADEPT nicht außer Acht lässt. Im folgenden Abschnitt 2.5 wird
daher auch auf den engen Zusammenhang zwischen WfM und dem sog. Serviceflow,
welcher Grundlage dieser Arbeit ist, eingegangen.
24
Grundlagen
2.5 Serviceflow
Der Serviceflow rückt, wie schon aus dem Namen erkennbar, die Dienstleistung (Service) in
den Mittelpunkt des Modells. Diese sind in [KW00] wie folgt definiert:
"Services sind soziale Beziehungen, basierend auf einer Vereinbarung, zum Zweck der
Bedürfnisbefriedigung."
"Service ist eine unternehmerische Leistung, die ihre Wertschöpfung darauf gründet, die
Bedürfnisse des Kunden zu erkennen und zu befriedigen. Dafür werden nach
Möglichkeit betriebliche Standardabläufe auf die Erfordernisse der jeweiligen
Dienstleistungssituation angepasst."
Eine Organisation, sei dies nun eine Firma oder eine Klinik, hat gegenüber dem Kunden ihr
Leistungsziel erfüllt, wenn der Kunde mit der für ihn erbrachten Dienstleistung zufrieden ist.
Dabei interessiert ihn zunächst das erzielte Resultat und nur indirekt wie dies erreicht wurde.
In komplexen Arbeitsumgebungen, bei denen eine Dienstleistung aus vielen einzelnen
Teilleistungen besteht, ist eine möglichst effiziente Kooperation und Koordination bei der
Erbringung von Teilleistungen wünschenswert. Im Gegensatz zum WfM, welches den
"Arbeitsfluss" in den Mittelpunkt stellt, dreht sich beim Serviceflow alles um den
Bearbeitungsgegenstand, z. B. eine Prozessakte, die von Sacharbeiter zu Sachbearbeiter
(in der Justiz z. B. von der Klageschrift bis zum Urteil) weitergereicht und bearbeitet wird.
Der Gesamtprozess des Serviceflow mit seinen unterschiedlichen Perspektiven für
Dienstleister (Serviceerbringer) und Kunden wird in [KW00] wie folgt definiert:
"Die Wertschöpfung (bzw. der Erfolg des Service) hängt jeweils entscheidend davon ab,
dass der Kunde/Klient die über Zeit-, Orts- und Teamgrenzen hinweg erbrachten
Teilleistungen als aufeinander aufbauend und kontinuierlich innerhalb einer
umfassenden Gesamtleistung erlebt. Diese umfassende Gesamtleistung bezeichnen wir
als Serviceflow verbunden mit folgenden Sichtweisen:
•
Aus Perspektive des Kunden stellt sich ein Serviceflow so dar, als ob der Kunde in
einen zusammenhängenden "Fluss von Dienstleistungen" eingebettet ist, wobei
dem sich zeitlich und räumlich bewegenden Kunden Serviceleistungen "folgen",
"begleiten" oder "vorauseilen", sozusagen "umspülen" und dabei auf dem Weg der
Bedürfnisbefriedigung voranbringen.
•
Aus Perspektive des Serviceerbringers steht die Verbindung und das aufeinander
Aufbauende der situativen Einzelleistungen über Zeit-, Ort- und Teamgrenzen
hinweg im Vordergrund, die sich zu einer kontinuierlichen und umfassenden
Gesamtleistung am sich "bewegenden" Kunden zusammensetzen (basierend auf
Standardabläufen). Diese Herausforderung besteht darin, durch geeignete
organisatorische Maßnahmen sowohl für einen Kunden, als auch für viele Kunden
parallel diese umfassende Serviceleistung zu ermöglichen."
25
Grundlagen
Die einzelnen Teilleistungen werden durch die so genannten SPs (Service Points), welche
also die Leistungsanbieter darstellen, erbracht. Dies sind zumeist die Stellen, an denen der
Kunde mit dem Dienstleister in direkten Kontakt tritt, wobei es aber auch SPs geben kann,
die nur Hintergrundprozesse ohne einen direkten Kundenkontakt durchführen. Um die
gesamte Wertschöpfungskette zu durchlaufen, bewegt sich der Kunde auf einem Pfad von
SP zu SP.
In Abb. 2.5 ist ein solcher Weg zwischen unterschiedlichen SPs dargestellt. Dabei muss
nicht immer ein fest vorgegebener Pfad durchlaufen werden. Vielmehr kann es auch
Verzweigungen geben. Damit die Leistungserbringung beginnen und schließlich
abgeschlossen werden kann muss nur gewährleistet sein, dass es auf jedem Pfad einen
Start- und Endpunkt gibt. In der grafischen Darstellung kann durch die Größe der SPs
dargestellt werden, welcher Aufwand für den Dienstleister bei der Abarbeitung der
Tätigkeiten für den Kunden zu erwarten ist.
Abb. 2.5: Serviceflow-Muster nach [KW00]. Dargestellt ist ein Standardablauf mit möglichen
Alternativen.
26
Grundlagen
Nach [KW00] gründet Serviceflow-Management zunächst auf der gleichen Idee wie
Workflow-Management, da beide
der Organisation von Arbeitsteilung und Kooperation [dienen], indem sie aufbauend auf
dem Bild vom "Fluß" als Metapher für die Verbindung von Einzelleistungen der
Beteiligten Prozeßmuster modellieren, instantiieren und abarbeiten.
Im Gegensatz zum WfM, welches versucht die Abfolge der Arbeitsschritte und die damit
verbundene Prozesslogik durch feste Regeln zu definieren, wird beim Serviceflow am Ende
einer Teilbearbeitung durch einen SP neu über den nächsten anzuwendenden
Verarbeitungsschritt und den hierfür in Frage kommenden SP nachgedacht. Um diese
Entscheidung durchzuführen, verfügt jeder SP über Vorbedingungen, die sog.
"Preconditions".
Um entscheiden zu können, ob Bedingungen erfüllt sind, müssen in geeigneter Weise
Informationen gespeichert werden. Diese fallen während des Durchlaufens der
Wertschöpfungskette, insbesondere durch Tätigkeiten innerhalb eines SP, an. In der Praxis
repräsentiert dies dann z. B. den Inhalt einer Prozess- oder Krankenakte.
Hierfür existiert beim Serviceflow das sog. "Servicefloat", welches nach [Anz02] als
personalisierte Prozessrepräsentation von einem Servicepunkt
weitergeleitet und dabei entsprechend fortgeschrieben wird.
zum
nächsten
Es wird in [Anz02] vorgeschlagen dies als XML-Dokument zu realisieren. Dies kann aber
auch in Form eines relationen Datenmodells auf das mit Hilfe eines RDBMS (Relational
Database Management System) zugegriffen wird oder in einem beliebigen Dateiformat
geschehen.
Innerhalb eines SP kommen sog. SP-Skripte zum Einsatz, die den konkreten Arbeitsablauf
in einem SP abbilden und für die Modifikation des Servicefloats sorgen. Wenn Prozesse
parallel ablaufen, kann das Servicefloat für die einzelnen SP kopiert und später wieder
synchronisiert werden. Hierfür ist eine Kooperationsabstimmung zwischen allen Prozessen,
die das Servicefloat modifizieren notwendig.
In Abb. 2.6 sind die Vorgänge in und um einen SP näher dargestellt. Neben der eigentlichen
Tätigkeit am Kunden durch die Mitarbeiter gibt es zusätzlich Hintergrundprozesse und
Koordinationsabstimmungen. Diese bekommt der Kunde zwar nicht direkt mit, sie sind aber
wichtig für die gesamte Dienstleistung.
27
Grundlagen
Abb. 2.6: Serviceflow-Beispiel mit Supportprozessen und individuellem Arbeitsablauf an einem SP
nach [KW00]
Neben den Preconditions und den Skripten kann ein SP auch noch über Nachbedingungen,
die sog. Postconditions, verfügen. Diese sichern Eigenschaften oder Zustände des
Servicefloats beim Verlassen des SP zu (vgl. Abb. 2.7).
Abb. 2.7: SP mit Aktivitäten, Vor- und Nachbedingungen nach [KW02]
Serviceflow soll das Management komplexer vernetzter Dienstleistungen, bei denen ein
Kunde viele Teildienstleistungen in Anspruch nimmt, vereinfachen. Hier wird versucht mehr
28
Grundlagen
Flexibilität und eine situationsbedingte Anpassung der Auswahl des nächsten
Arbeitsschrittes zu bieten als dies bei WfM möglich ist. Dabei will das SFM aber nicht
bestehende Modelle ablösen, sondern als Erweiterung, die auf existierenden Konzepten und
Systemen aufsetzt, verstanden werden.
Da es sich beim Serviceflow noch um einen recht jungen Ansatz zur Modellierung von
Geschäftsprozessen handelt, gibt es auch noch wenig Erfahrung beim Einsatz von ITSystemen, die diese Idee in der Praxis umsetzen. Jedoch scheint der Ansatz viel
versprechend, insbesondere für Umgebungen wie ein Krankenhaus, in dem der
Arbeitsablauf schwer vorherzusehen ist, da sich schrittweise diagnostizierte Krankheitsbilder
und der gesundheitliche Zustand eines Patienten oft nicht wie geplant entwickeln und somit
auf unvorhergesehene Ereignisse flexibel reagiert werden muss.
2.6 Standards in der medizinischen Informatik
Zum Betrieb medizinischer Informationssysteme ist ein Datenaustausch zwischen einzelnen
Systemen und medizinischen Großgeräten zwingend notwendig, da zurzeit kein System
eines einzigen Herstellers in der Lage ist, alle Bereiche einer Klinik abzudecken.
Wünschenswert sind hier Standards, die eine Kopplung beliebiger Komponenten
unterschiedlicher Anbieter ermöglichen. In Deutschland haben sich hierzu innerhalb lokaler
Netzwerke drei Standards am Markt durchgesetzt:
•
DICOM (Digital Imaging and Communications in Medicine)
•
HL7 (Health Level 7)
•
XDT, Oberbegriff für eine Gruppe sehr ähnlicher Standards, deren wichtigste
Vertreter ADT (Abrechnungsdatentransfer), BDT (Behandlungsdatentransfer), GDT
(Gerätedatentransfer) und LDT (Labordatentransfer) sind.
Innerhalb dieser Standards gibt es diverse Interpretationsmöglichkeiten, insbesondere bzgl.
der Semantik von Feldinhalten, und teilweise ungeklärte oder unterschiedlich
interpretierbare Verhaltensvorschriften für Sender und/oder Empfänger. Dies gilt
insbesondere für das Verhalten von Komponenten, wenn Fehler auftreten. Des Weiteren
gibt es Überschneidungen der Einsatzgebiete der unterschiedlichen Standards mit der
Frage, welches Feld des einen Standards sich auf welches Feld eines anderen Standards
wie abbilden lässt. Da es hier in den letzten Jahren immer wieder Schwierigkeiten bei der
Kopplung von Systemen gegeben hat, wurde durch die Produkthersteller versucht mit Hilfe
eines weiteren Standards Klarheit und feste Vorschriften zu schaffen. Die wichtigste
Initiative, die sich darum kümmert, ist die IHE (Integrating the Healthcare Enterprise).
In diesem Abschnitt werden die Kommunikationsstandards, die IHE-Initiative und ihre
Bedeutung für die Entwicklung medizinischer AISe vorgestellt.
29
Grundlagen
2.6.1 DICOM
Dieser Abschnitt enthält eine Kurzfassung der Einführung aus [Eic02] mit einigen
Ergänzungen und zusätzlichen Erklärungen, die im Rahmen dieser Arbeit relevant sind. Für
eine umfassendere Einführung sei hier daher auf [Eic02] und die dort referenzierte, weiter
führende Literatur verwiesen.
Spätestens mit dem Aufkommen der Idee einer digitalen Archivierung von Bildern in so
genannten PACSs (Picture Archiving and Communication System) und einer elektronischen
Bildverteilung im Krankenhaus entstand das Bedürfnis, digitale Bilder zwischen
medizinischen Großgeräten und Informationssystemen verschiedener Hersteller
austauschen zu können. Diese Überlegungen kamen zunächst in der Radiologie als
Bestandteil von Radiologie-AISen auf und wurden kurz danach in anderen Abteilungen, die
bildgebende diagnostische und therapeutische Verfahren verwenden, aufgegriffen. Zu
diesen Abteilungen gehören auch die Innere Medizin und die Kardiologie, in denen bei
medizinischen Maßnahmen wie Angiografien oder Echokardiogrammen große Mengen
multimedialer Daten anfallen.
Ziel des DICOM-Standards, welcher 1993 verabschiedet und seitdem kontinuierlich weiter
entwickelt wurde, ist es daher, eine offene, herstellerunabhängige Kommunikationsbasis für
den Austausch medizinisch relevanter Informationen zu schaffen. Der Schwerpunkt des
Standards liegt auf der Übertragung von Bildern und Filmen in Form von aneinander
gereihten Einzelbildern (Multiframe). Zusätzlich bietet DICOM die Möglichkeit, diskrete
Messwerte und Kurven (Waveforms) zu übertragen. Seit kurzem gibt es auch eine
Erweiterung für die Übermittlung von Reporten (Structured Reports). Der DICOM-Standard
beschränkt sich dabei nicht nur auf das Format der Nutzdaten, sondern spezifiziert darüber
hinaus Netzwerkdienste, zu verwendende Datenträger und Anforderungen an
standardkonforme Geräte und Programme.
Wichtiges Merkmal aller DICOM-Objekte, welche Nutzdaten wie z. B. Bilder enthalten, ist ihr
Aufbau als Liste von Datenelementen, den so genannten DICOM-Attributen. Diese enthalten
neben den eigentlichen Bilddaten begleitende Informationen. Dabei handelt es sich in der
Regel um patientenbezogene Daten, Untersuchungsinformationen (z. B. Strahlendosis) und
Daten darüber, unter welchen technischen Bedingungen (z. B. Kalibrierung,
Aufnahmewinkel) die Aufnahme entstanden ist.
Die DICOM-Netzwerkdienste bedienen sich des Client-/Server-Konzeptes. Jeder an der
Kommunikation beteiligte Knoten, sei es ein Informationssystem oder medizinisches Gerät,
wird als "Application Entity" bezeichnet. Die Geräte, die Daten von Untersuchungen
versenden, werden Modalität (modality) genannt. Bei den Daten handelt es sich meistens
um Filme und/oder Bilder, seltener auch um Messkurven, wie z. B. beim EKG.
30
Grundlagen
Im Standard ist genau festgehalten, wer Server und wer Client ist, welche "Application
Entity" auf welche Anfrage unter Nutzung welcher Dienste wie zu antworten hat und wie die
Daten übertragen werden müssen. In der Praxis sind die wichtigsten Dienste:
•
DICOM-Dienst zur Bildübertragung (Storage) von einer Modalität (im Allgemeinen
medizinisches Gerät) an ein PACS
•
DICOM-Dienst zur Übermittlung von Arbeitsaufträgen (WLM, Worklistmanagement)
inklusive aller relevanten Informationen, wie z. B. Patientenstammdaten, von einem
Informationssystem an eine Modalität (meistens medizinisches Großgerät)
•
DICOM-Dienst zur Übermittlung des Gerätestatus (MPPS, Modality Performed
Procedure Step) und aktuell relevanter medizinischer Informationen (z. B. Messwerte
oder Anzahl produzierter Bilder) von einer Modalität (im Allgemeinen medizinisches
Gerät) an ein Informationssystem
•
DICOM-Bildarchiv-Dienst zur Abfrage von Bildern (Query/Retrieve) anhand
ausgewählter Informationen, meist Patienten- oder Untersuchungsdaten, aus einem
PACS
•
DICOM-Dienst zur Bestätigung des erfolgreichen Empfangs von Objekten (Storage
Commitment), insbesondere Bilder und Filme, die von einer Modalität an ein PACS
gesendet wurden
•
DICOM-Druckdienst zur Ausgabe von Bildern (Print Management) auf Druckern und
Belichtern.
Neben Standards für die Kommunikation über lokale Netzwerke bietet DICOM seit 1996
auch eine Spezifikation für den Datenträgeraustausch. Dieser beschreibt neben der
Dateistruktur und den Dateiinhalten auf dem Datenträger auch dessen physikalische
Beschaffenheit. Zusätzlich muss jeder Datenträger über ein Inhaltsverzeichnis ("DICOM
directory"), welches sich immer auf der obersten Ebene des Datenträgers in einer Datei mit
dem Namen "DICOMDIR" befindet, verfügen. In diesem ist eine Übersicht über die Objekte
auf dem Datenträger und eine Referenz auf jedes Dateiobjekt enthalten. Dies erlaubt nicht
nur einen schnellen Überblick über und Zugriff auf den Inhalt, sondern erleichtert und
beschleunigt auch das Durchsuchen großer Datenmengen.
Für unterschiedliche Anwendungsgebiete sind für den Datenträgeraustausch Anwendungsprofile ("Application Profiles") definiert. So existieren z. B. für die Kardiologie unter den
Bezeichnungen "Basic Cardiac X-Ray Angiographic Studies on CDR-Media" und "1024 XRay Angiographic Studies on CDR-Media" zwei eigene Profile zur Speicherung von
Herzkatheterfilmen auf CDs. Diese definieren unter anderem genau in welcher Auflösung
31
Grundlagen
und unter Verwendung welches Kompressionsverfahrens welche DICOM-Objekte auf der
CD abgelegt werden dürfen3.
Jedes standardkonforme Produkt muss über eine Konformitätserklärung ("DICOM
Conformance Statement") verfügen. In dieser ist genau festgehalten, welche Dienste und
Optionen unterstützt werden und was beim Betrieb des Produktes zu beachten ist. Dadurch
soll es für den Anwender schon vor Kauf oder Inbetriebnahme von Produkten
unterschiedlicher Hersteller möglich sein, nur durch Vergleich der "Conformance
Statements" zu prüfen, ob diese interoperabel sind.
In der Praxis hat sich DICOM heute als führender Standard zur Übertragung von
Bildinformationen in der Medizin durchgesetzt und wird von allen bedeutenden Geräte- und
Softwareherstellern unterstützt. DICOM hat stark zur Verbesserung der Kommunikation in
klinischen Netzwerken beigetragen, was insbesondere für den Kunden vorteilhaft ist, da er
so nicht zwingend auf Systeme eines einzelnen Herstellers angewiesen ist.
In den Kardiologien in Deutschland hat sich DICOM als Kommunikationsstandard seit Ende
der 90er Jahre flächendeckend durchgesetzt. Dies wurde durch den Gesetzgeber mit der
Förderung von medizinischen Großgeräten, die DICOM-kompatibel sind, forciert. Dadurch
wurde dieser Standard essentieller Bestandteil jeder Ausschreibung bei der Neuanschaffung
solcher Geräte und die Hersteller mussten diesen Standard als Teil ihrer Produkte anbieten,
um keine Aufträge zu verlieren.
Abb. 2.8 zeigt ein typisches Szenario, wie die Kommunikation im HK-Labor unter Nutzung
von DICOM-Diensten stattfinden kann. Zuerst werden die Patienten- und Untersuchungsdaten per WLM an das HK-Labor gesendet. Dieses übermittelt während der Untersuchung
regelmäßig seinen aktuellen Status per MPPS und versendet am Ende eine letzte MPPSNachricht mit dem Status "Completed". Abschließend werden die Daten an das PACS
gesendet, welches für die Archivierung auf einer CD, die einem DICOM-Profil zur
Speicherung von Herzkatheterfilmen entspricht, sorgt. Aus dem PACS können die Daten per
DICOM-Query/Retrieve durch jeden Arbeitsplatz im Netzverbund abgerufen [Anz02]werden.
Die Kommunikation wird dabei immer vom medizinischen Gerät, in diesem Fall dem HKLabor, initiiert. Dies soll verhindern, dass ein Ereignis, welches von außen ausgelöst wird,
das Gerät beeinflusst und im schlimmsten Fall dem Patienten auf Grund einer Fehlfunktion
Schaden zufügt.4
3
In den genannten Profilen ist die maximale Auflösung der Objekte 512x512 Pixel für das erste und
1024x1024 Pixel für das zweite Profil bei jeweils 8bit Farbtiefe, wobei nur Graustufen angewendet
werden. Als Kompressionsverfahren ist JPEG lossless vorgeschrieben. Weiterhin muss für jedes
Film- und Bild-Objekt im DICOM directory ein 128x128 Pixel großes Übersichtsbild existieren.
4
Die einzige Ausnahme bildet hier der Dienst Storage Commitment, welcher aber nur zur Bestätigung
und Verifizierung eines vorangegangenen Datenaustauschs dient. Da dieser Dienst zur Zeit in der
Praxis in Herzkatheterlaboren nur selten anzutreffen ist und keinen Einfluss auf Art und Menge der
übertragenen Nutzdaten hat, wird hierauf an dieser Stelle nicht näher eingegangen.
32
Grundlagen
Abb. 2.8: Kommunikation im Herzkatheterlabor unter Nutzung von DICOM-Diensten.
Bei der Kopplung DICOM-konformer Systeme gibt es jedoch auch Probleme, von denen hier
einige genannt seien:
•
Fehlerhafte Umsetzung des Standards durch den Hersteller
•
Fehlerhafte Definitionen und Inkonsistenzen innerhalb des Standards
•
Unterschiedliche Interpretationen durch unterschiedliche Hersteller
•
Kommunikation zwischen verschiedenen Produkten ist nicht möglich, da diese
unterschiedliche Teilmengen des Standards implementiert haben.
In [Eic02] wird dies mit folgendem Zitat aus [Oos97] sehr gut beschrieben:
DICOM does not necessarily guarantee Interoperability. It is a major step towards
connectivity, but there are still many issues that a user needs to be aware of.
33
Grundlagen
2.6.2 HL7
HL7 (Health Level Seven) ist eine durch das ANSI (American National Standards Institute)
anerkannte SDO (Standards Developing Organization), welche für den gleichnamigen
Standard verantwortlich ist. Dessen Aufgabenbereich liegt darin, einen standardisierten
Datenaustausch von administrativen, patienten- und untersuchungsbezogenen Daten in
klinischen Institutionen zu ermöglichen. Nach [HL7] definiert sich sein Ziel als:
To provide standards for the exchange, management and integration of data that support
clinical patient care and the management, delivery and evaluation of healthcare services.
Specifically to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.
Bei der zu Grunde liegenden Organisation handelt es sich um eine "Non-ProfitOrganisation", deren Mitglieder in erster Linie aus dem Bereich der Produktanbieter und
Anwender von medizinischen Informationssystemen und Geräten kommen. Diese Mitglieder
sind in Arbeitsgruppen (Working Groups) organisiert, die die einzelnen technischen
Komitees und Special Interest Groups repräsentieren. Diese wiederum sorgen für eine
kontinuierliche Weiterentwicklung und Pflege des Standards um Aktualität, Korrektheit,
Konsistenz, Offenheit und Beachtung der Interessen ihrer Mitglieder sicher zu stellen.
Der Namensanteil Level Seven bezieht sich auf die siebte Schicht des ISO/OSI-Schichtenmodells, in welcher HL7 anzusiedeln ist. Im Gegensatz zu DICOM, welches sämtliche
Aspekte von Datenträgern und Kommunikation bis zur physikalischen Schicht beschreibt,
beschränkt sich HL7 nur auf die Anwendungsschicht. Diese umfasst Aufgaben wie
•
Sicherheitsüberprüfung
•
Verfügbarkeitsüberprüfung
•
Timing
•
Antwortverhalten und
•
Struktur der auszutauschenden Daten.
Derzeit liegt HL7 in der Version 3.0 nur als Entwurf vor. Dieser basiert auf dem so
genannten RIM (Reference Information Model), einem Objektmodell für die bildliche
Repräsentation der klinischen Daten, und XML (eXtensible Markup Language) als
Datenstruktur. Diese Version unterscheidet sich jedoch grundsätzlich von ihren Vorgängern
2.x, welche in der neuesten Fassung 2.5 im Juni 2004 verabschiedet wurde. Diese
unterschiedlichen Versionen sind nicht direkt miteinander kompatibel.
In der Praxis ist 3.0 eigentlich nicht anzutreffen, da die ältere Version weit verbreitet, erprobt
und seit Jahren im Einsatz ist und die Systemhersteller die Investition in eine neue
Kommunikationsinfrastruktur, die am Markt (noch) nicht etabliert ist, scheuen. Dies führt
aber wiederum dazu, dass beim Anwender bei Neuinstallationen Version 2.5 zum Einsatz
34
Grundlagen
kommt, da sonst die Kommunikation mit bereits vorhandenen Systemen nicht möglich wäre.
Daher ist derzeit eine flächendeckende Umstellung auf die aktuellste Fassung 3.0 nicht
abzusehen und es wird deshalb der praxisrelevante Standard HL7 Version 2.5 vorgestellt.
Jede HL7-Nachricht besteht aus Datenfeldern variabler Länge, die durch Seperatoren
(meistens das Zeichen ^ ) voneinander getrennt sind. Die Datenfelder sind in logischen
Gruppen, den so genannten Segmenten, zusammengefasst. Diese wiederum sind durch
Segmentseperatoren (meistens das Zeichen | ) voneinander getrennt. Jedes Segment
beginnt mit einem drei Zeichen langen Kürzel, welches den Typ des Segmentes beschreibt.
Folgendes Beispiel zeigt eine Aufnahmenachricht:
MSH|^~\&|Demoersteller|TestKlinik|OrdMgr|OrdCtr|20041229090131||A
DT^A01|01052901|P|2.3.1
EVN|A01|200105290900||||200105290900
PID|||56782445^^^UAReg^PI~99985^^^USSSA^SS||Mustermann^Peter^^||1
9600101|M||C|Testweg 7^^Musterstadt^Niedersachsen^12344^^H|||||||
0105I30001
PV1||I|W^389^1^UABH^^^^3||||5^Doktor^Anna^J^^^Dr.^^^UAMC^L||6^Arz
t^Karl^X^^^Dr.^^^UAMC^L|MED|||||A0||7^Müller^Jürgen^^^^Dr.^^^UAMC
^L
OBX|1|NM|HT^HEIGHT^99LOC1||1.71|m^meter^ANSI+|||||F
OBX|2|NM|WT^WEIGHT^99LOC1||75|kg^kilogramm^ANSI+|||||F
Der genaue Aufbau der Nachrichten kann im Standard eingesehen werden, hier sollen nur
die wichtigsten Eigenschaften der Beispielnachricht, welche aus sechs Segmenten besteht,
erläutert werden:
•
Ein MSH-Segment, der Message Header, welches jede Nachricht enthalten muss.
Wichtige Informationen hierin sind die verwendeten Trennzeichen (^~\&), der
Ersteller (Demoersteller), der Erstellungszeitpunkt (29.12.2004, 09:01:31 Uhr) und
der Nachrichtentyp (ADT^A01), der hier eine stationäre Aufnahme bezeichnet.
•
Ein EVN-Segment zur Übermittlung administrativer Daten in ADT-Nachrichten.
•
Ein PID-Segment, welches die Patientendaten enthält, wie z. B. Patientennummer
(56782445), Name (Peter Mustermann), Geburtsdatum (01.01.1960) und Anschrift
(Testweg 7, 12344 Musterstadt).
•
Ein PV1-Segment, welches die Aufnahmedaten, wie z. B. den behandelnden Arzt
(Anna Doktor) und Fallnummer (67890) enthält.
•
Zwei OBX-Segmente, die Messwert und Untersuchungsergebnisse, in diesem Fall
Größe und Gewicht, enthalten.
35
Grundlagen
Für viele in der Klinik gängige Transaktionen gibt es eigene Nachrichtentypen, z. B.
•
ADT für die Patientenaufnahme, -verlegung und -entlassung
•
ORM für Untersuchungsanforderungen
•
BAR zur Übermittlung von Diagnosen und Therapien, in Deutschland meistens in
Form der gesetzlich vorgeschriebenen ICD- (International Classification of
Diagnosis) und OPS301- (Operationenschlüssel nach § 301 des Sozialgesetzbuchs)
Codes (vgl. [IEK03])
•
MDM, ORU und UDM zur Übermittlung von Befunden in unterschiedlichen Formaten,
wie z. B. Transfer von reinem Text oder Verweise auf externe Dokumente im
Dateisystem
•
DFT zur Übermittlung von abrechnungsrelevanten Informationen
•
ACK für die Bestätigung, ob eine Nachricht erfolgreich oder nicht verarbeitete wurde.
Daneben gibt es noch ein Kommunikationsmodell um Anfragen zu stellen (Query/Retrieve),
welches jedoch in der Praxis kaum zum Einsatz kommt. Zusätzlich kann jede Nachricht um
so genannte Z-Segmente erweitert werden, um zusätzliche Informationen, die nicht durch
den Standard abgedeckt sind, zu übermitteln.
In der Praxis treten ähnliche Probleme wie bei der Kopplung DICOM-konformer Systeme
auf. Im Gegensatz zu DICOM treten Schwierigkeiten aber viel häufiger auf, was unter
anderen folgende Gründe hat:
•
Ein Conformance Statement ist bei HL7-kompatiblen Systemen nicht gefordert.
•
Die Semantik vieler Felder ist nur unzureichend definiert.
•
Der Standard basiert auf der Struktur des amerikanischen Gesundheitswesens, was
in Deutschland dazu führt, dass einige Informationen nur in Z-Segmenten übermittelt
werden können. Deren proprietäre Inhalte können aber ohne Abstimmung zwischen
den Systemherstellern nicht ausgetauscht und interpretiert werden.
•
Es existieren eine Reihe einzelner Felder, deren Kombination unterschiedlicher
Interpretationsmöglichkeiten viel mehr Varianten und somit Fehlinterpretationen
zulässt, als dies bei DICOM der Fall ist.
Zusammenfassend gilt hier dasselbe, was bereits im letzten Abschnitt für den DICOMStandard festgestellt wurde: Interoperabilität zwischen zwei HL7-konformen Systemen ist
nicht automatisch gewährleistet, jedoch ist HL7 ein großer Schritt in diese Richtung.
36
Grundlagen
2.6.3 XDT
Bei XDT handelt es sich um eine Gruppe von Standards, die wie HL7 die Struktur der
auszutauschenden Daten definiert. Im Jahre 1987 verabschiedete die KBV (Kassenärztliche
Bundesvereinigung) unter dem Namen ADT (Abrechnungsdatentransfer) den ersten
Vertreter der XDT-Gruppe, dessen Aufgabe die elektronische Übermittlung der
quartalsweise anfallenden Abrechnungsdaten niedergelassener Ärzte an die KV
(Kassenärztlichen Vereinigung) war.
Ziel war zunächst eine einheitliche, einfache, effiziente und kostengünstige Lösung zur
Übermittlung der Abrechnungsinformationen zu schaffen. 1989 erreichte ADT nach einigen
Modifikationen einen für die Praxis akzeptablen Stand. Jedes Softwareprodukt, das
Abrechnungsinformationen an die KV übertragen möchte, muss im Rahmen des ADTZulassungsverfahren seine Abrechnungstauglichkeit prüfen lassen. Erst wenn das
entsprechende Zertifikat verliehen wurde, darf eine "Diskettenabrechnung" mit der Software
durchgeführt werden.
Da der Aufbau des ADT aus der Mitte der 80er Jahre stammt, handelt es sich um einen
einfachen, zeilenorientierten Dateistandard. Jede Zeile beginnt mit einer drei Byte langen
Längenbeschreibung, gefolgt von einer vier Byte langen Feldkennung, welche die Semantik
des Feldes angibt. Danach folgt der eigentliche Inhalt des Felds, welcher durch die zwei
Bytes CR (Carriage Return, ASCII-Wert 13) und LF (Line Feed, ASCII-Wert 10)
abgeschlossen wird.
Im Folgenden entstand zunehmend der Wunsch, Daten zwischen verschiedenen
Informationssystemen (auch über die Grenzen von medizinischen Institutionen hinweg) und
medizinischen Geräten in Praxen auszutauschen. Hierfür wurde der ADT modifiziert und es
entstanden die Standards BDT (Behandlungsdatentransfer), GDT (Gerätedatentransfer) und
LDT (Labordatentransfer), welche grundsätzlich denselben internen Aufbau haben, sich
aber in zwei wichtigen Punkten vom ADT unterschieden:
•
Es sind Felder mit anderer Semantik, repräsentiert durch andere Kennungen,
enthalten, um den speziellen Anforderungen für das Einsatzgebiet gerecht zu
werden
•
Programme, die diesen Standard nutzen, müssen nicht über ein Zulassungszertifikat
verfügen.
Der vierstellige Code, der die Feldbezeichnung repräsentiert, wurde im folgenden Beispiel
hervorgehoben um die Lesbarkeit zu vereinfachen. Zu beachten ist, dass die Längenangabe
alle Bytes einer Zeile enthält, also auch den Code, die Längenangabe und die beiden
Zeilenbegrenzungszeichen. In der gedruckten Version sind die letzten beiden Zeichen CR
und LF nicht sichtbar, weswegen die Längenangabe immer zwei Zeichen zu kurz wirkt. Die
Angaben hinter den beiden Schrägstrichen "//" gehören nicht zu der GDT-Datei. Sie leiten
Kommentare ein, die die semantische Bedeutung des vierstelligen Codes beschreiben.
37
Grundlagen
Das folgende Beispiel zeigt einen Ausschnitt einer GDT-Datei, die von einem EKG-Gerät
nach Ende der Untersuchung übermittelt wurde und Untersuchungsergebnisse enthält:
01380006310
014810001173
014921801.00
0093000
01031102
0123622165
0123623068
0148402EKG04
017843220072004
0158439115546
0228410Aufnahmedauer
014842002:00
0148421HH:MM
0188410Total QRS
01384209330
0098421
0168410Min. HF
011842054
0138421/min
...
// Art des Datensatzes
// Gesamte Anzahl der Bytes in der Datei
// Version
// Start des Datenblockes
// Identifikationsnummer des zugehörigen Patienten
// Größe in cm
// Gewicht in kg
// Art der Untersuchung
// Erstellungsdatum: 20.07.2004
// Erstellungsuhrzeit: 11:55.46
// Bezeichnung des folgenden Messwertes
// gemessener Wert
// Einheit
// Bezeichnung des folgenden Messwertes
// gemessener Wert
// Einheit
// Bezeichnung des folgenden Messwertes
// gemessener Wert
// Einheit
In diesem Beispiel lässt sich gut der einfache Aufbau erkennen, in welchem es aber gewisse
Regeln gibt. So muss z. B. der Header immer die Felder "8000", "8100" und "9218"
enthalten oder die Übermittlung von Messwerten immer aus dem Tripel "8410", "8420" und
"8421" bestehen. Dies kann detailliert unter [XDT] bei der KBV eingesehen werden.
Der Vorteil des XDT-Standards liegt in seinem einfachen, unkomplizierten Aufbau, welcher
bei der Kopplung von Systemen selten Probleme bereitet. Nachteile liegen unter anderen in
der geringen Flexibilität (z. B. fehlende Unterstützung von Binärobjekten), der Längenbeschränkung der Textzeilen und der reinen Ausrichtung auf das Dateisystem. Dadurch
muss ständig ein Verzeichnis auf neu eingehende Dateien (Dateipolling) überprüfend
betrieben werden und Mechanismen wie "Query/Retrieve" sind nicht umsetzbar.
In der Praxis wurde durch die KBV der flächendeckende Einsatz von XDT in deutschen
Arztpraxen erzwungen. Darüber hinaus hat er aber keine weitere nennenswerte Verbreitung,
weder in anderen Institutionen des Gesundheitswesens noch anderen Branchen oder dem
Ausland, gefunden. Da Ambulanzen in Krankenhäusern mit der KV über ADT abrechnen
müssen, gibt es unterdessen viele KIS-Hersteller, die eine XDT-Schnittstelle bieten.
Weiterhin werden medizinische Geräte, wie EKGs, in Praxen und Kliniken gleichermaßen
eingesetzt. Da der Hauptumsatz mit diesen kleineren Geräten im niedergelassenen Bereich
erfolgt, besitzen diese Geräte häufig nur eine GDT-Schnittstelle. Daher verfügen einige
klinische Informationssysteme auch über die passende Schnittstelle, um diese Geräte
anzubinden. Somit spielt XDT auch für klinische Informationssysteme eine gewisse Rolle.
38
Grundlagen
2.6.4 IHE
In klinischen Umgebungen müssen häufig unterschiedliche Geräte und IT-Lösungen, die
über unterschiedliche Schnittstellen verfügen, gekoppelt werden. Dies potenziert meist die
Schwierigkeiten, da nicht nur die bereits angesprochenen Kommunikationsprobleme gelöst
werden müssen, sondern zusätzlich korrespondierende Felder innerhalb der verschiedenen
Standards aufeinander abgebildet werden müssen. Dies ist insbesondere bei ID-Feldern
notwendig. Hier kann es zu weiteren Inkompatibilitäten z. B. bei Feldlängen oder deren
Datentypen kommen.
Im Jahr 1998 wurde in den USA durch den amerikanischen Radiologenverbund und die
HIMSS (Healthcare Information and Management Systems Society), einer Vereinigung der
Anbieter medizinischer Informationssystemanbieter, die IHE-Initiative (Integrating the
Healthcare Enterprise), gegründet. Eines der vorrangigen Ziele der IHE ist die Verbesserung
des Datentauschtauschs zwischen IT-Systemen im Gesundheitswesen. Eine der wichtigsten
Aufgaben ist es hier, Richtlinien und Vorgehensweisen zu schaffen, die eine reibungslose
Kopplung zwischen Systemen, die medizinische IT-Standards verwenden, gewährleisten
sollen (vgl. [IHE]). In den letzten Jahren hat die IHE eine internationale Bedeutung
gewonnen, die auch die europäischen und japanischen Anforderungen an das
Gesundheitswesen berücksichtigt.
Die folgende kurze Vorstellung der Aktivitäten der IHE stammt in erster Linie aus [WER04],
[Eic03] und [IHE]. Weiterführende Informationen und Literatur sind dort zu finden.
Grundlage des Standards bildet das technische Rahmenwerk (technical framework),
welches IT-Systeme und die wichtigsten Interaktionen zwischen diesen definiert. Zurzeit ist
es in die vier Bereiche IT-Integration, Radiologie, Labor und Kardiologie aufgeteilt. Innerhalb
dieser werden einzelne Anwendungsszenarien durch sog. Integrationsprofile beschrieben. In
diesen Profilen gibt es Akteure, welche den beteiligten IT-Systemen oder Modalitäten
entsprechen, sowie Transaktionen, die die Interaktionen zwischen den Akteuren
modellieren.
Dabei stützt sich die IHE auf existierende Standards, insbesondere auf HL7 und DICOM,
und versucht für diese Klarheit für unterschiedlich interpretierbare Definitionen und
Abbildungen zum Austausch von Informationen, die in beiden Domänen verwaltet werden,
zu schaffen. Zusätzlich wird die Vielzahl an Auswahlmöglichkeiten, die es an einigen Stellen,
sowohl bei der Art der Kommunikation (verwendete Protokolle oder genutzte Segmente im
Nachrichtenaufbau) als auch bei den ausgetauschten Inhalten (verwendete Attribute), gibt,
auf ein Minimum reduziert.
Da die IHE am Anfang in erster Linie im Bereich der Radiologie tätig war, entstammen
dieser auch die meisten der bisher verabschiedeten Integrationsprofile. Viele von diesen
können aber auch auf andere, artverwandte medizinische Fachbereiche angewendet
werden.
39
Grundlagen
Als Beispiel sind hier drei Integrationsprofile aufgeführt.
•
Scheduled Workflow (Geplanter Arbeits- und Informationsfluss). In diesem Profil
werden beteiligte Systeme und auszutauschende Nachrichten definiert, die sich mit
Organisation und Vereinheitlichung des Datenflusses innerhalb der Abteilung
beschäftigen. Bei den Systemen sind insbesondere der sog. "Order Filler", welcher
Daten zu einem angeforderten Arbeitsauftrag liefert, und die Modalität, die eine
Auftragsliste anfordert, zu nennen. Dies reicht von der Patientenaufnahme und der
Weitergabe angeforderter Daten an Subsysteme und Modalitäten bis zur
Speicherung erstellter Bilder und Filme in einem PACS. Dazu sind sowohl DICOMDienste wie WLM oder Storage als auch HL7-Nachrichten sowie ADT notwendig.
•
Patient Information Reconciliation (Korrektur von Patientendaten). Stellt ein
Mitarbeiter fest, dass Daten falsch oder unvollständig erfasst wurden, so korrigiert er
diese zunächst in dem System, zu dem er gerade Zugang hat. Wünschenswert ist
nun, dass diese Korrekturen automatisch an alle klinischen Informationssysteme im
Netzverbund weitergereicht werden. Wie dies zu geschehen hat, definiert dieses
Integrationsprofil, welches sich in erster Linie auf HL7-Nachrichten abstützt.
•
Charge Posting (Übermittlung von Abrechnungsnachrichten). Hier wird
beschrieben, wie abrechnungsrelevante Daten von einem Informationssystem an ein
Abrechnungssystem übermittelt werden.
Speziell für die Kardiologie wurden bisher folgende drei Integrationsprofile definiert:
•
Arbeitsfluss im Herzkatheterlabor
•
Arbeitsfluss in der Echokardiographie und
•
Zugriff auf EKG-Daten.
Da die Verabschiedung dieser Profile aber erst Ende 2004 erfolgte, liegen zu ihrer
Anwendung in der Praxis und Unterstützung seitens Informationssystemherstellern noch
keine Informationen vor. Demonstrationen erster Umsetzungen dieser kardiologischen
Integrationsprofile werden für den Mitte 2005 stattfinden Connect-A-thon erwartet. Bei dieser
jährlichen, 2001 erstmals in Europa durchgeführten Veranstaltung treffen sich Hersteller von
medizinischen Geräten und Informationssystemen, die Mitglieder der IHE-Initiave sind, und
können die Interoperabilität ihrer Systeme für beliebige Integrationsprofile in einem
möglichst realitätsnahen Testszenario überprüfen.
Diese Veranstaltung ist nicht für Kunden zugänglich, um den Firmen Freiheiten und offene
Kommunikation in einem "geschützten Raum" zu gewähren. Die Firmen testen hier neue
Technologien, die nur teilweise den Produktstatus erreichen oder sogar noch über Fehler
verfügen. Hier ist es deshalb nicht erwünscht, dass Kunden so detaillierten Einblick in die
Produktentwicklung erhalten.
40
Grundlagen
Es werden aber Pressemitteilungen zum Connect-A-thon herausgegeben und Vorführungen
IHE-kompatibler Systeme im Rahmen anderer Großveranstaltungen durchgeführt. Dies
geschieht meist bei medizinischen Kongressen wie dem ESC-Kongress (European Society
of Cardiology) oder ECR (European Congress of Radiology). Diese Demonstrationen sollen
Vertrauen beim Kunden schaffen und den Nutzen der IHE-Initiative zeigen.
Zusammenfassend kann gesagt werden, dass die IHE eine praxisorientierte Initiative
darstellt, deren Aktivitäten die Interoperabilität medizinischer Geräte und Informationssysteme im Produktionsbetrieb vereinfachen soll und teilweise sogar erst ermöglicht. Bisher
liegt aber nur für den Bereich der Radiologie eine umfassende Menge an Profilen und eine
daraus resultierende Umsetzung in der Praxis vor. Die hier weitgehend positiven
Rückmeldungen von Herstellern und Anwendern geben aber Mut, auch in anderen
klinischen Bereichen IHE-Profile zu definieren und diese als Grundlage für die Kopplung von
Systemen zu nutzen.
Es gibt darüber hinaus mit XDS (Cross-Enterprise Clinical Documents Sharing) erste
Überlegungen den Austausch klinischer Dokumente über die Grenzen medizinischer
Einrichtungen hinweg zu ermöglichen. Veröffentlichungen zur Umsetzung dieser Idee
werden für den Connect-A-thon 2005 erwartet.
2.7 Kardiologische Abteilungsinformationssysteme in
Deutschland
Unter der Bezeichnung eines kardiologischen AISs werden in erster Linie Systeme, die eine
Dokumentation im HK-Labor ermöglichen, zusammengefasst. Dies liegt am hohen
Stellenwert der medizinischen Eingriffe, die im HK-Labor durchführt werden. Beim
Herzkatheter und der EPU handelt sich um aufwändige, komplexe medizinische Eingriffe,
die derzeit die wichtigsten diagnostischen und therapeutischen Behandlungsmethoden in
der Kardiologie sind. Im Vergleich zu anderen medizinischen Verfahren in der Kardiologie
sind Behandlungen im HK-Labor auch relativ kostspielig. Dadurch kommt dem Einsatz von
AISen im HK-Labor innerhalb der Kardiologie die höchste Bedeutung zu. Diese können in
zwei Gruppen eingeteilt werden:
1. Systeme, die primär für die Dokumentation im HK-Labor entwickelt und ausgelegt
sind. Hier wird versucht möglichst viele Funktionen, die aber teilweise sehr speziell
sind und somit nur im HK-Labor benötigt werden, anzubieten, die den Routinebetrieb
im Labor erleichtern sollen.
2. Erweiterungen von KISen, häufig unter Verwendung von Maskengeneratoren. Diese
sind eigentlich nur durch den Anwender selber erstellte Erfassungsmasken mit
geringer oder gar keiner eigenständigen Funktionalität.
41
Grundlagen
Der erste Ansatz ist der, der aus Sicht des medizinischen Personals wünschenswert ist, da
diese Systeme gezielt auf die Belange der Anwender zugeschnitten sind. Der zweite hat
aber auch einige Vorteile, denn zunächst ist er kostengünstiger, da keine zusätzlichen
Produkte angeschafft werden müssen, sondern das bereits im Haus eingesetzte KIS genutzt
wird. Weiterhin muss nicht über Schnittstellen zum KIS nachgedacht werden, da es sich nur
um eine Erweiterung des KISs handelt, deren Einbindung in klinische IT-Infrastruktur per se
gewährleistet ist. Schließlich ist der administrative Aufwand für die EDV-Abteilung der Klinik
zumeist geringer. Diese Lösungen sind somit insbesondere für kleine klinische Abteilungen,
welche wenige Eingriffe im Herzkatheterlabor durchführen, interessant, dem gegenüber
steht jedoch häufig eine geringere Produktivität durch das medizinische Personal.
Auf Seiten der kommerziellen Spezialsysteme, also der Systemgruppe 1, gibt es derzeit in
Deutschland folgende Produkte:
•
CATHMASTER von der Fa. Meierhofer
•
Carddas Centricity von GE Medical Systems
•
cardioBase von der Fa. Schwarzer (dabei handelt es sich um GO-Kard von OFFIS,
welches von Schwarzer in Lizenz vertrieben wird)
•
CLAIM von der Fa. CLAIM GmbH
•
Metek von der Fa. Metek-Lehmann GmbH.
Über die exakte Verteilung von Installationen dieser Systeme in Deutschland liegen dem
Autor trotz intensiver Recherche keine verlässlichen Zahlen vor. Die im Folgenden vorgestellten Zahlen basieren auf eigenen Schätzungen und Rückfragen bei Vertriebsmitarbeitern, können aber als realistisch angesehen werden. Zunächst kann davon ausgegangen
werden, dass nur etwa die Hälfte aller Herzkatheterlabore über ein spezialisiertes AIS für
das HK-Labor verfügen. Die restlichen Kardiologien dokumentieren entweder mit
Erweiterungen von KISen oder mit Werkzeugen, die nur die gesetzlichen Anforderungen
erfüllen, oder mit Eigenentwicklungen. Diese Dokumentation wird fast immer durch eine
Befundschreibung mit einer gängigen Textverarbeitung, zumeist Microsoft Word, ergänzt.
Für die übrigen HK-Labore, die kommerzielle Lösung nutzen, gilt etwa folgende Verteilung:
42
•
Ca. 30 % verwenden cardioBase / GO-Kard
•
Ca. 30 % verwenden Carddas Centricity
•
Ca. 16 % verwenden Metek
•
Ca. 8 % verwenden CLAIM
•
Ca. 8 % verwenden CATHMASTER
•
Die restlichen ca. 8% entfallen auf weitere, selten anzutreffende kommerzielle
Systeme wie z. B. CardioLogica von Philips.
Grundlagen
Bemerkenswert ist hier der große Anteil von Kliniken, die kein spezialisiertes AIS einsetzen.
Dies kann darauf zurückzuführen sein, dass es noch einige sehr "konservative" Chefärzte
gibt, die diesen System skeptisch gegenüber stehen, oder dass die IT-Lösungen (noch) zu
teuer und keine entsprechenden Investitionsmittel verfügbar sind. Es liegt aber auch nahe
zu vermuten, dass der Anwender nicht vom Preis-/Leistungsverhältnis der am Markt
verfügbaren Produkte überzeugt ist.
Eine Umfrage unter 123 deutschen Herzkatheterlaboren (vgl. [WV02]) ergab, dass alle
Anwender Kritikpunkte bzgl. des von ihnen eingesetzten Systems anbrachten. Die
Ergebnisse sind in Tab. 2.1 zusammengefasst.
Kritikpunkt
Anteil
Kritikpunkt
Anteil
Fehlende Schnittstelle
29 %
Unmodern
9%
Bedienerunfreundlich
14 %
Hoher Zeitaufwand
7%
System nicht stabil
9%
Fehlende Bilddokumentation
5%
Befunderstellung schlecht
9%
Unflexibel
5%
Fehlende Statistik
9%
Mehrfacherfassung vieler Eingaben
3%
Tab. 2.1:
Hauptkritikpunkte der Anwender an dem in ihrem Labor etablierten System nach [WV02].
Unter Anteil ist der prozentuale Anteil der Anwender angegeben, die diesen
Hauptkritikpunkt nannten. Insgesamt führten alle Anwender (also 100 %) mindestens
einen Kritikpunkt an.
Um eine steigende Akzeptanz und Zufriedenheit beim Anwender zu erreichen, sind hier
offenbar noch FuE-Anstrengungen notwendig, zu der die vorliegende Arbeit einen wichtigen
Beitrag leisten möchte. Bevor dieser Beitrag konzeptionell und implementierungstechnisch
ab Kapitel 4 vorgestellt wird, beschreibt Kapitel 3 in der notwendigen Detaillierung
medizinische Grundlagen sowie Aufbau und Ablauforganisation einer klinischen
kardiologischen Fachabteilung.
43
Die klinische kardiologische Fachabteilung
3 Die klinische kardiologische Fachabteilung
In diesem Kapitel wird die Anwendungsumgebung einer typischen klinischen
kardiologischen Abteilung vorgestellt. Es wird ein Überblick über Organisationsstrukturen,
verwendete medizinischen Geräte, Arbeitsabläufe und angewandte therapeutische und
diagnostische Verfahren gegeben. Zusätzlich sollen die Einordnung der Kardiologie im
klinischen Kontext und in der Behandlungskette von Herzerkrankungen herausgearbeitet
werden.
Dazu werden zunächst auf informeller Ebene die für ein kardiologisches Informationssystem
relevanten Ressourcen und deren Rolle im klinischen Arbeitsprozess vorgestellt. Diese sind
insbesondere
•
Personal, welches in Gruppen zusammengefasst werden kann,
•
Räumlichkeiten,
•
Inventar, insbesondere medizinische Geräte und Materialien,
•
Verbrauchsmaterialien,
•
Arbeitsabläufe bei der Durchführung von medizinischen Maßnahmen (dies beinhaltet
administrative, therapeutische und diagnostische Verfahren).
Deren Zusammenhang wird unter Verwendung von Flussdiagrammen modelliert.
Die Auswahl einer kardiologischen Abteilung wurde als anspruchsvolles Beispiel einer
klinischen Umgebung in dieser Arbeit aus folgenden Gründen getroffen:
•
Eigene Expertise: Der Autor kann auf eine mehrjährige Arbeitserfahrung in einer
großen kardiologischen Abteilung eines Akutkrankenhauses der regionalen
Vollversorgung zurückgreifen. Dieses Fachwissen wird durch die aktive Mitarbeit in
einem großen Projekt ([CTKR99], [CKRJ99], [Cla00]), welches die Entwicklung von
Software für Kardiologien zum Inhalt hat, abgerundet. Im Rahmen dieses Projekts
wurden auch enge Kontakte zu kardiologischen Abteilungen anderer Krankenhäuser
geknüpft, wodurch eine breiter abgesicherte Sicht auf die Tätigkeiten einer
kardiologischen Abteilung ermöglicht wird. Dadurch liegt ein fundiertes Verständnis
für die zum Einsatz kommenden Ressourcen und Arbeitsabläufe in der Kardiologie
vor, welches für die praxisrelevante und detaillierte Analyse und Modellierung der
Geschäftsprozesse unabdingbar ist.
45
Die klinische kardiologische Fachabteilung
•
Gesundheitspolitische Relevanz: Erkrankungen des Herz-Kreislaufsystems stellen
mit knapp 50 % die häufigste Todesursache in Deutschland (vgl. [SBD04]) dar. Da
die Behandlung dieser Erkrankungen derzeit nur mit teuren und aufwendigen
Verfahren und Medikamenten möglich ist, entstehen hier, verglichen mit anderen
Krankheitsbildern, die höchsten Kosten im Gesundheitswesen. Eine Rationalisierung
bei Diagnostik- und Therapieverfahren von Herzerkrankungen ist also aus
medizinischer und ökonomischer Sicht besonders wünschenswert.
•
Heterogenität: In der Kardiologie kommen hinreichend unterschiedliche Verfahren
zum Einsatz. Diese reichen von der ganz einfachen medikamentösen Therapie bis
zum Einsatz modernster Technik im Herzkatheterlabor. Es finden sich hier komplexe,
unterschiedliche Arbeitsabläufe die auch auf Ressourcen anderer Abteilung wie z. B.
Labor oder Radiologie angewiesen sind.
•
Qualitativ und quantitativ interessante Datensammlungen: Die unterschiedlichen
Diagnostik- und Therapieverfahren liefern große Datenmengen in verschiedenen
Formaten. Diese umfassen sowohl alphanumerische als auch multimediale Inhalte.
Insbesondere Filme und Bilder stellen einen zentralen Bestandteil der
kardiologischen Diagnostik dar. Die Archivierung und Bereitstellung von
medizinischen Informationen ist in der Kardiologie unverzichtbar und muss in
besonderem Maße als Teil des Geschäftsprozesses berücksichtigt werden.
•
IT-Akzeptanz: Nach der Radiologie und dem Labor ist die Kardiologie führend bei
der Einführung von standardisiertem Datenaustausch zwischen unterschiedlichen ITSystemen und Modalitäten. Dies zeigt sich unter anderem daran, dass für die
Kardiologie bereits ein IHE-Profil entworfen wurde [IHE] und hier alle medizinischen
Großgeräte (Herzkatheterlabore und Ultraschallmaschinen) mit digitaler DICOMkompatibler Schnittstelle zur Bereitstellung von Untersuchungsdaten verfügbar sind.
3.1 Einbettung in die Klinik
Die moderne invasive Kardiologie hatte ihre Anfänge 1929 mit der ersten Herzsondierung
durch Forßmann im Klinikum Eberswalde. Bei diesem Selbstversuch führte er einen
Katheter durch die Arteria Radialis (große Armarterie) in die Aorta und von dort in die linke
Herzkammer. Dann begab er sich zu einem ein Stockwerk tiefer gelegenen Röntgengerät,
injizierte sich selbst durch den Katheter ein für Röntgenstrahlen undurchlässiges
Kontrastmittel und konnte so mit einer Röntgenaufnahme die Umrisse seines Herzens und
den Weg des Katheters aufzeichnen. Auf ähnliche Weise wird noch heute in der modernen
Kardiologie das Herz dargestellt.
46
Die klinische kardiologische Fachabteilung
Jedoch wurde dieses bahnbrechende Ereignis durch die Mediziner der damaligen Zeit nicht
gewürdigt, so dass erst wieder 1958 mit der ersten Schrittmacherstimulation eine gezielte
Behandlung des Herzens stattfand. Insbesondere in den 60er Jahren wurden die
Grundlagen der modernen Kardiologie entdeckt und die Ideen von Forßmann wieder
aufgegriffen. Eine kurze Zusammenfassung der Geschichte der modernen Kardiologie nach
[Hen03] kann Tab. 3.1 entnommen werden.
Jahr
Ereignis
1929
Erste Herzsondierung durch Forßmann
1953
Entwicklung der Echokardiografie durch Edler, Hertz und Effert
1958
Erste Schrittmacherimplantation durch Senning
1959
Entwicklung der Streptokinase durch die Firma Behring
1961
Entwicklung der Wiederbelebungstechniken durch Kouwenhoven
1962
Entwicklung der Röntgen-Kinofilm-Technik: Kard-Angiografie durch Siemens und Philips,
Einführung der Kathetertechnik nach Sones und Judkins (1969) wie sie heute noch als
Standardmethode zur Anwendung kommen
1964
Erfindung der ß-Rezeptorblocker durch Black
1977
Erste Ballondilatation in Zürich durch Grüntzig und Kaltenbach
1980
Implantation des ersten Defibrillators
1986
Einsatz des ersten Stents in Lausanne durch Sigwart
2000 ff.
Gentherapie
(Gefäßwachstum,
Stammzellen),
medikamentöse
Begleittherapie
(Blutplättchen- Verklebungshemmung), Qualitätskontrolle, Betonung der präventiven
(vorbeugenden) Aufgabe der Kardiologie, beschichtete Stents, Stentbestrahlung
Tab. 3.1:
Geschichte der modernen Kardiologie nach [Hen03]
Die Kardiologie ist ursprünglich keine eigene Fachdisziplin gewesen, sondern hat sich als
Spezialgebiet aus der Inneren Medizin heraus entwickelt. Da die Diagnostik und Therapie
des Herz-/Kreislaufsystems einen immer höheren Stellenwert, insbesondere bei der
Behandlung von älteren Patienten, einnimmt und mit komplexen, technisch hoch
entwickelten Maschinen und Medikamenten durchgeführt wird, ist die Kardiologie
unterdessen eine eigenständige Fachdisziplin. Zwar durchläuft der Mediziner vor seiner
Weiterbildung zum Kardiologen zunächst die komplette Ausbildung der Inneren Medizin,
darf aber nur nach einer mehrjährigen zusätzlichen Ausbildung und Ablegen einer eigenen
Prüfung die Bezeichnung "Facharzt für Kardiologie" tragen.
Es ist besonders hervorzuheben, dass diese hohe Spezialisierung für die Behandlung von
nur einem einzigen Organ notwendig ist, was wiederum den Stellenwert und die Komplexität
der angewandten therapeutischen und diagnostischen Verfahren unterstreicht. Gerade hier
ist daher eine enge Zusammenarbeit aller Beteiligten in einem reibungslosen Arbeitsablauf
notwendig. Ein solcher Arbeitsablauf ist aber häufig nicht ein einfach planbarer, linearer
47
Die klinische kardiologische Fachabteilung
Prozess, da im klinischen Umfeld u. a. folgende störende Faktoren berücksichtigt werden
müssen:
•
Vorher unbekannte Diagnosen, die erst während der Behandlung erkannt werden
•
Unvorhersehbare Ereignisse, die zu Komplikationen führen
•
Nebenwirkungen von medizinischen Verfahren
•
Notfälle.
Diese unvorhersehbaren Ereignisse gehören im klinischen Alltag zur Normalität und müssen
daher bei der Modellierung der Arbeitsabläufe besonders berücksichtigt werden. Dabei kann
es nicht nur zu abweichenden Abläufen kommen, sondern auch zu kompletten Abbrüchen
der Behandlung, spontanen Änderungen des angewandten Verfahrens oder der
Unterbrechung von laufenden Therapien, um Notfälle zu versorgen und dann den
Routinebetrieb wieder aufzunehmen.
Ein weiterer schwer kalkulierbarer Faktor ist die Abhängigkeit von angeforderten externen
Leistungen
unter
zeitlichen
Rahmenbedingungen.
Bei
besonders
schweren
Krankheitsbildern, wie sie in der Kardiologie z. B. beim akuten Herzinfarkt zum Alltag
gehören, muss der verantwortliche Arzt entscheiden, ob genug Zeit für eine abklärende
Voruntersuchung wie z. B. das Erstellen eines Blutbildes durch das Labor bleibt. Ist der Fall
so schwer, dass akuter Handlungsbedarf besteht, muss ggf. ohne Informationen, die unter
normalen Umständen vorlägen, die Behandlung eingeleitet werden.
In jeder klinischen Abteilung sind zur Durchführung der meisten medizinischen Maßnahmen
nur Personengruppen mit der notwendigen Qualifikation und Berechtigung zugelassen.
Diese sind zum einen durch Ausbildung und Stellung innerhalb der Hierarchie in der
Abteilung vorgegeben, zum anderen aber auch von der Vertretungsregelung. So übt ein
leitender Oberarzt, der Vertreter des Chefarztes ist, ggf. die Funktionen des Chefarztes in
dessen Abwesenheit aus. Dadurch kann er z. B. in dieser Zeit eine Ambulanzberechtigung
haben, dort Behandlungen und Liquidationen durchführen, obwohl er selbst durch die KV
keine Zulassung zur Abrechnung von Leistungen hat.
Personen und klinische Ressourcen müssen im Rahmen der Behandlung eines Patienten
geeignet koordiniert werden. Daher stellen Kommunikation und Kooperation einen zentralen
Aspekt bei der Qualität der Behandlung dar. Hinzu kommt noch, dass häufig Ressourcen
anderer Abteilungen angefordert werden müssen. Diese so genannten konsiliarischen
Leistungen müssen teilweise "dynamisch" in den Arbeitsablauf integriert werden, da im
Vorfeld nicht immer bekannt ist, was wann benötigt wird. Dies wiederum liegt daran, dass
sich Gesundheitszustand und Heilungsfortschritt eines Patienten nicht exakt vorhersehen
lassen. Daher sind Kommunikation und ständiger Informationsaustausch eine der
wichtigsten Voraussetzungen bei der Behandlung des Patienten, um die nächsten Schritte
innerhalb der Behandlungskette an den aktuellen Zustand des Krankheitsbildes
48
Die klinische kardiologische Fachabteilung
anzupassen. Dies muss soweit flexibel gehalten werden, dass die
Behandlungskette spontan umgestellt und dynamisch neu gestaltet werden kann.
gesamte
Grundlage für den Informationsaustausch bildet die Erfassung der während einer
medizinischen Maßnahme anfallenden Informationen. Dies ist in Deutschland auch durch
den Gesetzgeber geregelt. Die Dokumentation ist eine zu erfüllende Pflicht gegenüber der
KV und den Krankenkassen, wobei die Aufzeichnungen so umfangreich sein sollten, dass
sowohl der KV als auch den Krankenkassen eine Überprüfung der ordnungsgemäßen
Leistungserbringung möglich ist (siehe §§ 275, 295 in [SGBV]). Darüber hinaus ist die
Erfassung und Übermittlung fest definierter Daten zur Qualitätssicherung gesetzlich
vorgeschrieben (siehe § 108 in [SGBV]). Zusätzlich definiert die Berufsordnung der Bundesärztekammer die Dokumentationspflicht gegenüber dem Patienten (siehe § 10 in [BÄK]).
Die geschilderten Dokumentationsaufgaben werden vom medizinischen Personal häufig als
lästige Pflicht angesehen, die Ärzte und Pflegepersonal von ihrer tatsächlichen Arbeit am
Patienten fern hält. Tatsächlich nimmt diese Arbeit nach einer internen Studie der Klinikum
Oldenburg gGmbH als reine Arbeit am Schreibtisch ohne Kontakt zum Patienten täglich pro
Arzt mehr als eine Stunde in Anspruch. Dazu kommt die Zeit, die während Untersuchungen
und Patientengesprächen zur Dokumentation verwendet werden muss. Diese kann mit ca.
30 % der Gesamtzeit bei der Patientenaufnahme, Visite und Übergabe veranschlagt und
somit auf etwa eine weitere Stunde pro Tag abgeschätzt werden. Insgesamt verbringt ein
Arzt mindestens ein Viertel seiner Arbeitszeit nur mit der Dokumentation seiner Tätigkeit.
Insbesondere seit Umstellung der Abrechnung für Krankenhäuser im deutschen
Gesundheitswesen auf das G-DRG-System (German Refined - Diagnosis Related Groups,
siehe [GDRG]) ist nicht nur eine vollständige, sondern auch chronologisch korrekte
Dokumentation notwendig. Es reicht nicht mehr aus nur festzuhalten, warum und wie der
Patient behandelt wurde. Es muss genau unterschieden werden zwischen
•
Einweisungsdiagnose
•
Hauptdiagnose bei Aufnahme
•
Nebendiagnose(n) bei Aufnahme
•
Risikofaktoren
•
Behandlungsrelevante Hauptdiagnose
•
Nebendiagnose.
Wie in Tab. 3.2 dargestellt, können bei derselben Therapie gleiche Diagnosen, die aber in
einer unterschiedlichen Reihenfolge gestellt wurden, zu verschiedenen gegenüber der
Krankenkasse abrechenbaren Punktwerten5 führen. Eine exakte Dokumentation ist hier zum
5
Die Punktwerte werden direkt in einen Betrag in €, der gegenüber den Krankenkassen in Rechnung
gestellt wird, durch Multiplikation mit einem jährlich neu festgelegten Faktor umgerecht.
49
Die klinische kardiologische Fachabteilung
einen für die Klinik relevant, damit der maximale Erlös nicht durch Fehlen von Diagnosen
und daraus resultierendem Herabstufen des Schweregrades der abrechenbaren
Fallpauschale verloren geht (vgl. Tab. 3.2). Zum anderen verlangen die Krankenkassen
auch eine lückenlos und kausal nachvollziehbare Aufzeichnung aller diagnostischen und
therapeutischen Verfahren, damit Kliniken nicht durch "geschicktes Vertauschen" von
Diagnosen die Abrechnung in ihrem Sinne manipulieren können. Dass Letzteres nicht
passiert, wird durch den medizinischen Dienst der Krankenkassen überwacht, welcher auf
Wunsch die kompletten Akten eines Behandlungsfalls einsehen kann.
DRG
DRG-Text
Gewicht
Punkte
F41A
Myokardinfarkt mit invasiver Diagnostik mit KK
3,0
18.255
F41B
Myokardinfarkt mit invasiver Diagnostik ohne KK
1,8
10.953
F60A
Myokardinfarkt ohne invasive Diagnostik mit KK
2,4
14.604
F60B
Myokardinfarkt ohne invasive Diagnostik ohne KK
1,6
9.736
F60C
Myokardinfarkt ohne invasive Diagnostik, verstorben
1,5
9.128
Tab. 3.2:
Unterschiedliche DRGs und damit verbundene Erlöse, die z. B. nach der Hauptdiagnose
"Akuter Myokardinfarkt" abrechenbar sind, in Abhängigkeit von KK (Komplikationen und
Komorbidität). Liegen zusätzliche, erschwerende KK vor, so wird der Erlös höher. Daher
müssen diese dokumentiert und für die Abrechnung angegeben werden.
Die derzeit im Einsatz befindlichen eher datenorientierten KISe und medizinischen AISe sind
für die Lösung der Koordinations-, Kommunikations- und Dokumentationsprobleme in den
medizinischen Fachabteilungen weniger geeignet als prozessorientierte Systeme. Ein
klinisches Abteilungsinformationssystem sollte daher in der Lage sein, alle klinisch
relevanten Informationen innerhalb des Behandlungsprozesses zu jeder Zeit an jedem Ort
für berechtigte Anwender schnell zur Verfügung zu stellen.
Nach [HSW96] sind die Forderungen an ein solches System wie folgt beschreibbar:
50
•
Patientendatenaufnahme und -verwaltung ist nicht nur für die Verwaltung, sondern
für alle Bereiche eines Krankenhauses von Bedeutung
•
Auf einer Station sind diagnostische, therapeutische, pflegerische und administrative
Arbeiten zu unterstützen
•
In Ambulanzen kommen Unterstützung von Terminierung und Ablaufsteuerung hinzu
•
Eine integrierte OP-Dokumentation unterstützt Ärzte, Schreib- und Verwaltungskräfte
•
Einrichtungen zur Funktionsdiagnostik benötigen Unterstützung bei ihren
Arbeitsabläufen, bei einer umgehenden Leistungsanforderung und bei rechtzeitiger
Befundübermittlung und -präsentation
Die klinische kardiologische Fachabteilung
•
Das Krankenaktenarchiv muss Krankenakten verwalten und rechtzeitig zur
Verfügung stellen können
•
Medizinisches Schriftgut wie Arztbriefe, OP-Berichte sollte auf einfache Weise
erstellbar sowie rechtzeitig und patientenbezogen zugreifbar sein
•
Die
medizinische
Basisdokumentation
dient
dem
Berichtswesen und der Erfüllung gesetzlicher Verpflichtungen
•
Für die Betriebssteuerung (Controlling) ist eine Zuordnung der entstandenen Kosten
zu Leistungserbringern und Leistungsempfängern nötig
•
Für das Qualitätsmanagement werden Informationen über die Behandlung von
Patienten und Wissen über diagnostische und therapeutische Standards benötigt.
krankenhausinternen
Auch innerhalb der GMDS (Deutsche Gesellschaft für Medizinische Informatik, Biometrie
und Epidemiologie e.V., siehe [GMDS]) gibt es eine eigene Arbeitsgruppe "KIS Informationssysteme im Gesundheitswesen" (siehe [AGKIS]), die sich unter anderem mit
Anforderungen an KISe und medizinische AISe beschäftigt. Diese Forderungen treffen
sicher auch für ein kardiologisches AIS zu.
3.2 Die moderne Kardiologie
Die zentrale Aufgabe der Kardiologie ist die Diagnose und Therapie von Herzerkrankungen.
Darüber hinaus werden auch Erkrankungen artverwandter Disziplinen wie der Angiologie
und Pulmologie in größeren kardiologischen Abteilungen, insbesondere in Häusern, die zu
klein für eigenständige angiologische oder pulmonologische Abteilungen sind, behandelt.
Dies umfasst Erkrankungen des Kreislaufsystems, der peripheren Gefäße und der Lunge.
In den letzten Jahren entstanden durch Outsourcing und Expansion kardiologischer Praxen
zunehmend im niedergelassenen Bereich Kardiologien, die das volle Spektrum der
kardiologischen Diagnostik und Therapie unter Nutzung eines Herzkatheterlabors anbieten.
Hier wird nicht auf die Besonderheiten niedergelassener Fachärzte eingegangen, sondern
der Fokus auf die medizinische Dokumentation ausgerichtet. Daher werden die
kardiologischen Verfahren im Einzelnen vorgestellt und dahingehend analysiert, wie deren
Ablauf durch IT-Systeme unterstützt werden kann. Die Frage, auf welchem Weg aus den
medizinischen Daten die für den Arzt relevanten Abrechnungsinformationen in Abhängigkeit
seiner Organisationsform ermittelt werden können, wird erst in Kapitel 5 wieder aufgegriffen.
Dort wird gezeigt, an welcher Stelle die dort vorgestellte Software-Architektur entsprechende
Adapter und Schnittstellen für diese Aufgabe bereitstellt.
In der Klinik präsentiert sich die Kardiologie zum einen als "Abteilung der Vollversorgung", in
der der Patient von der Aufnahme bis zu Entlassung durchgehend inklusive stationärem
51
Die klinische kardiologische Fachabteilung
Aufenthalt betreut wird. Zum anderen finden sich in der Kardiologie Unterabteilungen wie
Ultraschall, Herzkatheterlabor oder EKG-Abteilung, die als reine Dienstleister auftreten. Die
Leistungen werden dort hauptsächlich für Patienten der zugehörigen kardiologischen
Normal- und Intensivstationen, gelegentlich aber auch konsiliarisch für andere Stationen der
eigenen Klinik oder für externe Krankenhäuser, erbracht.
Dies bedeutet, dass nicht nur der Behandlungsablauf in der Abteilung, sondern auch der
Ablauf in jeder leistungserbringenden Unterabteilung genauer betrachtet werden muss.
Zusätzlich wird noch die Einbettung der Kardiologie in den gesamten Behandlungsprozess
von Herzpatienten vorgestellt. Eine Übersicht über diese drei grundlegenden Abläufe und ihr
Zusammenhang kann Abb. 3.1 entnommen werden.
Von außen gesehen erscheint die Klinik als "black box", in die der Patient durch einen Arzt
auf Grund einer Diagnose eingewiesen wird. Innerhalb der Klinik hält sich der Patient auf
einer Station auf und wird durch die leistungserbringenden Abteilungen behandelt. Diese
einzelnen Abteilungen präsentieren sich aus Sicht der Stationen wiederum als "black box" in
welche der Patient verlegt und später, nach Durchführung der medizinischen Maßnahme,
wieder abgeholt wird. Die detaillierte Betrachtung dieser leistungserbringenden Abteilungen
zeigt, dass hier die grundsätzlichen Leistungen durchgeführt werden, welche den
"atomaren" Aktivitäten aus medizinischer Sicht entsprechen.
Hausarzt
Überweisung
Entlassung
Facharzt
Einrichtung
Kardiologie in der Klinik
Notarzt
Zu Hause
Kardiologie in der Klinik
Überweisung
Reha-
Station
Rückverlegung
Verlegung
Leistungserbringende
Entlassung
Unterabteilung
Leistungserbringende Unterabteilung
Verlegung
Rückverlegung
Vorbereitung
Durchführung
Nachbereitung
Abb. 3.1: Abläufe und Zusammenhänge im Behandlungsprozess kardiologischer Patienten: Der
Patient wird meistens vom Facharzt, seltener vom Hausarzt oder Notarzt, in die Klinik
eingewiesen und nach erfolgreicher Behandlung wieder entlassen. Innerhalb der
Kardiologie liegt der Patient auf einer Station und wird von dort den notwendigen
diagnostischen und therapeutischen Verfahren zugeführt.
52
Die klinische kardiologische Fachabteilung
Von einer Effizienzsteigerung einer tieferen Ebene profitieren auch alle darüber liegenden.
Es ist daher in der Kardiologie wichtig, dass die leistungserbringenden Unterabteilungen
möglichst effizient arbeiten. Dies verkürzt Wartezeiten der Patienten auf den Stationen, die
auf eine medizinische Behandlung warten. Zusätzlich kann dies zu einer Beschleunigung
der Gesamttherapie in anderen Abteilungen des Hauses führen, wenn die kardiologischen
Leistungserbringer konsiliarisch tätig sind.
Daneben muss der stationäre Arbeitsablauf betrachtet werden. Hier muss insbesondere der
Prozess der Aufnahme und Entlassung analysiert werden. Da die entscheidenden diagnostischen und therapeutischen Verfahren aber in den leistungserbringenden Unterabteilungen
durchgeführt und in diesen fast alle Befunde gestellt und invasiven Maßnahmen ausgeführt
werden, liegt hier der Schwerpunkt bei der Erfassung medizinischer Informationen. Speziell
in der Kardiologie steht das Herzkatheterlabor im Mittelpunkt des Behandlungsprozesses.
So werden auch Patienten in der Regel zum Herzkatheter in die Klinik eingewiesen.
Bei der Einbettung der Klinik in den gesamten Behandlungsprozess der Herzerkrankung
steht nur der Informationsaustausch im Mittelpunkt. Das eigentliche "praktische" Vorgehen
in anderen Institutionen kann nur selten von außen, d. h. durch Veränderungen in der
eigenen Klinik, beeinflusst werden. Da es sich bei kardiologischen meistens um chronische
Erkrankungen handelt, ist eine enge Kooperation und Kommunikation zwischen den
unterschiedlichen beteiligten medizinischen Institutionen, im Allgemeinen Hausarzt,
Facharzt, Klinik und Rehabilitationseinrichtungen, wichtig.
Im Folgenden werden zunächst die wichtigsten kardiologischen Krankheitsbilder vorgestellt.
Danach werden die in der Kardiologie anzufindenden personellen und materiellen
Ressourcen beschrieben. Im Anschluss daran werden die unterschiedlichen diagnostischen
und therapeutischen Verfahren vorgestellt. Hierauf wird auf die Behandlung im stationären
Kontext und nachfolgend im Zusammenspiel mit externen Institutionen eingegangen. Die
hier vorgestellten medizinischen Arbeitsabläufe, Ressourcen und Berufsgruppen bilden die
Grundlage für das Modell in Kapitel 4 und die Software-Architektur in Kapitel 5.
3.2.1 Die wichtigsten kardiologischen Krankheitsbilder
Im Kern beschäftigt sich die Kardiologie mit der Diagnose und Therapie von
Herzerkrankungen. Diese können in fünf Obergruppen zusammengefasst werden:
•
Erkrankungen der Herzkranzgefäße
•
Fehlfunktionen der Herzklappen
•
Erkrankungen des Herzmuskels, links- und rechtsventrikuläre Dysfunktion
•
Chronische Herzrhythmusstörungen und Dysfunktion des Erregungsleitungssystem
•
Sonstige Erkrankungen des Herzens wie z. B. Perikardergüsse.
53
Die klinische kardiologische Fachabteilung
Zusätzlich werden in der Kardiologie häufig diagnostische und therapeutische Verfahren für
das Herz-/Kreislaufsystem, insbesondere für die großen herznahen Gefäße, die
Halsschlagadern und die Nierenarterien, durchgeführt. Auf diese angiologischen Verfahren
soll hier auch eingegangen werden, da sie später bei der Modellierung der HK
(Herzkatheruntersuchung) eine Rolle spielen werden.
Weitere Krankheitsbilder wie z. B. angeborene Herzfehler bei Neugeborenen oder
pneumologische Erkrankungen werden zwar auch von Kardiologen behandelt, insbesondere
wenn diese im Zusammenhang mit Herzerkrankungen auftreten, da Kinderkardiologien aber
nur in wenigen speziellen Fachkliniken vertreten sind und die hier als Beispiel verwendete
Abteilung in erster Linie6 Erwachsene behandelt, wird auf diese Erkrankungen nicht weiter
eingegangen. Für diese noch weiter spezialisierten Fachkliniken kann zwar grundsätzlich die
im Folgenden zu entwickelnde Software-Architektur Anwendung finden, muss aber um
Module zur Abdeckung dieser selten auftretenden Krankheitsbilder erweitert werden. Hierbei
geht es in erster Linie um die Darstellung der angeborenen Fehlbildungen, die in stark
unterschiedlichen und teilweise schwer klassifizierbaren Ausprägungen auftreten. Hier sind
eher IT-Systeme aus den Bereichen Grafikverarbeitung und CAD gefragt, mit denen der Arzt
selber die gefundene Morphologie für jeden Fall individuell und möglichst realitätsnah
zeichnen kann.
Wie aus Tab. 3.3 (vgl. [Bru04]) hervorgeht, ist die häufigste kardiologische Erkrankung die
der Herzkranzgefäße, welche zumeist mit einer Leistungseinschränkung des Herzmuskels
einhergeht. Die Diagnose "Herzinsuffizienz" beschreibt ein undifferenziertes Krankheitsbild,
welches einfach nur für das Vorhandensein einer Leistungseinschränkung des Herzens
steht. Dies ist meistens auf eine koronare Herzerkrankung oder einen Herzklappenfehler
zurückzuführen.
Ein ähnliches Bild der Diagnoseverteilung findet sich auch in Tab. 3.4, welche die
Auswertung der Diagnosen nach Herzkatheteruntersuchungen in der Kardiologie der
Klinikum Oldenburg gGmBH darstellt. Am zweithäufigsten finden sich Erkrankungen der
Herzklappen, gefolgt von sonstigen Herzerkrankungen und Rhythmusstörungen. Der Anteil
angiologischer Diagnosen wurde der Vollständigkeit halber in Tab. 3.4 mit aufgenommen.
Dieser ist jedoch nicht repräsentativ, da in Oldenburg ein anderes Krankenhaus den
primären Versorgungsauftrag für Gefäßerkrankungen mit einer eigenen Angiologie abdeckt
und weiterhin viele angiologische diagnostische und therapeutische Verfahren von
Radiologen durchgeführt werden. Sowohl die Daten externer Abteilungen als auch
Informationen aus anderen Häusern lagen für diese Arbeit nicht zur Auswertung vor.
6
Für die Klinikum Oldenburg gGmbH ist seit 2001 ein Kinderkardiologe, der aber über das
angeschlossene Kinderkrankenhaus angestellt ist, tätig. Dieser führt weniger als 1 % der
Untersuchungen im HK-Labor durch und überweist komplizierte Fälle an die besser ausgestatteten
Kinderkliniken in Kiel und Hannover, da Oldenburg kein ausgewiesenes Zentrum für
Kinderkardiologie ist und auch die Herzchirurgie nicht über die Ausstattung für herzchirurgische
Eingriffe an Kindern verfügt.
54
Die klinische kardiologische Fachabteilung
Erkrankungsgruppe
ICD-Gruppen
Anzahl
Anteil
Herzkranzgefäße, Herzinfarkt, Herzmuskel
I21, I25
827.135
70 %
Herzinsuffizienz
I50
263.007
22 %
Herzklappe
I05, I06, I07, I08, I09, I34, I35,
I36, I37, I38, I39, Q22, Q23
64.692
6%
Sonstige Herz
I51, Q20, Q24
20.449
2%
Tab. 3.3:
Verteilung der Primärdiagnosen bei Entlassung aus stationärem kardiologischem Aufenthalt in Deutschland in den Jahren 2002 und 2003 nach [Bru04]. Von den Krankenhäusern
wurden insgesamt 1.175.283 Entlassungsdiagnosen gemeldet. Hier sind keine Erkrankungen der peripheren Gefäße und Rhythmusstörungen aufgeführt. Die Diagnosen sind nach
den Obergruppen des ICD (erste drei Stellen) aufgeschlüsselt. Daher kann nicht zwischen
Erkrankungen der Herzkranzgefäße und des Herzmuskels unterschieden werden.
Erkrankungsgruppe
Herzkatheter
Ultraschall
MR
ICD-Codes
Anz.
Anteil
Herzkranzgefäße,
Herzinfarkt
I25.10, I25.11, I25.12, I25.13,
I25.2, I25.4, I21.0, I21.1, I21.3
2.931
82,8 %
3
0,03 %
2
0,8 %
Herzmuskel
I11.0, I11.9, I25.3, I25.5, I27.0,
I42.0, I42.1, I42.2, I42.9, I50.01,
I50.19, Q21.0, Q21.1, Q21.2
890
25,1 %
2.826
26,3 %
95
36,6 %
Herzklappen
I05.0, I05.1, I05.2, I06.0, I06.2,
I08.0, I08.1, I08.2, I08.3, I34.0,
I34.1, I34.2, I34.8, I35.0, I35.1,
I35.2, I36.1, I37.0, I37.1, I37.2,
Q21.1, Q22.1, Q22.2, Q22.3,
Q23.0, Q23.2, Q23.3, Q23.4,
Q22.8, Q23.1, Q23.3
327
9,2 %
6.676
62,1 %
131
50,4 %
Chronische
Rhythmusstörung
I44.2, I44.7, I47.2, I48, I49.0,
I49.3
7
0,2 %
0
0%
0
0%
Sonstige Herz
D15.1, I27.9, I31.1, I31.3, I33.0,
I40.1, I51.3, Q21.3, Q22.6,
Q25.0, Q26.1, Z95.8
42
1,2 %
597
5,6%
28
10,8 %
Kreislauf,
periphere
Gefäße
I63.4, I65.0, I65.2, I65.3, I66.0,
I66.1, I70.0, I70.1, I70.20, I70.22,
I70.25, I70.8, I71.01, I71.4, I71.6,
I71.9, I77.8, I80.0, I80.1, I80.2,
I87.8
80
2,3 %
490
4,6 %
15
5,8 %
Normalbefund
Keine kardiologische Diagnose
339
9,6 %
3.207
29,9 %
89
34,2 %
Tab. 3.4:
Anz.
Anteil
Anz.
Anteil
Häufigkeit und prozentuale Verteilung der Diagnosen nach Herzkatheter, Ultraschall und
MR in der Kardiologie der Klinikum Oldenburg gGmBH im Jahr 2003. Insgesamt wurden in
diesem Zeitraum 3.541 Herzkatheter, 10.743 Ultraschalluntersuchungen und 260 MRs
durchgeführt. Da bei einem Patienten auch mehrere Diagnosen gestellt werden können
und nicht nur die Primärdiagnose ausgewertet wurde, differiert die Summe der Diagnosen
von der Anzahl der durchgeführten Eingriffe.
55
Die klinische kardiologische Fachabteilung
Die Diagnoseverteilung bezüglich Rhythmusstörungen darf ebenfalls nicht als repräsentativ
angesehen werden, da zu deren Diagnostik andere Verfahren, insbesondere EKG
(Elektrokardiogramm) und EPU (elektrophysiologische Untersuchung), angewendet werden.
Diese Verfahren kommen zwar in der Oldenburger Kardiologie zum Einsatz, ihre Ergebnisse
werden aber nicht in einem Informationssystem erfasst und stehen daher ebenfalls nicht zur
Auswertung zur Verfügung. Der Anteil der chronischen, behandlungsbedürftigen
Rhythmuserkrankungen kann nach Einschätzung der kardiologischen Fachärzte der
klinischen Referenzabteilung mit etwa 5 % aller kardiologischen Erkrankungen abgeschätzt
werden.
Die Erkrankung der Herzkranzgefäße wird meist als KHK (koronare Herzerkrankung,
Koronararterien ist der medizinische Fachbegriff für die Arterien, die den Herzmuskel mit
Blut versorgen) abgekürzt. Nach [Her97] ist sie definiert als
"Herzerkrankung
unterschiedlicher
Ätiologie
mit
dem
gemeinsamen
pathophysiologischen Mechanismus der Koronarinsuffizienz = Missverhältnis zwischen
Sauerstoffbedarf und Sauerstoffangebot im Herzmuskel."
In über 90% der Fälle ist die Ursache der KHK die stenosierende Atherosklerose der großen
Herzkranzgefäße. Seltener findet sich die Ätiologie in der pathologischen Verengung der
kleinen Gefäße.
Die stenosierende Atherosklerose beschreibt die Verengung der Arterien bedingt durch
Ablagerungen an der Gefäßinnenwand. Diese Ablagerungen besitzen einen Lipidkern, der
von einer bindegewebsarterigen Kappe bedeckt ist und aus fettangereicherten
Schaumzellen, Kalk und Monozyten besteht. Reißt diese Kappe ein (sog. Plaque-Ruptur),
so kommt der hochthrombotische Lipidkern mit dem Blut in Kontakt, was zur sofortigen
Gerinnung des Blutes (Thrombenbildung) und meist zum vollständigen Gefäßverschluss
führt. Dadurch kann kein Blut mehr durch das Gefäß transportiert werden und die Zellen des
hinter dem Verschluss liegenden Gewebes werden nicht mehr mit Sauerstoff versorgt. Dies
führt dazu, dass die Zellen absterben. Dieser Vorgang wird dann als Infarkt bezeichnet (vgl.
Abb. 3.2).
Wie Tab. 3.4 entnommen werden kann, ist das wichtigste Verfahren zur Abklärung der KHK
der diagnostische Herzkatheter. Da die KHK gleichzeitig die häufigste kardiologische
Erkrankung ist und diese mit Hilfe des therapeutischen Herzkatheters durch den
Kardiologen auch therapiert werden kann, ist die Herzkatheteruntersuchung das zentrale
diagnostische und therapeutische Verfahren der Kardiologie.
56
Die klinische kardiologische Fachabteilung
Schaumzellen
Gefäßwand
Thrombus
Lipidkern
Abb. 3.2: Stenotische Atherosklerose und Mechanismus des Infarktes: durch Aufbrechen der
Ablagerung (atherosklerotischer Plaque) bildet sich ein Thrombus, der das Gefäß
verschließt. Dadurch wird das hinter dem Verschluss liegende Gewebe nicht mehr mit
Sauerstoff versorgt und stirbt ab.
Die zweithäufigste Erkrankungsgruppe bildet die Fehlfunktion des Herzmuskels, die häufig
eine Folge der KHK oder eines daraus resultierenden Infarktes ist. Ist durch die mangelnde
Versorgung des Herzmuskels dieser geschädigt, so kann er nicht mehr die notwendige
Leistung erbringen, um den Körper mit Blut zu Versorgung. Die häufigsten Krankheitsbilder
sind
•
Linksherzinsuffizienz: der linke Ventrikel hat nicht mehr genug Leistung, um den
Körper ausreichend mit Blut zu versorgen
•
Rechtsherzinsuffizienz: der rechte Ventrikel kann das Blut nicht mehr ausreichend
durch die Lunge befördern, meist als Folge einer Lungenembolie
•
VSD (Ventrikelseptumdefekt): die Trennwand zwischen rechtem und linken Ventrikel
hat ein Loch, durch welches das Blut statt in die Gefäße in den jeweils anderen
Ventrikel gepresst wird
•
ASD (Atriumseptumdefekt): wie VSD, jedoch befindet sich das Loch in der
Trennwand zwischen den Vorhöfen.
Herzklappenerkrankungen können an allen vier Klappen (Aorten-, Mitral-, Pulmonal- und
Trikuspidalklappe) auftreten (vgl. Abb. 3.3). Am häufigsten sind die Klappen des linken
Ventrikels betroffen, da diese unter viel stärkerer mechanischer Belastung stehen.
Medizinisch wird zwischen erworbenen und angeborenen Klappenfehlern unterschieden.
Diagnostisch wird zwischen der Insuffizienz, welche ein Leck der Klappe beschreibt, und der
57
Die klinische kardiologische Fachabteilung
Stenose, welche eine Verengung angibt, unterschieden. Sowohl Stenose als auch
Insuffizienz werden in vier Grade eingeteilt, die Auskunft über die Schwere der Erkrankung
geben und zwar
•
Grad 1: Keine Beschwerden
•
Grad 2: Beschwerden bei stärkerer körperlicher Belastung
•
Grad 3: Beschwerden bei leichter körperlicher Belastung
•
Grad 4: Beschwerden in Ruhe.
Das Verfahren der Wahl zur diagnostischen Abklärungen von Klappenerkrankungen ist
derzeit die Ultraschalluntersuchung (vgl. Tab. 3.4). Ab Grad 3 ist die Indikation zur Therapie
gegeben, die meist operativ durch die Herzchirurgie in Form eines Herklappenersatzes
erfolgt. In seltenen Fällen erfolgt die Behandlung durch den Kardiologen im
Herzkatheterlabor im Rahmen einer sog. Klappensprengung.
Aorta
Vena Cava superior
Pulmonalarterie (PA)
Rechter Vorhof (RA)
Pulmonalklappe (PK)
Linker Vorhof (LA)
Vena Cava inferior
Aortenklappe (AK)
Trikuspidalklappe (TK)
Rechter Ventrikel (RV)
Mitralklappe (MK)
Linker Ventrikel (LV)
Abb. 3.3: Schematische Darstellung des Herzens mit Schwerpunkt auf der Abbildung der
Herzklappen und -kammern nach [RS95].
Bei chronischen Herzrhythmusstörungen ist die Erregungsleitung im Herzen gestört. Erste
Anzeichen hierfür lassen sich zuverlässig im EKG nachweisen. Die häufigsten
Erkrankungen sind
58
•
Bradykardie: das Herz schlägt zu langsam
•
Tachykardie: zu schneller Herzschlag
Die klinische kardiologische Fachabteilung
•
Kammerflimmern oder –flattern: Der Ventrikel kontrahiert und expandiert nicht mehr
gleichmäßig, sondern "flimmert" und pumpt somit das Blut nicht mehr durch den
Körper
•
Vorhofflimmern oder –flattern: Der Vorhof kontrahiert und expandiert nicht mehr
gleichmäßig, sondern "flimmert" und pumpt somit das Blut nicht mehr durch den
Körper
•
Blockbilder: die Erregungsausbreitung zu gewissen Teilen des Herzens ist gestört,
wodurch die Muskelpartien dort nicht mehr oder zum falschen Zeitpunkt kontrahieren
•
Arrhythmia absoluta: Die Erregungsausbreitung ist komplett gestört, wodurch das
Herz in völlig unregelmäßigen Intervallen kontrahiert.
Häufig treten Rhythmusstörungen erst unter Belastung auf. Die Therapie erfolgt heute durch
Implantation eines Schrittmachers, welcher die Pulsgebung übernimmt und so die
betroffenen Muskelpartien stimuliert.
Besonders gefährlich sind Kammer- und Vorhofflimmern, da durch diese der Bluttransport in
den Körper zum Erliegen kommen kann, was den schnellen Tod oder dauerhafte
Organschäden beim Patienten zur Folge hat. Dieses Flimmern kann mit Defibrillatoren,
welche einen elektrischen Schock von mehreren hundert Volt bei geringer Stromstärke
abgeben, behandelt werden. Diese Geräte lassen sich unterdessen so klein konstruieren,
dass sie auch implantiert werden können.
Die restlichen Erkrankungen des Herzens bilden lediglich einen verschwindend geringen
Anteil (< 2 %) aller kardiologischen Erkrankungen. Für sich genommen stellen sie jeweils
weniger als 0,5 % der Herzerkrankungen dar. Die wichtigsten sind:
•
Angeborene Fehlstellungen: hierunter fallen sämtliche Fehlbildungen des Herzens
wie z. B. zusammengewachsene Herzkammern oder falsch verbundene Venen und
Arterien.
•
Perikarderguß: Flüssigkeit fließt in die Herzhöhle und drückt auf das Herz
(Perikardtamponade), so dass das Schlagvolumen eingeschränkt wird, häufig als
Folge einer herzchirurgischen Operation.
•
Tumore und Myxome: Wucherungen im Herzen, die sich meistens an den
Herzwänden oder auf den Herzklappen bilden und operativ entfernt werden.
Abschließend werden hier die angiologischen Erkrankungen vorgestellt, die artverwandt mit
den Erkrankungen der Herzkranzgefäße sind und sich auch mit sehr ähnlichen
medizinischen Maßnahmen, wie sie von Kardiologen angewendet werden, diagnostizieren
und behandeln lassen. Dies liegt daran, dass es sich bei den Koronararterien grundsätzlich
auch nur um Blutgefäße handelt, wie sie sich im restlichen Körper auch finden. Es kann in
allen Gefäßen zu atherosklerotischen Veränderungen kommen, die im gesamten Körper zur
Mangelversorgung mit Sauerstoff bei Organen und Muskelgewebe führen kann. Ebenfalls
59
Die klinische kardiologische Fachabteilung
kann es zu Verschlüssen und daraus resultierenden Infarkten kommen. Betrifft dies z. B.
das Gehirn, so wird dies in leichten Fällen als TIA (transmurale ischämische Attacken) und
in schweren Fällen als Schlaganfall bezeichnet.
Zusätzlich kann es bei den großen Gefäßen, insbesondere der Aorta, zu so genannten
Dissektionen kommen. Bei diesen handelt es sich um Risse in einer der drei Schichten der
Gefäßwand. Durch diese dringt Blut zwischen die Gefäßwände und staut sich dort an, da es
dort keinen Ausgang findet. Dieser teilweise geronnene Blutsack nennt sich Aneurysma (vgl.
Abb. 3.4) und ist bei großen Arterien lebensbedrohlich. Platz das Aneurysma oder reißt die
Arterienwand, hat dies häufig den Tod des Patienten durch inneres Verbluten zur Folge. Bei
einem Aortenaneurysma sinkt die Überlebenswahrscheinlichkeit pro Stunde um 10 %.
Aorta
Nierenarterien
Aneurysma
A. iliaca
Wirbelsäule
Abb. 3.4: Aneurysma der Bauchaorta: Das Aneurysma ist gut als Aufweitung in der Mitte des Bildes
zu erkennen. Im Hintergrund ist das Originalbild in der angiografischen Ansicht zu sehen.
60
Die klinische kardiologische Fachabteilung
3.2.2 Kardiologische Ressourcen
Die im Folgenden vorgestellten kardiologischen Ressourcen können in fünf Obergruppen
eingeteilt werden:
•
Personal, welches in Gruppen zusammengefasst werden kann
•
Räumlichkeiten (inkl. fest installierter medizinischer Großgeräte)
•
Medizinisches Inventar (spezielles Mobiliar, Geräte und Maschinen)
•
Verbrauchsmaterialien.
Das Personal kann in medizinisches und nicht-medizinisches Personal, letzteres im
Folgenden auch als "administratives Personal" bezeichnet, unterteilt werden. Die
medizinischen Mitarbeiter werden wiederum in Ärzte und Pflegepersonal unterteilt.
Aufgabe der Ärzte ist die Behandlung der Patienten. Hierfür können sie auf alle verfügbaren
Ressourcen der Abteilung zurückgreifen, sind gegenüber dem Pflegepersonal
weisungsbefugt und übernehmen die Verantwortung für die angeordneten diagnostischen
und therapeutischen Verfahren. Weiterhin können Ärzte Leistungen anderer Abteilung direkt
anfordern, wie z. B. Laborbefunde vom Labor oder Röntgenbilder aus der Radiologie, oder
Termine für Untersuchung durch Fachärzte aus anderen Bereichen der Klinik, wie z. B.
Gastroskopien aus der Inneren Medizin oder operative Leistungen aus der Chirurgie,
vereinbaren. Sämtliche Schritte in der Behandlungskette müssen vom Arzt dokumentiert und
für die Abrechnung an die Verwaltung gemeldet werden.
Innerhalb der Ärzteschaft gibt es eine feste Hierarchie aus folgenden Mitarbeitergruppen:
•
Chefarzt: Der Chefarzt oder Klinikdirektor leitet die Abteilung und ist in letzter
Instanz für alle von seinen Mitarbeitern durchgeführten medizinischen Eingriffe
verantwortlich. Zusätzlich zu seiner ärztlichen Tätigkeit muss sich der Chefarzt auch
um die administrative Leitung der Abteilung kümmern. Dies umfasst Aufgaben wie
Budgetverhandlungen, Einstellungen von Mitarbeitern, Repräsentation der Abteilung
nach außen oder Entscheidungen über die Einführung neuer medizinischer
Behandlungsverfahren. Der Chefarzt hat eine Ambulanzermächtigung für die
Durchführung gewisser medizinischer Eingriffe, die mit der KV ausgehandelt sind.
Daneben kann der Klinikdirektor zusätzliche Leistungen bei privat versicherten
Patienten durchführen und abrechnen. Der Chefarzt ist gegenüber allen Mitarbeitern
weisungsbefugt.
•
Oberarzt: Jede Abteilung verfügt über mindestens einen, in der Regel mehrere
Oberärzte (in der Oldenburger Kardiologie sieben), die für die Durchführung der
medizinischen Eingriffe verantwortlich sind. Innerhalb der Abteilung ist für jede
Station und jeden Funktionsbereich ein Oberarzt primär zuständig. Bei den
Oberärzten handelt es sich ausschließlich um Fachärzte. Eine besondere Stellung
nimmt der leitende oder erste Oberarzt ein, der den Chefarzt in dessen Abwesenheit
61
Die klinische kardiologische Fachabteilung
vertritt und in diesem Zeitraum seine Kompetenzen inkl. der Ambulanzermächtigung
und Privatliquidation übernimmt. In seltenen Fällen können Oberärzte, ebenso wie
der Chefarzt, über eine eigene Ambulanz verfügen.
•
Assistenzarzt: Die Assistenzärzte führen die medizinischen Eingriffe meist nach
Rücksprache mit den Oberärzten durch. Häufig sind sie noch in der Weiterbildung
zum Facharzt und dürfen grundsätzliche medizinische Entscheidungen nicht selbst
treffen. Dies gilt besonders für die Ärzte, die gerade erst ihr Staatsexamen abgelegt
haben und frisch von der Hochschule kommen. Bis Oktober 2004 wurden diese als
AIP (Arzt im Praktikum) für einen gesetzlich vorgeschriebenen Zeitraum von 18
Monaten in der Klinik in niedrigeren Gehaltsstufen angestellt. Diese Regelung wurde
mit dem primären Ziel, den Beruf des Klinikarztes attraktiver zu gestalten, gestrichen.
Dadurch wird der Einstieg junger Hochschulabsolventen in die Klinik gefördert und
dem Ärztemangel in Deutschland entgegen gewirkt.
Wie in allen Kliniken, die einen Fort- und Weiterbildungsauftrag haben und
Facharztausbildungen anbieten, gibt es auch in der Kardiologie des Klinikum Oldenburg
Ausbildungs- und davon abgeleitete Befugnisvorschriften für die Ärzte. In Oldenburg erfolgt
die Ausbildung in enger Kooperation mit der Abteilung für Innere Medizin. Sämtliche Ärzte
werden zunächst innerhalb von ca. vier Jahren zu Fachärzten für Innere Medizin ausgebildet
und können dann in einer einjährigen Fortbildung zum Facharzt für Kardiologie werden. Die
endgültige Prüfung wird vor der Ärztekammer nach Absolvieren eines vorgeschriebenen
Katalogs an medizinischen Leistungen, die der Arzt während seiner Weiterbildung im
Krankenhaus selber durchgeführt haben muss, abgelegt.
Um sämtliche Bereiche der Fachabteilung durchlaufen zu haben, "rotiert" der Arzt während
seiner Ausbildung durch die einzelnen Unterabteilungen und lernt diese in folgender
Reihenfolge kennen:
•
Normalstation
•
Intensivstation / Innere Notfallaufnahme
•
Ultraschall
•
Diagnostischer Herzkatheter
•
Therapeutischer Herzkatheter.
Dies führt dazu, dass es innerhalb der Gruppe der Assistenzärzte Personen mit
unterschiedlichen Ausbildungsständen und Befugnissen gibt.
Es ist also wichtig zu wissen, welcher Arzt welches Verfahren in welchem Maße bereits
beherrscht. Dies gilt auch für Fachärzte, die für die Ausübung komplexer neuer
medizinischer Verfahren zunächst eine Fortbildung durchlaufen müssen. So verfügen z. B.
nur zwei der sieben Oldenburger Oberärzte über fundierte Kenntnisse im Umgang mit einem
62
Die klinische kardiologische Fachabteilung
Kardio-MR. Neben einer Einteilung in der klinischen Hierarchie kann also jeder Arzt bzgl.
eines medizinischen Verfahrens in drei Gruppen eingeteilt werden:
•
Kann das Verfahren nicht durchführen (hat es noch nie angewendet)
•
Kann das Verfahren unter Aufsicht oder mit Hilfe eines erfahrenen Arztes anwenden
(hat es schon mehrfach, teilweise selbständig angewendet, ist aber noch in der Aus-/
Fortbildung)
•
Kann das Verfahren selbständig durchführen.
Aufgabe des Pflegepersonals ist es die Ärzte bei der Behandlung und Betreuung der
Patienten zu unterstützen. Dazu delegieren die Ärzte Aufgaben an das Pflegepersonal, die
Ärzte sind hier weisungsbefugt. Disziplinarisch untersteht das Pflegepersonal jedoch der
Pflegedienstleitung und nicht den Ärzten.
Das Pflegepersonal führt neben den medizinischen Tätigkeiten noch organisatorische
Aktivitäten aus. Darunter fällt z. B.:
•
Transport von Patienten sowohl begleitend als auch im Rollstuhl oder Bett
•
Lagerhaltung, Verwaltung von Akten, Materialbeständen und Medikamenten
•
Vor- und Nachbereitung von Untersuchungen und Visiten
•
Kommunikation zwischen den einzelnen Abteilungen (Abrufen von Patienten,
Organisation der Wartezonen, Abliefern und Abholen von Patienten, Verbringen von
Akten und anderen Unterlagen etc.).
Neben den rein medizinischen Tätigkeiten müssen so viele administrative Aufgaben
erledigt werden, dass hierfür in großen klinischen Abteilungen Personal angestellt ist. Diese
sind:
•
Chefsekretärin: Neben den normalen Sekretariatsaufgaben wie Terminkoordination
der Chef- und Oberärzte, Schreiben und Versenden von Briefen sowie Koordination
und Vorbereitung von Besprechungen ist die Chefsekretärin für die
Terminvereinbarung mit Privatpatienten zuständig. Zusätzlich ist sie für die
medizinische Korrespondenz bzgl. der Privatpatienten verantwortlich, die
erfahrungsgemäß meistens viel zügiger abgewickelt wird als für Kassenpatienten.
•
Herzkathetersekretariat:
Hier
werden
die
Terminplanung
und
die
Patienteneinbestellung für das Herzkatheterlabor organisiert. Dies erfolgt in
Absprache mit dem Chefsekretariat, da dort die Termine für Privatpatienten
vergeben werden. Weitere Aufgaben sind die Kommunikation mit externen Ärzten
(z. B. Versenden angeforderter Patientenakten), Schreiben von Briefen für
Assistenz- und Oberärzte sowie Annahme und Weiterleitung von externen Anrufen
von Patienten, niedergelassenen Ärzten und Firmen.
63
Die klinische kardiologische Fachabteilung
•
Reinigungskräfte:
Diese
Mitarbeiter
sind
für
die
Reinigung
Untersuchungsräume zuständig und verantworten somit deren Sterilität.
der
In der Klinik gibt es Räumlichkeiten für die medizinischen Tätigkeiten, Stationszimmer für
die Patienten und Aufenthalts- und Büroräume für das Personal. Letztere sind hier nicht von
Bedeutung, die beiden Erstgenannten können in der Kardiologie den Stationen oder
Funktionseinheiten zugeordnet werden.
Neben den Patientenzimmern gibt es auf den Stationen Untersuchungszimmer, in denen
körperliche Untersuchungen, meist für die Aufnahme, und Patientengespräche durchgeführt
werden. Teilweise werden diese Zimmer wegen räumlicher Ressourcenknappheit zusätzlich
als Arztzimmer genutzt.
Bei den Funktionseinheiten gibt es Räume, die festen Aufgaben zugeordnet sind, da in
ihnen medizinische Großgeräte installiert sind. In der Kardiologie sind dies
Herzkatheterlabor, Kardio-MR und Kardio-CT, wobei die beiden Letzteren nicht in jeder
invasiven Kardiologie anzutreffen sind.
Zusätzlich gibt es Räume, die für Untersuchungsmethoden vorgesehen und für diese
speziell ausgerüstet sind. Dies sind in der Kardiologie spezielle Räumlichkeiten für die
Durchführung von Ultraschall-Untersuchungen und EKGen. Die hier zum Einsatz
kommenden Geräte sind aber mobil und können auch zum Patienten gebracht werden (z. B.
wenn dieser auf der Intensivstation liegt und nicht nicht auf eine andere Station verlegt
werden kann). Die Durchführung der Untersuchung in einem extra für den Eingriff
eingerichteten Raum wird aber bevorzugt, da
•
die Geräte teilweise sehr sperrig und umständlich zu bewegen sind
•
der Patient hier ungestört von anderen Patienten, z. B. Bettnachbarn im gleichen
Zimmer, untersucht werden kann
•
spezielle zusätzliche Ausrüstung in den Räumen zur Verfügung steht.
Das medizinische Inventar dient zur Durchführung der diagnostischen und therapeutischen
Verfahren in der Kardiologie. Am Wichtigsten sind hier die speziell für die kardiologische
Behandlung verwendeten medizinischen Großgeräte, deren Daten Tab. 3.5 entnommen
werden können (vgl. auch Abb. 3.5).
Sämtliche in Tab. 3.5 aufgeführten Geräte produzieren multimediale Daten oder Kurven, die
für die weitere Behandlung des Patienten relevant sind. Im Falle der Geräte, die mit
Strahlung arbeiten, ist nach [RöV87] eine Archivierung der Bild- und Filmdaten von
mindestens 10 Jahren gesetzlich vorgeschrieben. In jedem Fall müssen die von diesen
medizinischen Großgeräten gesammelten Informationen als essentieller Bestandteil des
kardiologischen Arbeitsflusses beachtet und ihrer Archivierung und Bereitstellung besondere
Aufmerksamkeit geschenkt werden.
64
Die klinische kardiologische Fachabteilung
Med. Gerät
Technische Daten
Diagnostik
HK-Labor
Stationäre Montage
in eigenem Raum
mit zusätzlichem
Raum für Steuerung
und Auswertung
Darstellung von Koronararterien,
peripheren Gefäßen, der
Herzkammern und
Druckmessung im Herzen, EPU
Derzeit Verfahren mit der besten
Auflösung und höchsten
diagnostischen Qualität
Kardio-MR
Therapie
Belastung
Minimalinvasive
Eingriffe an
Herz und
peripheren
Gefäßen
Arbeitet mit
Röntgenstrahlen:
belastet
Patient und
Personal
Stationäre Montage Darstellung der großen Gefäße,
in eigenem Raum
der Herzkammern und der
mit zusätzlichem
Dynamik des Herzens
Raum für Steuerung
und Auswertung
Keine mit
diesem
Gerät
möglich
Keine, leichte
Erwärmung
des Körpers
um ca. 1°
Kardio-CT
Stationäre Montage Darstellung der großen Gefäße,
in eigenem Raum
der Herzkammern und der
mit zusätzlichem
Dynamik des Herzens
Raum für Steuerung
und Auswertung
Keine mit
diesem
Gerät
möglich
Arbeitet mit
Röntgenstrahlen:
belastet
Patienten
Ultraschall
Sperrig: 1 – 1,5 m
Darstellung der großen Gefäße,
hoch, 100 – 200 kg der Herzkammern und der
schwer, montiert auf Herklappen
Rollen, innerhalb
der Klinik mobil
Keine mit
diesem
Gerät
möglich
Keine
(Langzeit-)
EKG
Unterschiedlich:
einfach Geräte
wiegen wenige Kilo,
komplexere Geräte
sind auf leichtem
Rollwagen montiert
Leicht zu bewegen
Keine mit
diesem
Gerät
möglich
Keine
Tab. 3.5:
Elektrische Aktivität des Herzens
und Rhythmus des Herzens,
daraus lassen sich Rückschlüsse
auf andere Herzerkrankungen
(z. B. Infarkte) ziehen, die durch
andere Verfahren abgesichert
werden
Charakteristika der wichtigsten medizinischen Großgeräte der Kardiologie
Neben den Großgeräten gibt es gängige medizinische Geräte wie Stethoskope, Infusoren,
Beatmungsgeräte, spezielle Lampen, Sterilisatoren, Blutgasanalysegeräte, Defibrillatoren
oder spezielle Tische wie sie in auch in anderen Kliniken oder Arztpraxen zur Anwendung
kommen. Diese sollen hier, genauso wie das sonstige Inventar, welches alltägliche
Gegenstände wie Betten, Stühle oder Büroeinrichtung umfasst, nicht weiter vorgestellt
werden.
65
Die klinische kardiologische Fachabteilung
Abb. 3.5: Die wichtigsten medizinischen Geräte in der Kardiologie: portables EKG-Gerät (oben
links), 12-Kanal-EKG (oben rechts), Ultraschallgerät (unten links), MR (unten in der Mitte)
und HK-Labor (unten rechts)
Abschließend wird hier ein Überblick über die zum Einsatz kommenden
Verbrauchsmaterialien gegeben. Grundsätzlich können diese in drei Gruppen unterteilt
werden:
•
Medikamente
•
Medizintechnisches Verbrauchsmaterial
•
Implantate.
In der Kardiologie stellen diese Materialien einen erheblichen Kostenfaktor dar (vgl. Tab.
3.6). Kosten können eingespart werden, wenn der Verbrauch reduziert und der
Lagerbestand möglichst gering gehalten wird. Dabei muss allerdings beachtet werden, dass
alle notwendigen Materialien für die unterschiedlichen Eingriffe vorhanden sein sollten. Dies
ist insbesondere im Herzkatheterlabor wichtig, da hier auf Grund der unterschiedlichen
Morphologie der Koronararterien mehrere hundert unterschiedliche Artikel in einer großen
Kardiologie zum Einsatz kommen können. Auf dieses Problem wird im folgenden Abschnitt
näher eingegangen.
66
Die klinische kardiologische Fachabteilung
Eingriff
Diagnostische Herzkatheteruntersuchung
Therapeutischer Herzkatheter inkl. Stentimplantation
Behandlung mit GP-IIb-IIIa-Antagonisten
Lysetherapie
Ungefähre Materialkosten in €
100,- bis 300,1.000,- bis 5.000,200,- bis 1.500,100,- bis 300,-
EKG
< 5,-
Ultraschalluntersuchung
< 5,-
MR-Untersuchung
< 5,-
Tab. 3.6:
Ungefähre Kosten für Verbrauchsmaterialien bei ausgewählten Eingriffen der Kardiologie
3.2.3 Die wichtigsten diagnostischen Verfahren in der Kardiologie
Bei der Behandlung kommen zur Abklärung der Erkrankung zunächst die diagnostischen
Verfahren zum Einsatz. Die Wichtigsten, deren Ablauf im Folgenden vorgestellt wird, sind
•
EKG
•
Ultraschalluntersuchung
•
MR
•
EPU
•
Herzkatheter.
Im EKG werden elektrische Signale registriert, die während der Herztätigkeit auftreten.
Dafür werden an unterschiedlichen Stellen des Körpers äußere Elektroden aufgeklebt. An
diesen Stellen werden die elektrischen Impulse, die das Herz zur Kontraktion reizen,
gemessen. Diese punktbezogenen Messungen werden als Ableitungen bezeichnet. Im
einfachsten Fall werden nur am Herzen drei, bei einem kompletten EKG zwölf Ableitungen,
aufgezeichnet. Der typische Untersuchungsablauf kann Abb. 3.6. entnommen werden.
Neben dem normalen EKG gibt es noch zwei nennenswerte Varianten:
•
Langzeit-EKG: Hierbei wird die elektrische Aktivität über mehrere Stunden oder
Tage aufgezeichnet und nach Anomalien im Herzrhythmus gesucht.
•
Stress-EKG: Bei dieser Untersuchung wird zunächst ein EKG in Ruhe geschrieben.
Dann wird der Patient in vier bis fünf Stufen bis zur Grenze seiner Leistungsfähigkeit
belastet, indem er z. B. auf einem Fahrrad gegen einen Widerstand tritt. In jeder
Belastungsstufe wird ein komplettes EKG geschrieben. So können die
Leistungsfähigkeit und Reserven des Herzens getestet werden.
67
Die klinische kardiologische Fachabteilung
Patient abrufen
EKG vorbereiten
Vorbereitendes Gespräch,
Patient vorbereiten (Elektroden
aufkleben)
EKG einstellen,
ggf. Daten
eingeben
Patient abrufen
EKG vorbereiten
Vorbereitendes Gespräch,
Patient vorbereiten (Elektroden
aufkleben)
EKG einstellen,
ggf. Daten
eingeben
Belastung
erhöhen
EKG schreiben
EKG schreiben
Nein
Patient
ausbelastet?
Befund schreiben und dabei mit
Patient besprechen
Ja
Patient zurück
schicken
EKG
nachbereiten
Befund schreiben und dabei mit
Patient besprechen
Patient zurück
schicken
EKG
nachbereiten
Abb. 3.6: Normaler Untersuchungsablauf eines EKGs (links) und Stress-EKGs (rechts)
Das EKG ist eine schnell durchführbare, einfache und kostengünstige Untersuchung, die
sehr zuverlässig Hinweise auf eine Erkrankung des Herzens aufzeigt. Daher wird dieses
Verfahren in der kardiologischen Diagnostik bei auftretendem Verdacht auf eine
Herzkrankheit auch stets als erstes angewendet.
Störungen in der Erregungsleitung, welche Rückschlüsse auf eine Erkrankung erlauben,
können so gesehen werden. Wie im oberen Teil von Abb. 3.6 dargestellt, werden beim
68
Die klinische kardiologische Fachabteilung
Mehrkanal-EKG bis zu 12 Elektroden an unterschiedlichen Positionen des Körpers
angebracht, die jeweils ein eigenes Signal, die sog. EKG-Ableitungen (I, II, III, aVR, aVL,
aVF, V1 - V6), liefern. Diese in mV gemessenen Signale werden meist auf Millimeterpapier
gegen die Zeit als Kurve dargestellt.
Auch Herzinfarkte und deren zeitlicher Verlauf können im EKG diagnostiziert werden. In den
unteren vier Bildern von Abb. 3.7 ist dies gezeigt. Wie im ersten Bild, welches ein normales
EKG-Signal eines Herzschlages zeigt, dargestellt, werden die "EKG-Zacken" (Hoch- und
Tiefpunkte der Signalkurve eines Schlages) mit P, Q, R, S und T bezeichnet. Im
Initialstadium direkt nach dem Infarkt zeigt das EKG-Signal (2. Bild von links) eine stark
gehobene T-Welle, wenige Stunden nach dem Infarkt (3. Bild von links) eine Hebung der
ST-Strecke und nach einigen Wochen (rechtes Bild) eine pathologische Q-Zacke und
negative T-Welle.
Abb. 3.7: Oben: Mehrkanal-EKG mit Beispiel für die 12 Ableitungen. Unten: Veränderungen des
EKG in den verschiedenen Stadien eines Herzinfarktes
Das EKG gibt jedoch meistens nur Hinweise auf die Erkrankung. Diese werden dann durch
eine folgende Untersuchung, meist Ultraschall, Herzkatheter oder EPU, abgesichert. Z. B.
beim Herzinfarkt zeigt das EKG nur, dass dieser vorliegt. Es kann jedoch nicht genau
festgestellt werden, welche Herzkranzgefäße verschlossen und erkrankt sind und somit
nicht entscheiden, welche Behandlung angemessen ist. Nur bei einigen Herzrhythmus-
69
Die klinische kardiologische Fachabteilung
störungen ist das EKG das ausschlagende diagnostische Verfahren, welches die Grundlage
für die folgende Therapie bildet. In diesem Fall ist dies entweder die medikamentöse
Behandlung der Rhythmusstörung oder die operative Implantation eines Schrittmachers.
Wie das EKG so ist auch die Ultraschalluntersuchung ein schnelles, kostengünstiges und
für den Patienten nicht belastendes diagnostisches Verfahren. Es setzt im Gegensatz zum
EKG jedoch ein sehr viel teureres Untersuchungsgerät und eine umfassendere Ausbildung
des Arztes voraus. Daher wird diese Untersuchung in der Regel vom Kardiologen in einer
Facharztpraxis oder im Krankenhaus durchgeführt und nicht vom Hausarzt.
Bei der Ultraschalluntersuchung wird durch eine Sonde ein Ultraschallsignal abgegeben,
welches von den unterschiedlichen Organen und Gewebeschichten unterschiedlich
reflektiert wird. Diese unterschiedlichen Reflektionen werden von der Sonde aufgezeichnet
und daraus das Ultraschallbild berechnet.
Am häufigsten wird in der Kardiologie das TTE (transthorakales Echo) durchgeführt, bei dem
die Sonde von außen in der Mitte des Thorax unterhalb der Rippen angesetzt wird. Durch
Drehen und Kippen der Sonde in unterschiedliche Positionen kann der Kardiologe die
gewünschte Schnittebene (vgl. Abb. 3.8) des Herzens darstellen. Dabei gibt es
Standardansichten wie den "Vierkammerblick", der sämtliche Herzkammern zeigt, oder den
"Zweikammerblick", welcher eine Herzhälfte zeigt. Es bedarf sehr viel Übung und
Fingerspitzengefühl durch den Untersucher, eine gute Position zur Visualisierung der
Hohlräume (Kammern und große Gefäße) des Herzens und der Herzklappen nur durch das
Ausrichten der Sonde zu finden. Insbesondere bei schlecht schallbaren Patienten (meist
bedingt durch hohe Signaldämpfung bei Übergewichtigen) kann ungeübten Ärzten das eine
oder andere diagnostisch relevante Detail entgehen. Daher ist eine gute Ausbildung durch
einen erfahrenen Facharzt vor Anwendung dieser Untersuchungsmethode sehr wichtig.
Abb. 3.8: Prinzip der Ultraschalluntersuchung und Ausrichtung der Sonde für die Standardansicht
des "Vierkammerblicks" (links) und "Zweikammerblick" (rechts).
70
Die klinische kardiologische Fachabteilung
Wie auch beim EKG gibt es unterschiedliche Variationen bei der Untersuchung:
•
TTE (s. o.): Die Untersuchung wird durch Ansetzen des Ultraschallkopfes von außen
an
den
Thorax
des
Patienten
durchgeführt.
Dies
ist
die
Standarduntersuchungsmethode beim Ultraschall.
•
TEE (transoesophageales Echo, auch als Schluckecho bezeichnet): Eine spezielle
Ultraschallsonde wird in die Speiseröhre des Patienten eingeführt und von innen die
Betrachtung des Herzens durchgeführt. Diese Methode ist zwar aufwendiger als das
TTE, produziert aber eine bessere Bildqualität, da der Schall, insbesondere bei
übergewichtigen Patienten, durch weniger Gewebe muss und die Rippen nicht im
Schallweg liegen.
•
Stressechokardiografie: Wie beim Stress-EKG wird zunächst die Untersuchung in
Ruhe durchgeführt. Dann wird der Patient in mehreren Stufen, meistens vier bis fünf,
bis zur Grenze seiner Leistungsfähigkeit belastet, indem er z. B. auf einem Fahrrad
gegen einen Widerstand tritt. In jeder Belastungsstufe wird das Herz im Ultraschall
betrachtet. So können Leistungsfähigkeit und Beweglichkeit von Herzmuskel und
Herzklappen unter Belastung abgeschätzt werden.
•
Gefäßdarstellung: Mit dem Ultraschall können auch die großen Arterien und Venen
des Körpers dargestellt werden.
Der grundsätzliche Ablauf einer Ultraschalluntersuchung kann Abb. 3.9 entnommen werden.
Im Ultraschall gibt es unterschiedliche Verfahren, die inzwischen von fast allen Geräten
unterstützt werden:
•
Farbdoppler: Durch die Nutzung des Dopplereffektes kann der Blutfluss dargestellt
werden. Durch unterschiedliche Farben wird sichtbar gemacht, ob das Blut zum
Schallkopf hin oder von ihm weg fließt.
•
M-Mode: Eindimensionale Darstellung einer Schnittebene zur Betrachtung von
Bewegungen über die Zeit
•
Harmonic Imaging: verbesserte
unterschiedlicher Schallfrequenzen
•
Kontrastmittelechokardiografie: Durch die Injektion eines Kontrastmittels, welches
aus kleinen Luft- oder Gasbläschen besteht, können Gefäße dargestellt werden.
Darstellung
des
Bildes
durch
Nutzung
71
Die klinische kardiologische Fachabteilung
Echo
vorbereiten
Patient abrufen
Vorbereitendes Gespräch,
Patient/Echo vorbereiten
Echo
vorbereiten
Patient abrufen
Vorbereitendes Gespräch,
Patient/Echo vorbereiten
Patientendaten
erfassen
Patientendaten
erfassen
In gewünschter
Projektion
schallen
Nein
Nein
In gewünschter
Projektion
schallen
Alle
Projektionen
durch?
Ja
Alle
Projektionen
durch?
Belastung
erhöhen
Ja
Nein
Patient
ausbelastet?
Ja
Befund schreiben, dabei
mit Patient besprechen
Filme / Bilder
archivieren
Befund schreiben, dabei
mit Patient besprechen
Patient zurück
schicken
Echo
nachbereiten
Filme / Bilder
archivieren
Patient zurück
schicken
Echo
nachbereiten
Abb. 3.9: Ablauf einer Ultraschalluntersuchung (links) und eines Stress-Echos (rechts)
In Abb. 3.10 ist eine TEE-Untersuchung bei einem Patienten mit schwerer
Mitralklappeninsuffizienz zu sehen. Im linken oberen Bild ist eine gute Öffnung der
Mitralklappe mit freiem Blutfluss vom Vorhof in die Kammer zu sehen. Dieser Fluss ist an
72
Die klinische kardiologische Fachabteilung
dem blauen Farbjet im unteren linken Bild zu erkennen. Auf den rechten Bildern ist der
Klappenschluss in der Systole des Herzens zu erkennen. Das hintere Mitralsegel kommt
nicht weit genug nach vorne, wodurch eine Lücke zwischen den Segeln entsteht, und die
Klappe nicht vollständig schließt. Dadurch kommt es zu einem turbulenten Rückfluss des
Blutes von der Kammer in den Vorhof. Dies ist im unteren rechten Bild in der
Farbdarstellung als gelbblaue Farbwolke sichtbar.
Segel der
Mitralklappe
Linker Vorhof
Linker Vorhof
Segel der
Mitralklappe
Lücke
Linke Kammer
Mitralklappe
Linker Vorhof
Linke Kammer
Linke Kammer
Mitralklappe
Linker Vorhof
Linke Kammer
Abb. 3.10: Multimediale Daten einer Ultraschalluntersuchung. Die oberen beiden Bilder wurden ohne
und die unteren Bilder mit Farbdoppler durchgeführt. Links ist jeweils die Diastole (Füllung
des Ventrikels) und rechts die Systole (Kontraktion und Entleerung) zu sehen.
73
Die klinische kardiologische Fachabteilung
Die Ultraschalluntersuchung ist das Verfahren der Wahl zur Beurteilung der Funktionalität
der Herzkammern, der Herzklappen und zum Auffinden von Tumoren, Myxomen und
Perikardergüssen. Diese Ultraschalldiagnosen können direkt die Indikation zu einer der
folgenden Therapien sein:
•
Medikamentöse Therapie von Erkrankungen des Herzmuskels oder der Herzklappen
•
Operativer Ersatz einer oder mehrerer erkrankter Herzklappen
•
Operativer Verschluss eines ASD, VSD oder anderer Fehlbildung des Herzseptums,
•
Operative Entfernung von Thromben, Myxomen oder Tumoren
•
Perikardpunktion zur Entfernung von Perikardergüssen.
Daneben wird die Technik der Ultraschalluntersuchung bei Kindern und Jugendlichen
eingesetzt um angeborene Fehlstellung von Herzklappen oder großen Gefäßen abzuklären.
Hier ist insbesondere die schonende Untersuchungsmethode, welche auf Röntgenstrahlen
verzichtet, von großem Vorteil.
Wie Ultraschall und EKG so ist auch das MR eine für den Patienten sehr schonende
Untersuchung. Die Kosten für das hierfür notwendige medizinische Großgerät liegen jedoch
mit mehreren Millionen € sehr viel höher. Zusätzlich sind die Abmessungen des Geräts so
groß, dass eine feste Installation in einem eigenen Raum benötigt wird. Außerdem ist die
Bedienung sehr komplex, so dass es nur von speziell fortgebildeten Fachärzten bedient
werden kann. Daher sind MRs meist nur in größeren kardiologischen Abteilungen in Kliniken
installiert, wo die Nutzung des Geräts häufig mit der Radiologie geteilt wird.
Grundsätzlich lassen sich in MR und Ultraschall ähnliche Krankheitsbilder befunden, die
gewonnenen Bilder und Filme bieten jedoch eine andere Darstellung. So ist bei dem in Abb.
3.11 vorgestellten Fall im MR deutlich eine Narbe zu erkennen. Im Ultraschall war bei
diesem Patienten nur die in den oberen Bildern gezeigte Wandbewegungsstörung zu
erkennen. Zur weiteren Abklärung wurde noch ein MR durchgeführt, bei dem eine
wandverdünnte Narbe der Herzvorderwand und ein schalenförmiger Thrombus
diagnostiziert wurden. Nach Gabe von Kontrastmittel färben sich das Blut und der
Herzmuskel an, der nicht durchblutete Thrombus bleibt schwarz und ist somit deutlich zu
erkennen. 10 Minuten nach Kontrastmittelgabe (letztes Bild unten rechts) verbleibt das
Kontrastmittel in der Herzmuskelnarbe (late enhancement), welche dadurch als dünner
weißer Streifen sichtbar wird.
74
Die klinische kardiologische Fachabteilung
Narbe
Thrombus
Thrombus
Abb. 3.11: MR-Bilder: Oben: Diastole und Systole eines Herzens mit wandverdicktem Herzmuskel
und deutlicher Wandbewegungsstörung im Vorderwandbereich. Unten: Thrombus und
Herzmuskelnarbe, links direkt und rechts zehn Minuten nach Kontrastmittelgabe (late
enhancement)
Weiterhin kann mit dem MR eine 3D-Rekonstruktion durchgeführt werden. Dabei werden die
einzelnen Bilder, die durch den um den Patienten rotierenden Sensor, aufgezeichnet werden
zusammengesetzt. In Abb. 3.12 ist eine Aortenisthmusstenose zu sehen.
75
Die klinische kardiologische Fachabteilung
Aortenisthmusstenose
Armarterie
Umgehungsgefäße
Aorta
Niere
Abb. 3.12: 3D-Rekonstruktion im MR: Verengung der Hauptschlagader direkt nach Abgang der linken
Armarterie. Die Durchblutung der unteren Körperhälfte erfolgt über ausgeprägte
geschlängelte Umgehungskreisläufe.
Der typische Ablauf einer MR-Untersuchung kann Abb. 3.13 entnommen werden.
Die MR-Technologie befindet sich zurzeit in einer dynamischen Entwicklung, die leider
momentan nur eine relativ geringe Auflösung produziert. Es wird jedoch davon
ausgegangen, dass Geräte der übernächsten Generation in etwa fünf Jahren so gute
Ergebnisse liefern, dass alle Koronararterien dargestellt werden können, und so die
Diagnostik der Herzkranzgefäße durch den Herzkatheter teilweise abgelöst werden kann.
76
Die klinische kardiologische Fachabteilung
Derzeit wird durch das MR in erster Linie die Indikation zu Operationen an der Aorta oder zu
operativen Korrekturen angeborener Fehlstellungen der großen Gefäße oder des Herzens
gestellt.
Patient abrufen
MR vorbereiten
Vorbereitendes Gespräch,
Patient vorbereiten
MR einstellen,
Patientendaten
eingeben
MR-Aufnahme
erstellen
Ja
Film-/Bilddaten
archivieren
Alle
Projektionen
durch?
Einstellung des
MR ändern
Nein
Patient zurück
schicken
Filme / Bilder
auswerten
MR
nachbereiten
Befund
schreiben
Abb. 3.13: Normaler Ablauf einer MR-Untersuchung
77
Die klinische kardiologische Fachabteilung
Das zurzeit wichtigste diagnostische Verfahren in der Kardiologie ist die
Herzkatheteruntersuchung. So steht in den deutschen Leitlinien der deutschen
Gesellschaft für Kardiologie unter [HAB04]:
"Die Koronarangiographie ist derzeit der "Goldstandard" zur Diagnose und
Schweregradbeurteilung der koronaren Herzerkrankung. Angiographische Befunde
bilden die Basis für die Indikation zur perkutanen oder operativen Revaskularisation und
erlauben eine weitere Risikobeurteilung."
Bei der Herzkatheteruntersuchung handelt es sich um ein invasives Verfahren, bei dem
unter lokaler Anästhesie ein kleiner Schnitt in der Leiste (gelegentlich auch der Armarterie)
zum Einführen des Katheters durchgeführt wird (vgl. Abb. 3.14). Durch dieses Loch wird
dann eine Schleuse in die Beinschlagader (Arteria femoralis) eingeführt. Diese Schleuse
bildet den Zugang über den Katheter durch die Beckengefäße und die Aorta bis zum Herzen
vorgeführt werden können. Durch die von innen hohlen Diagnostikkatheter kann gezielt
Kontrastmittel, welches keine Röntgenstrahlen durchlässt, in die Koronararterien und die
Herzkammern injiziert werden. Damit kann der Blutfluss in den Arterien und den
Herzkammern als Film dargestellt werden. Zusätzlich können Blutdruck und
Sauerstoffsättigung des Blutes gemessen werden.
Weg des Katheters
Punktionsstelle
Arteria radialis
Punktionsstelle
Arteria femoralis
Aorta
Abb. 3.14: Technik der Herzkatheteruntersuchung
Ergebnis der Herzkatheteruntersuchung sind Filme, die die Dynamik des Blutflusses in den
Koronararterien und Herzkammern darstellen und pathologische Veränderungen der
Arterien (vgl. Abb. 3.18) und Herzwände aufzeigen. In Abb. 3.15 sind neun ausgewählte
Bilder (die jeweilige Bildnummer innerhalb des gesamten Filmes ist unter dem Bild
angegeben) eines Filmes des linken Ventrikels, der an einer Kontraktionsstörung leidet,
dargestellt. Es sind zwei Herzzyklen (ca. 3,5 Sekunden) zu erkennen, die jeweils aus
78
Die klinische kardiologische Fachabteilung
Diastole und Systole bestehen. Das durch den Katheter injizierte Kontrastmittel macht den
Blutfluss im Röntgenbild sichtbar, welcher wiederum die Umrisse des linken Ventrikels
hervortreten lässt. Hier ist eine Hypokinesie der Hinterwand (unten links) und eine Akinesie
im Bereich der Lateralwand (oben rechts) zu erkennen. Zusätzlich können die Volumina der
Herzkammer in gefülltem und entleertem Zustand extrapoliert werden. Für diesen Patienten
ergibt sich eine Ejektionsfraktion von 50 %, d.h. bei jedem Herzschlag werden 50 % des
angesaugten Blutes wieder in den Körper gepumpt. Dies entspricht einer leicht
eingeschränkten Funktionalität des linken Ventrikels.
Neben der medikamentösen Belastung ist der Patienten bei dieser Untersuchung Röntgenstrahlung ausgesetzt. Daher wird dieses Verfahren nur angewendet wenn ein begründeter
Verdacht auf eine Erkrankung des Herzens besteht, welcher durch ein anderes Verfahren,
wie z. B. EKG oder Ultraschall, abgesichert ist. Das Ergebnis der Untersuchung ist, im
Gegensatz zu den anderen vorgestellten Verfahren, bzgl. des Zustands von
Koronararterien, peripheren Gefäßen und Funktionalität der Herzkammern sehr zuverlässig.
Katheter
1. Diastole: Bild Nr. 38
1. Diastole: Bild Nr. 51
1. Diastole: Bild Nr. 63
Akinesie
Hypokinesie
1. Systole: Bild Nr. 67
2. Diastole: Bild Nr. 74
2. Diastole: Bild Nr. 85
2. Systole: Bild Nr. 91
2. Systole: Bild Nr. 96
2. Systole: Bild Nr. 101
Abb. 3.15: Ausgewählte Bilder aus einem Herzkatheterfilm, die den linken Ventrikel zeigen. Es sind
eine Hypokinesie der Hinterwand und eine Akinesie der Lateralwand zu erkennen.
79
Die klinische kardiologische Fachabteilung
Der Ablauf des diagnostischen Herzkatheters kann Abb. 3.16 entnommen werden. In dieser
Abbildung ist auch die Durchführung des therapeutischen Herzkatheters enthalten, welcher
bei gegebener Indikation in einer Sitzung durchgeführt werden kann. Auf dieses wichtigste
therapeutische Verfahren der Kardiologie wird im folgenden Abschnitt näher eingegangen.
HK-Labor
vorbereiten
Patient abrufen
Vorbereitendes Gespräch,
Patient vorbereiten
Patientendaten
erfassen
Nein
Diagnostik
durchführen
Nur Dilatation?
Ja
Indikation
zur primavista
Dilatation?
Ja
Dilatation
durchführen
Nein
Patient nachbereiten
(insb. Abdrücken)
Daten auswerten, Nachbesprechung, Procedere festlegen
Befund
schreiben
HK-Labor
nachbereiten
Filme / Bilder
archivieren
Befund mit Patient
besprechen
Patient zurück
verlegen
Abb. 3.16: Ablauf der Herzkatheteruntersuchung. Das therapeutische Verfahren der Dilatation ist
durch die gestrichelten Linien hervorgehoben und entfällt bei einem rein diagnostischen
Herzkatheter.
80
Die klinische kardiologische Fachabteilung
Das letzte hier vorgestellte diagnostische Verfahren ist die EPU. Diese dient ausschließlich
der genauen Abklärung von Rhythmuserkrankungen. Wie beim Herzkatheter werden unter
Röntgenkontrolle Katheter über die Leiste bis ins Herz vorgeschoben. Dies geschieht bei der
EPU jedoch meist über die Venen. Bei den Kathetern handelt es sich um Elektrodenkatheter
mit denen gezielt Teile des Herzens elektrisch stimuliert werden können. So kann genau Art
und Lokalisation der Herzrhythmusstörungen gefunden werden.
Da diese Untersuchung häufig dann angewendet wird, wenn die Herkunft der Arrhythmien
unbekannt ist, ist es sehr schwer die Dauer einer EPU abzuschätzen. Diese kann weniger
als 30 Minuten bis zu mehreren Stunden dauern.
3.2.4 Die wichtigsten therapeutischen Verfahren in der Kardiologie
Basierend auf den Ergebnissen der Diagnostik wird eine Therapie aus einer der folgenden
Gruppen angewendet:
•
Konservative Behandlung mit Medikamenten
•
Kardiologische Intervention im Herzkatheterlabor.
Auf die operativen Verfahren, wie z. B. Bypass, Herzklappenersatz oder Verschluss eines
Septumdefektes, wird hier nicht weiter eingegangen, da sie ausschließlich in der
Herzchirurgie durchgeführt werden.
Wichtig ist jedoch, dass die Patienten nach oder während des operativen Eingriffs auch von
Ärzten der Kardiologie überwacht und in jedem Fall nach der Entlassung aus der
Herzchirurgie an ein kardiologisches Fachzentrum, sei dies nun die Kardiologie in der
eigenen Klinik, eine Rehabilitationseinrichtung oder ein niedergelassener Facharzt für
Kardiologie, überwiesen werden (vgl. Abb. 3.16).
Zudem wird versucht eine medikamentöse Behandlung durchzuführen, da diese für den
Patienten weniger belastend als eine Operation oder Intervention ist. Hierbei wird in der
Klinik ein Behandlungsplan vorgeschlagen, der mit dem Patienten besprochen und den
betreuenden externen Ärzten, meist Hausarzt und einweisender Kardiologe, mitgeteilt wird.
Der Patient stellt sich dann in regelmäßigen Intervallen, meist alle sechs Monate, oder bei
Eintreten besonderer kardialer Ereignisse bei den betreuenden Ärzten vor. Sollten sich hier
Verschlechterungen des Zustandes zeigen, so wird der Patient wieder in das Krankenhaus
eingewiesen (vgl. Abb. 3.17).
81
Die klinische kardiologische Fachabteilung
Abb. 3.17: Kardiologische Behandlungskette: bei Herzpatienten handelt es sich meistens um
chronisch kranke Menschen, deren gesundheitlicher Zustand regelmäßig kontrolliert wird.
Bei Verschlechterung wird zum nächsten, höher spezialisierten Facharzt überwiesen und
von diesem nach erfolgreicher Behandlung wieder zurück zum Hausarzt von wo die Kette
wieder von vorne beginnt.
Das wichtigste therapeutische Verfahren in der Kardiologie ist die Intervention im
Herzkatheterlabor, welche auch als Dilatation oder Koronarangioplastie (PTCA =
percutaneous transluminal coronary angioplasty) bezeichnet wird. Mit diesem Verfahren
können wie bei der Bypass-Operation Gefäß–verengungen und –verschlüsse wieder
eröffnet werden. Jedoch ist diese Therapie bei weitem schonender für den Patienten, da
nicht der gesamte Brustkorb geöffnet werden muss und das Herz nicht stillgelegt und somit
das Blut nicht durch die Herz-Lungen-Maschine zur Aufrechterhaltung des Kreislaufs
gepumpt werden muss.
Ziel der kardiologischen Intervention ist die Beseitigung von Stenosen in den Arterien. Dafür
wird wie beim diagnostischen Herzkatheter über eine arterielle Schleuse in der Leiste ein
Führungskatheter bis zum Herzen vorgeschoben. Dieser kann vom Kardiologen durch
Ziehen, Schieben und Drehen in die Herzkranzgefäße navigiert werden. Unter
Röntgenkontrolle wird der Draht in das erkrankte Gefäß eingeführt und über die Engstelle
bis in die Gefäßperipherie vorgeführt. Entlang des Drahtes wird ein weiterer Katheter wie auf
einer Führungsschiene für die eigentliche Behandlung bis zur Stenose gebracht (vgl. Abb.
3.18 und 3.19).
82
Die klinische kardiologische Fachabteilung
Katheter
Ballon
Stenose
Stent
Arterie
Abb. 3.18: Schematische Darstellung der Dilatation der Herzkranzgefäße (PTCA), hier die direkte
Stentimplantation: Nach dem Aufdehnen verbleibt der Stent als Stütze in der Arterie und
verhindert so das erneute Zusammenfallen des Gefäßes. Moderne Stentsysteme können
zusätzlich beschichtet sein und als Medikamententräger fungieren.
Zum Eröffnen des Gefäßes gibt es unterschiedliche Verfahren. Das häufigste Verfahren ist
die Ballondilatation in Kombination mit einer Stentimplantation. Dazu wird ein passender
Ballonkatheter im Bereich der Stenose positioniert und mit einem Druck von 8 – 20 bar
aufgeblasen. Dadurch wird das stenotische Material in die Gefäßwand "platt" gedrückt und
das volle Gefäßlumen wieder hergestellt. Nachfolgend wird eine Gefäßstütze, ein so
genannter Stent, eingebracht, welche auf einem Ballon montiert ist und mit einem Druck von
bis zu 20 bar in die Gefäßwand gepresst wird. Dadurch werden Verkalkungen und anderes
stenotisches Material in der Gefäßwand fixiert, diese geglättet und ein Zusammenfallen der
Arterie verhindert. Grosse medizinische Studien (vgl. [ABH00]) belegen die Überlegenheit
der Stentimplantation gegenüber der reinen Ballondilatation.
Ist die Stenose gut zu erreichen, z. B. im Ostium oder proximalen Abschnitt der Kranzarterie
oder bei glatten, nicht geschlängelten Gefäßen, so kann eine direkte Stentimplantation ohne
vorherige Vordehnung mit einem Ballon durchgeführt werden. Der Vorteil liegt hier in den
verminderten Kosten und einer verkürzten Behandlungsdauer.
83
Die klinische kardiologische Fachabteilung
Katheter
Stenose
Arterie (RCA)
StentMarker
Entfalteter
Ballon
Abb. 3.19: Originalbilder einer PTCA: Oben 90%ige Stenose der rechten Kranzarterie (RCA) vor der
Behandlung. Unten: Links Positionierung des Stents im Bereich der Stenose, in der Mitte
Aufdehnung des Ballons, rechts Ergebnis der direkten Stentimplantation. Es zeigt sich ein
glatter Gefäßverlauf bei dem die Stenose vollständig beseitigt wurde.
84
Die klinische kardiologische Fachabteilung
Stentsysteme bieten seit einigen Jahren zusätzlich den Vorteil, dass sie beschichtet werden
können. Diese Beschichtung kann recht einfach sein und nur aus einem Material bestehen,
welches erneute Ablagerung von atherosklerotischem Material verhindert. Es können aber
auch Medikamente als Beschichtung zum Einsatz kommen. Diese auch als Drug Eluting
Stents (DES) bezeichneten, sehr teuren Implantate stützen nicht nur das Gefäß sondern
geben zusätzlich kontinuierlich geringe Mengen unterschiedlicher Medikamente direkt an
der erkrankten Stelle ab. Dies soll das erneute Auftreten von Stenosen und/oder Thromben
verhindern. Hier liegt derzeit das größte Problem bei der Stentimplantation (s. [MBGH04]).
Nach [AlSu04] kommt es in 15 bis 50% aller Fälle nach einer erfolgreichen Stentimplantation
zu einer sog. Rezidivstenose. Dies beschreibt die erneute Stenosierung eines kardiologisch
interventionell behandelten Gefäßabschnittes. Besonders die Behandlung der sog. In-StentRestenosen, die im Bereich implantierter Stents auftreten, ist komplex und kostenintensiv.
Hier sind die DES ein großer Hoffnungsträger, da in klinischen Studien bereits eine
hochsignifikante Reduktion der Restenoserate nachgewiesen werden konnte. Die
Empfehlung der DES als Standardbehandlungsverfahren wird daher zurzeit durch die DGK
(Deutsche Gesellschaft für Kardiologie, siehe [DGK]) intensiv diskutiert. Erste Studien
belegen die Überlegenheit des DES gegenüber dem herkömmlichen Stent. So konnte z. B.
im Rahmen der Endeavor-Stent-Studie (vgl. [Rut05]) die Restenoserate auf unter 5 % durch
den Einsatz eines DES der Fa. Medtronic gedrückt werden.
Dies zeigt, dass es sich bei der PTCA zwar um ein bewährtes und etabliertes Verfahren
handelt,
welches
aber
durch
ständige
Verbesserungen
basierend
auf
Forschungsergebnissen weiter entwickelt wird und somit auch nach über 25 Jahren des
routinemäßigen Praxiseinsatzes einer steten Dynamik unterworfen ist.
Bei besonderen Stenosemorphologien kommen seltener auch andere Verfahren zum
Einsatz (vgl. Tab. 3.7 und Abb. 3.20):
•
Rotablation: Bei der Rotablation wird mit einer Miniaturfräse, die mit über 10.000
U/min rotiert, das stenotische Material abgefräst. Dieses Verfahren kommt
insbesondere bei harten Verkalkungen zum Einsatz, hat jedoch den Nachteil, dass
das abgelöste Material in die Gefäßperipherie abtreibt und dort ungewollte
Komplikationen auslösen kann.
•
Laseratherektomie: Wie bei der Rotablation wird das stenotische Material zerstört, in
diesem Fall mit einem Laser. Dieses Verfahren kommt fast gar nicht mehr zum
Einsatz.
•
Protectiondevice: Bei diesem Verfahren wird verhindert, dass thrombotisches
Material in die Gefäßperipherie gelangt. Diese werden über einen Führungskatheter
hinter die Stenose in die Gefäßperipherie gebracht und dort entfaltet. Der
aufgefaltete Mikrofilter kann dann kleinste Teilchen, die z. B. beim Fräsen mit dem
Rotablator entstehen, auffangen und so verhindern, dass dieses Material in dünnere
85
Die klinische kardiologische Fachabteilung
Gefäße gelangt und diese verstopft. Nach dem Eingriff kann das Protektionssystem
zusammengefaltet und mit dem Fremdmaterial aus der Arterie entfernt werden.
•
Brachytherapie: Nach der Dilatation wird ein spezieller Deliverykatheter eingeführt,
der radioaktives Material zur Strahlentherapie in das Gefäß bringt. Dieser Eingriff
wird in Anwesenheit eines Arztes mit Fortbildung zur Strahlentherapie (meist
Radiologe) durchgeführt.
Abb. 3.20: Ausgewählte zusätzliche Maßnahmen bei Interventionen: auf den beiden linken Bildern ist
ein Rotablator abgebildet. Rechts sind zwei unterschiedliche Protektionssysteme zu
sehen.
Das größte Problem für den Langzeiterfolg von Koronarangioplastien sind die Restenosen.
Dies sind erneute atherosklerotische Verengungen der Gefäße, die insbesondere an den
Stellen auftreten, die vorher therapeutisch angegangen wurde. Die Restenoserate liegt bei
der reinen Ballondilatation bei ca. 25 % und wird durch den Einsatz des Stents auf
durchschnittlich 18 % verringert. Durch den Einsatz beschichteter Stentsysteme oder
Systemen, die Medikamente freisetzen, kann die Restenoserate auf 3 % verringert werden.
Diese Produkte sind aber erst seit wenigen Jahren verfügbar, so dass noch keine
Langzeitstudien vorliegen. Zusätzlich sind sie bis zu zehnmal teurer als konventionelle
Stents.
Es ist daher für den Kardiologen wichtig, vor der PTCA möglichst umfassende Informationen
über den aktuellen Fall zu erhalten. Dies sollte zeitnah im Herzkatheterlabor geschehen mit
der Möglichkeit, während der Behandlung diagnostische Vorfilme aus Ultraschall,
Herzkatheter oder MR über die Monitore im Herzkatheterlabor einzublenden. Dadurch wird
der behandelnde Arzt bei schwierigen Eingriffen besser in die Lage versetzt, das geeignete
Material für den Eingriff zu finden. Es gibt derzeit mehrere hundert unterschiedliche Ballons
86
Die klinische kardiologische Fachabteilung
und Stents am Markt, die sich in Durchmesser, Länge, Werk- und Wirkstoffen
unterscheiden.
Interventionelles
Verfahren
Erstmals
angewandt
Anzahl
Ges.
Anteil in %
2001 2002 2003
Ges.
2001
2002
2003
Ballondilatation
12.12.1990 4.591
340
227
226
30,27
17,67
14,45
14,69
Ballondil. + Stent
17.07.1991 6.990
861
821
921
46,08
44,75
52,26
59,88
Direkte
Stentimplantation
19.03.1997 3.341
641
437
290
22,03
33,32
27,82
18,86
Protectiondevice
09.03.2001
89
26
29
34
0,59
1,35
1,85
2,21
Rotablation
19.01.1995
24
3
1
1
0,16
0,16
0,06
0,06
Atherektomie
14.11.1994
9
0
0
0
0,01
0
0
0
Brachytherapie
22.02.2001
65
23
22
20
0,48
1,20
1,40
1,30
PTA
01.04.1999
41
8
14
9
0,27
0,42
0,89
0,59
PTA + Stent
25.06.1997
108
22
20
27
0,71
1,14
1,27
1,76
Tab. 3.7:
Verteilung unterschiedlicher Interventionsverfahren in der Kardiologie der Klinikum
Oldenburg gGmbH. Insgesamt wurden von 1990 bis 2003 12.741 therapeutische
Herzkatheter durchgeführt bei denen 15.168 Gefäßsegmenten dilatiert wurden. Dies
entspricht 1,19 behandelten Gefäßen pro Intervention.
Mit der Hilfe von Kathetern können unter Röntgenkontrolle auch weitere Eingriffe an Herz
und peripheren Gefäßen im Herzkatheterlabor vorgenommen werden:
•
Dilatation von peripheren Gefäßen (PTA = percutaneous transluminal angioplasty):
der Ablauf dieser Therapie ist identisch zur Koronarangioplastie, nur dass in im Fall
der PTA nicht Stenosen in der Herzkranzgefäßen sondern in den großen Arterien
des Körpers beseitigt werden. Insbesondere bei den Arterien im Hals (A. carotis und
A. subclavia), der Aorta, den Nierenarterien (A. renalis) und den Arterien der Becken/Beinetage (A. femoralis) wird dieses Verfahren angewendet.
•
Verschluss von Septumdefekten: Wenn die Wände zwischen den Herzkammern
Löcher aufweisen, kann mit dem Katheter ein Schirmchen bis zu einem solchen
Loch, welches als Septumdefekt bezeichnet wird, vorgebracht werden. Dort wird der
Schirm hinter dem Loch entfaltet und beim Zurückziehen des Katheters im Loch
verankert.
•
Ablationen: Durch den Einsatz von Elektrodenkathetern kann gezielt Gewebe mit
Hochfrequenzstrom verödet werden. Dadurch können bei Herzrhythmusstörungen
die Bahnen, auf denen falsche elektrische Signale laufen, korrigiert werden.
87
Die klinische kardiologische Fachabteilung
3.3 Die kardiologische Behandlungskette
Nachdem im vorangegangenen Abschnitt dargestellt wurde, welche Krankheiten mit
welchen Verfahren in der Kardiologie behandelt werden, wird jetzt darauf eingegangen, in
welcher Reihenfolge und unter welchen Voraussetzungen diese normalerweise durchgeführt
werden. Es wird nicht nur der Ablauf eines Krankenhausaufenthaltes in der Kardiologie,
sondern die komplette Behandlungskette, die der Patient durchläuft, mit allen beteiligten
externen Institutionen vorgestellt. Dies ist bei kardiologischen Erkrankungen von besonderer
Bedeutung, da es sich bei Herzerkrankungen um chronische Erkrankungen handelt, die erst
ab einem gewissen Alter auftreten, dann aber meist bis zum Tod des Patienten über viele
Jahre hinweg von unterschiedlichen Ärzten behandelt werden. Damit die beteiligten
Mediziner in möglichst konsistenter Weise zusammen arbeiten können, ist ein guter
Informationsaustausch zwischen ihnen
notwendig.
Dazu muss
aber
jeder
Behandlungsschritt immer im Gesamtbild der Erkrankung gesehen und dokumentiert
werden. Dies ist besonders für die Krankenhausaufenthalte wichtig, da hier die besonders
schweren Symptome der chronischen Erkrankung behandelt werden.
Normalerweise besucht der Patient bei auftretenden Beschwerden oder im Rahmen einer
Routineuntersuchung zunächst den Hausarzt. Bei V. a. (Verdacht auf) eine Herzerkrankung
überweist dieser den Patienten zur weiteren Abklärung an einen Facharzt für Kardiologie
oder Innere Medizin. Die häufigste Indikation ist hier "V. a. KHK" (Verdacht auf koronare
Herzerkrankung), welche durch den niedergelassenen Arzt meistens durch typische
Symptome die der Patient zeigt, wie z. B. "Druckgefühl in der Herzgegend" oder "Atemnot ".
Bei Erhärtung des Verdachtes und/oder weiterem Handlungsbedarf, erfolgt die Überweisung
an eine Klinik oder einen niedergelassenen Kardiologen mit Herzkatheterlabor. Im
Herzkatheter wird eine exakte Diagnose der Herzerkrankung gestellt und das weitere
therapeutische Vorgehen entschieden. Der Patient wird meistens nach der Therapie nach
Hause entlassen, in einem Viertel der Fälle jedoch einer herzchirurgischen Operation
zugeführt, die meistens vor der Entlassung noch einen Aufenthalt in einer
Rehabilitationsklinik nach sich zieht. Ist der Patient wieder zu Hause wird er weiter vom
Hausarzt oder niedergelassenen Facharzt betreut und der Versorgungskreis der
Behandlungskette schließt sich. Im Notfall kann die stationäre Einweisung auch durch den
Notarzt erfolgen. Die grundsätzliche Behandlungskette ist in Abb. 3.17 dargestellt.
In der Klinik wird zunächst mit diagnostischen Maßnahmen, die kostengünstig und für den
Patienten nicht belastend sind, eine vorläufige Diagnose gestellt. Dabei wird der Patient
ständig stationär betreut und medikamentös behandelt. Bei besonders schweren Fällen
kann dies auch auf der Intensivstation geschehen. Soweit möglich werden alle relevanten
Voruntersuchungen gemacht und bei den meisten Patienten mit Hilfe eines Herzkatheters
die exakte kardiologische Diagnose gestellt. Im Folgenden werden die Patienten dann
entweder innerhalb der Kardiologie medikamentös oder kardiologisch-interventionell weiter
behandelt oder in die Herzchirurgie zur Operation überwiesen.
88
Die klinische kardiologische Fachabteilung
Eine vergleichende Analyse der durchgeführten Prozesse in den einzelnen
leistungserbringenden Abteilungen der Kardiologie zeigt, dass der Arbeitsablauf immer nach
demselben Grundschema abläuft:
•
Planung des Untersuchungsablaufs und der durchzuführenden Tätigkeiten anhand
der Krankengeschichte und bereits vorliegender Untersuchungsergebnissen
•
Vorbereitung der notwendigen Geräte und Räumlichkeiten für die Untersuchung
•
Abruf des Patienten und soweit möglich Einweisung des Patienten
•
Durchführung des medizinischen Eingriffs
•
Auswertung und Dokumentation
•
Besprechung des Ergebnis mit dem Patienten und ggf. mit weiteren Ärzten
•
Rückverlegung des Patienten
•
Nachbereitung der notwendigen Geräte und Räumlichkeiten.
Diese variieren aber stark in Komplexität und damit auch in der für den Eingriff benötigten
Zeit (vgl. Tab. 3.8). Als Grundlage für die Berechnung der Zeiten wurden die Daten der
kardiologischen Datenbank der Klinikum Oldenburg gGmbH genommen. Die Korrektheit der
Minimal- und Maximalzeiten ist nach Ansicht der Fachärzte fraglich, denn es können hier
Erfassungsfehler vorliegen. In diesem Fall sind die Werte in Tab. 3.8 in Klammern
geschrieben. Mittelwerte (Ø) und Standardabweichungen können aber als sehr realistisch
angesehen werden, da die zu Grunde liegende Datenbasis über mehr als 10.000
Untersuchungen verfügt und hier einige "Ausreißer" statistisch nicht von Belang sind. Als
Grundregel gilt hier "Je höher die Relevanz des Verfahrens innerhalb der Behandlungskette
ist, desto komplexer und zeitintensiver ist es".
Kardiologisches Verfahren
EKG
Min.
Max.
Ø
Standardabw.
5
15
10
5
50
70
60
10
Ultraschall (TTE)
5
(177,8)
25,4
18,7
Ultraschall (TEE)
10,7
173,8
58,5
45,4
Stress-Echo
32,2
118
48,2
19,1
MR
(10)
144,8
48,1
31,7
10
(118,6)
28,1
13
20,1
(164)
46,8
18,7
Stress-EKG
Diagnostischer Herzkatheter
Therapeutischer Herzkatheter (PTCA)
Tab. 3.8:
Untersuchungszeiten in Minuten der wichtigsten kardiologischen Maßnahmen.
Abgebrochene Maßnahmen wurden nicht betrachtet. Die Zeiten für EKG und Stress-EKG
wurden durch Befragung des medizinischen Fachpersonals ermittelt, da hier keine
auswertbaren Zahlen in digitaler Form vorlagen.
89
Die klinische kardiologische Fachabteilung
Bei jeder dieser Untersuchungen kann es zu unvorhergesehenen Ereignissen,
Komplikationen und Notfällen kommen. Daher muss eingeplant werden, dass die
Untersuchung jederzeit abgebrochen werden kann. Im Fall des Herzkatheters muss
zusätzlich eingeplant werden, dass nach der Diagnostik in der gleichen Sitzung eine
Dilatation durchgeführt wird. Diese als "einzeitige" oder "primavista" PTCA bezeichnete
Therapie wird sehr häufig durchgeführt, weil sie zum einen für den Patienten schonender ist,
da die Behandlungszeit kürzer als bei zwei Eingriffen ist, und zum anderen die Kosten
niedriger sind. In Tab. 3.9 sind die Häufigkeiten von Komplikationen und Wechsel der
Behandlungsmethode aufgelistet.
Kardiologisches Verfahren
Komplikationen
Wechsel
EKG
< 0,1 %
1%
Stress-EKG
< 0,1 %
0%
0,15 %
1%
< 0,1 %
0%
Diagnostischer Herzkatheter
1,19 %
25,69 %
Therapeutischer Herzkatheter (PTCA)
2,40 %
0%
Ultraschall
MR
Tab. 3.9:
Häufigkeiten von Komplikationen und Wechsel der Therapien bei ausgewählten
kardiologischen Verfahren der Kardiologie in der Klinikum Oldenburg gGmbH
3.4 Aktueller Stand kardiologischer Leistungen in Deutschland
Nach [Bru04] waren in Deutschland am Ende des Jahres 2003 (Stichtag 31.12.2003) in den
Kliniken 3.059 Kardiologen beschäftigt. Diese erbrachten in 368 kardiologischen Zentren mit
555 Linksherzkatheter-Messplätzen (1,5 Messplätze pro Zentrum) insgesamt 655.512
diagnostische Linksherzkatheter-Untersuchungen und 222.668 therapeutische Maßnahmen
(PTCAs).
Dazu kommen die kardiologischen Leistungen, welche durch die 2.126 niedergelassenen
Kardiologen erbracht wurden. Diese führten 119.432 diagnostische LinksherzkatheterUntersuchungen und 17.143 therapeutische Maßnahmen (PTCAs) durch. Hieraus ist
ersichtlich, dass derzeit der Schwerpunkt der kardiologischen Versorgung in den klinischen
Fachabteilungen zu sehen ist.
Der Trend zeigt ein stetiges Wachstum in allen Bereichen der kardiologischen Versorgung.
So gab es im Jahr 1990 in Deutschland nur 234 Linksherzkatheter-Messplätze, welche nur
etwa 30 % der Leistungen des Jahres 2003 durchführten (vgl. Abb. 3.21).
90
Die klinische kardiologische Fachabteilung
Anzahl Leistungen
700000
Diagnostik (Links-HK)
Therapie (PTCA)
600000
Herzchirurgische OPs
500000
400000
300000
200000
100000
0
90
91
92
93
94
95
96
97
Jahr
98
99
00
01
02
03
Abb. 3.21: Entwicklung kardiologischer und herzchirurgischer Leistungen für Herzpatienten in den
Jahren 1990 bis 2003 nach [Bruck04]
Interessant ist hier auch ein Vergleich mit dem Wachstumstrend in der Herzchirurgie. Hier
gab es zwar auch einen starken Anstieg der Operationszahlen seit 1990, jedoch ist seit
1998 eine Stagnation, seit 2000 sogar ein leichter Rücklauf der herzchirurgischen
Operationszahlen zu erkennen (vgl. Abb. 2.9). In einer Stellungnahme der Herzchirurgen in
[DGK04] wurde dies als "Konsolidierung auf hohem Niveau" bezeichnet. Es ist eine
"Leistungsverlagerung von vergleichsweise stark belastenden (herzchirurgische
Operationen) zu schonenderen Verfahren (minimalinvasive kardiologische Eingriffe)" zu
sehen. Dies wird auch seitens des Kostenträgers angestrebt, da 2003 für therapeutische
Leistungen in der Herzchirurgie 45 % mehr Kosten bei deutlich weniger erbrachten
Maßnahmen als in der Kardiologie entstanden (vgl. Tab. 3.10).
Im Vergleich zu Österreich werden in Deutschland etwa 33 % mehr kardiologische Eingriffe
pro 1 Million Einwohner erbracht. Im europäischen Vergleich werden in Deutschland die
meisten Linksherzkatheter pro 1 Million Einwohner durchgeführt.
91
Die klinische kardiologische Fachabteilung
Maßnahme
Erbrachte
Anzahl
Durchschn.
Kosten
Gesamtkosten
Diagnostischer Linksherzkatheter
655.512
810 €
531 Mio. €
Therapeutischer Linksherzkatheter (PTCA)
222.668
3.600 €
802 Mio. €
Herzchirurgische Operation
94.712
15.400 €
1.459 Mio. €
Anschluss-Rehabilitations-Maßnahmen
69.000
2.400 €
166 Mio. €
Summe: 2.958 Mio. €
Tab. 3.10: Kostenverteilung für die wichtigsten Maßnahmen bei Herzpatienten im Jahr 2003 nach
[Bruck04]
In [Aum04] wird die kardiologische Versorgung in Deutschland als gut und flächendeckend
bezeichnet. Bei der Akutversorgung, insbesondere beim akuten Herzinfarkt, besteht jedoch
noch Verbesserungspotential. Dies gilt insbesondere für ländliche Regionen.
Insgesamt kann nach [Bruck04] eine Abnahme der Sterbeziffer bei kardiologischen
Erkrankungen festgestellt werden. So sank im Zeitraum 1990 bis 2003 die Anzahl der
Verstorbenen pro 100.000 Einwohner beim akuten Herzinfarkt von 107,4 auf 77,8 und
insgesamt bei den Erkrankungen der Herzkranzgefäße (zu denen auch der akute
Herzinfarkt zählt) von 216,3 auf 199,7. Im europäischen Vergleich liegt Deutschland damit
bei der altersstandardisierten Sterbeziffer für kardiologische Erkrankungen im Mittelfeld.
3.5 Zusammenfassung
Für jedes medizinische Verfahren in der Kardiologie werden folgende Ressourcen benötigt:
•
Medizinisches Fachpersonal (Ärzte und Pflegepersonal)
•
Räumlichkeiten (inkl. fest installierter medizinischer Großgeräte)
•
Medizinisches Inventar (spezielles Mobiliar, Geräte und Maschinen)
•
Sonstiges Inventar
•
Verbrauchsmaterial (Katheter, Medikamente, Stents etc.).
Dabei spielt der Patient eine passive Rolle und wird mit Hilfe des Gerätes durch das
Fachpersonal behandelt. Für ein Informationssystem können somit in erster Linie
Pflegepersonal und Ärzte als Anwender identifiziert werden. Dazu kommt noch das Personal
des Sekretariats für administrative Tätigkeiten wie z. B. Terminplanung.
Räumlichkeiten und Inventar können zusammengefasst werden, da bei den wichtigsten
kardiologischen Verfahren die medizinischen Großgeräte fest in einem Raum installiert sind
92
Die klinische kardiologische Fachabteilung
und somit eine untrennbare Verbindung besteht. Beim Einsatz mobiler Geräte ist in erster
Linie die Verfügbarkeit des medizinischen Gerätes relevant. Es kann davon ausgegangen
werde, dass das zuständige Personal für eine adäquate Umgebung für den Einsatz der
Geräte sorgt. Somit können die notwendigen Ressourcen zusammengefasst werden zu:
•
Medizinisches Fachpersonal
•
Für die Untersuchung notwendiges medizinisches Gerät
•
Verbrauchsmaterial.
Bei jeder Behandlung trägt ein Arzt, der eine ausreichende Qualifikation haben muss, die
Verantwortung. Dieser führt das Verfahren nach einem festen Ablauf durch, welcher dem
derzeitigen Stand der medizinischen Forschung entspricht. Eine Richtlinie hierfür bilden z. B.
die Leitlinien der medizinischen Fachgesellschaften. Bei jedem Verfahren kann es aber zu
Notfällen und unvorhersehbaren Ereignissen kommen, so dass der Arzt immer in der Lage
sein muss auf diese angemessen zu reagieren, insbesondere indem stets das medizinische
Personal die Kontrolle über den weiteren Behandlungsablauf hat.
In Tab. 3.11 sind noch einmal die Eckdaten der wichtigsten kardiologischen Behandlungsmethoden zusammengefasst. In der Spalte "Arzt" ist der Ausbildungsgrad des Arztes
angegeben. "Assi" besagt, dass dieses Verfahren von jedem Arzt der Abteilung durchführbar ist, da Assistenzärzte in der Klinik die unterste Stufe der "Ärztehierarchie" darstellen.
"Fach" bedeutet, dass der Arzt Facharzt sein muss oder im Rahmen seiner Ausbildung über
die notwendige fachliche Qualifikation verfügt. "Ober" zeigt an, dass ein Oberarzt für die
Behandlung verantwortlich ist und das Ergebnis abnimmt. Beim Personal steht "(1)" dafür,
dass im Routinebetrieb ein Mitarbeiter des Pflegepersonals den Arzt unterstützt, dieser aber
nicht zwingend erforderlicht und z. B. im Nachtdienst gelegentlich nicht anwesend ist.
In der Spalte "kardiologische Relevanz" ist der Stellenwert dieses Verfahren in der
klinischen kardiologischen Differentialdiagnostik angegeben. Bei Zeiten, Materialkosten,
Komplikationswahrscheinlichkeit und Wahrscheinlichkeit auf einen Wechsel des Verfahrens
wurden die Angaben grob gerundet. Hier soll eine Einschätzung des Verfahrens im
Vergleich zu den anderen Verfahren vermittelt werden. In der Spalte "Doku" ist angegeben,
welche Rolle die Dokumentation dieses Verfahrens spielt. Generell muss auf Grund der
gesetzlichen Dokumentationspflicht zu jeder Behandlung ein Befund geschrieben werden.
Dieser wird im Falle des EKG (Angabe "(Bef)") im klinischen Alltag jedoch selten gelesen,
da Kardiologen dem EKG-Streifen direkt seine medizinische Aussage ansehen und hier die
Originaldaten dem Befund vorziehen. Der Eintrag "Bef" steht dafür, dass ein ausführlicher
Befund notwendig ist. "QS" bedeutet, dass zusätzlich Daten für die Qualitätssicherung
(BQS) erhoben werden müssen. "Film" steht dafür, dass Bilder und Filme aufgezeichnet
werden, deren Nachbetrachtung für Falldiskussion und spätere Analysen interessant sind,
es jedoch nicht gesetzlich vorgeschrieben ist, diese neben dem Befund aufzubewahren. Im
Gegensatz dazu steht "Rö" dafür, dass Bilder und Filme aufgezeichnet werden, die nach der
Röntgenschutzverordnung mindestens 30 Jahre archiviert werden müssen.
93
Die klinische kardiologische Fachabteilung
Eingriff
Arzt
Personal
Kard.
Relevanz
Zeit
Mat.
Kosten
Kompl.
Wechsel
Doku
EKG
Assi
(1)
gering
10 Min.
2€
<1%
1%
(Bef)
Stress-EKG
Assi
(1)
gering
15 Min.
2€
<1%
0%
(Bef)
Ultraschall
Fach
(1)
hoch
15 Min.
5€
<1%
1%
Bef
Film
MR
Fach
Ober
1
hoch
45 Min.
5€
<1%
0%
Bef
Film
Diagnostischer
Herzkatheter
Fach
Ober
1
sehr
hoch
25 Min.
150 €
<2%
25 %
QS
Rö
Therapeutisch.
Herzkatheter
Fach
Ober
1
sehr
hoch
50 Min.
1000 €
<4%
0%
QS
Rö
Tab. 3.11: Eckdaten der wichtigsten kardiologischen Behandlungsmethoden
Für die Kostenerstattung durch die Krankenkassen ist es notwendig, dass der Patient
ambulant oder stationär aufgenommen und wieder entlassen wurde. Zusätzlich müssen alle
medizinischen Leistungen, die in der Zeit von der Aufnahme bis zur Entlassung durchgeführt
wurden, lückenlos dokumentiert werden. Dies ist nicht nur auf Grund der ärztlichen
Dokumentationspflicht (vgl. [BÄK]) notwendig, sondern auch zum Leistungsnachweis
gegenüber den Krankenkassen. Seitens der Krankenkassen gibt es den medizinischen
Dienst, welcher das Recht hat, Unterlagen über Behandlungsabläufe anzufordern, um z. B.
gestellte Rechnungen und durchgeführte Behandlungen in Frage zu stellen. Hier liegt es im
Interesse jeder medizinischen Institution eine genau Dokumentation von erbrachten
Leistungen zu führen um deren Anordnung und Durchführung auch im Nachhinein
rechtfertigen und somit abrechnen zu können.
Dabei ist der zeitliche Aspekt, wann die Dokumentation durchgeführt wird, nicht von
entscheidender Bedeutung. Wünschenswert ist aber, dass dies zeitnahe, möglichst während
oder unmittelbar nach der Behandlung, durchgeführt wird. Je mehr Zeit verstreicht, desto
höher ist die Wahrscheinlichkeit, dass Details bei der Dokumentation vergessen oder
Unterlagen verlegt werden.
Für die Modellierung der klinischen Fachabteilung
Anforderungen genügen:
94
sollte das Modell folgenden
•
Es werden flexible, situationsadaptierbare Arbeitsabläufe benötigt, um Wechsel der
Behandlungsart und Notfälle abdecken zu können.
•
Die gesamte Behandlungskette innerhalb der klinischen Fachabteilung muss
abbildbar sein, beginnend mit der Aufnahme und endend mit der Entlassung.
•
Der Status des Patienten innerhalb der Behandlungskette, also welche
Untersuchungen bereits durchgeführt werden, wo sich der Patient aktuell befindet
und was geplant ist, muss jederzeit abrufbar sein.
Die klinische kardiologische Fachabteilung
•
Der verantwortliche Arzt muss jederzeit die Entscheidungshoheit über den Fortgang
der Behandlung haben. Software darf hier nur unterstützend tätig sein.
•
Für jeden medizinischen Eingriff müssen Indikationen existieren, die diesen Eingriff
im Rahmen der Behandlungskette rechtfertigen.
•
Für jeden medizinischen Eingriff muss eine Dokumentationsmöglichkeit existieren.
Der Zeitpunkt der Dokumentation spielt dabei zunächst keine Rolle, jedoch sollte der
Zeitpunkt an dem die Dokumentation notwendig wurde (meistens das Ende des
medizinischen Eingriffs) festgehalten werden, um den Anwender später auf fehlende
Dokumente hinzuweisen.
•
Nach jeder Untersuchung muss festgehalten werden, was auf Grund der Ergebnisse
dieser und der bereits durchgeführten Untersuchungen als nächstes durch den
verantwortlichen Arzt empfohlen wird.
Für die konkrete Implementierung eines Abteilungsinformationssystems muss darüber
hinaus über die Aufbereitung der Daten für den Anwender nachgedacht werden. Dies
beinhaltet Fragestellungen wie:
•
Welche Informationen werden wann für wen angezeigt?
•
Wie werden multimediale Daten, insbesondere Bilder und Filme, abgelegt?
•
Wo müssen Eingabemasken durch den Anwender anpassbar/erweiterbar sein?
•
Wie werden welche Schnittstellen eingebunden und welche Daten werden hierüber
ausgetauscht?
•
Welche gesetzlichen Vorgaben müssen erfüllt werden?
Hierauf wird näher bei der Vorstellung des Implementierungsansatzes in Kapitel 5
eingegangen. Zunächst wird im folgenden Kapitel ein Verfahren zur Modellierung der
Arbeitsabläufe und der Behandlungen innerhalb der medizinischen Behandlungskette
vorgestellt.
95
Serviceflows zur Modellierung klinischer Behandlungsketten
4 Serviceflows zur Modellierung klinischer
Behandlungsketten
In diesem Kapitel wird ein Modell zur die Beschreibung medizinischer Fachabteilungen
vorgestellt. Dabei handelt es sich um einen serviceflow-orientierten Ansatz, der die Leistung
am Patienten in den Mittelpunkt stellt. Dies hat den Vorteil, dass die Aufgabe der
Modellierung einer großen Abteilung in die Teilbeschreibungen vieler einzelner Modelle
jeweils kleinster Einheiten, nämlich den leistungserbringenden Abteilungen, zerlegt werden
kann. Diese werden dann "dynamisch bei Bedarf", sobald sie im Rahmen der Behandlung
eine Rolle spielen, in den klinischen Kontext eingebettet, wodurch die gesamte
Behandlungskette abgebildet werden kann.
Ein Problem bei klinischen AISen ist es, die verschiedenen Sichten auf die verfügbaren
Daten für jeden am Behandlungsprozess Beteiligten zur Verfügung zu stellen. Zusätzlich
müssen zeitkritische Aspekte beachtet werden. Jederzeit können Nachrichten anderer
Systeme oder Ereignisse, die durch einen Anwender ausgelöst werden, die
Zustandsinformationen über einen Patienten aktualisieren. So muss z. B. auf
Verlegungsnachrichten oder Benachrichtigungen über durchgeführte Leistungen oder aktuell
verfügbare Laborergebnisse reagiert werden.
Um diesen Ansprüchen gerecht zu werden, wird in diesem Kapitel in mehreren Schritten der
sog. MSF (Medizinischer Service Flow) hergeleitet, mit dessen Hilfe Arbeitsabläufe in
medizinischen Institutionen abgebildet werden können. Dieses Modell des MSF dient als
wichtiger Baustein für die in Kapitel 5 vorgestellte Software-Architektur, die zur
Implementierung medizinischer AISe verwendet werden kann.
Im folgenden Abschnitt wird zunächst eine Übersicht über alle Definitionen, die für den MSF
benötigt werden, gegeben. In den folgenden Abschnitten werden diese dann detailliert
vorgestellt. Abschließend wird im letzten Abschnitt an Hand eines Beispiels der Einsatz des
MSF zur Modellierung einer kardiologischen Abteilung demonstriert.
97
Serviceflows zur Modellierung klinischer Behandlungsketten
4.1 Übersicht der Definitionen des medizinischen Serviceflows
Zur besseren Übersicht werden zunächst die Bausteine, die zur formalen Definition des
MSFs benötigt werden, erläutert. Ziel ist es, mit Hilfe des MSFs Arbeitsabläufe in klinischen
Institutionen abbilden und medizinische Leistungen dokumentieren zu können. Im Sinne des
Serviceflows (vgl. Abschnitt 2.5) entsprechen
•
die klinischen leistungserbringenden Unterabteilungen den SPs (Servicepoints),
•
die Krankenakte und der aktuelle PS (Patientenstatus), bestehend aus seinem
aktuellen Aufenthaltsort in der Klinik und den bei ihm geplanten und bereits
durchgeführten medizinischen Behandlungen, dem Servicefloat und
•
der Weg des Patienten durch die einzelnen Unterabteilungen, die er im Rahmen
seiner Behandlung aufsucht, dem Serviceflow.
In Abb. 4.1 ist ein Beispiel für die Behandlung eines Patienten in einer Kardiologie
dargestellt. Der Patient durchläuft im Rahmen des klinischen Aufenthalts die einzelnen
medizinischen SPs, in welchen die medizinischen Dienstleistungen durchgeführt werden.
Dabei wird durch die Mitarbeiter, welche innerhalb der SPs tätig sind, die Krankenakte
jeweils entsprechend aktualisiert und um die im Rahmen der medizinischen Dokumentation
anfallenden Informationen erweitert. Gleichzeitig wird, sobald der Patient einen SP verlässt,
der PS aktualisiert.
In diesem Beispiel wurde der Patient für eine Herzkatheteruntersuchung eingeplant.
Zunächst wird er durch die zentrale Patientenaufnahme des Krankenhauses aufgenommen.
Dort wird eine Krankenakte angelegt, die alle im Rahmen der Aufnahmeprozedur erfassten
Daten enthält. Im PS wird vermerkt, dass ein Herzkatheter geplant ist. Bis zu dessen
Durchführung hält sich der Patient auf der Station 8 auf. Von dort wird er dann in das
Herzkatheterlabor verlegt, in dem die geplante Untersuchung durchgeführt wird. Nach der
Untersuchung wird der Patient wieder auf die Station 8 zurückverlegt und nach einem
komplikationslosen Verlauf, welcher keine weitere Behandlung erforderlich macht,
entlassen. Bei jeder Verlegung wird der PS angepasst und die SK durch die
leistungserbringende Abteilung aktualisiert. Es handelt sich hier nur um einen möglichen
Weg einer Behandlungskette. Ebenso hätte der Patient auch auf Grund einer
entsprechenden Diagnose im Herzkatheterlabor in die Herzchirurgie verlegt werden können
oder vor der Herzkatheteruntersuchung hätten noch Voruntersuchungen durch das Labor
oder die Ultraschallabteilung durchgeführt werden können.
Die Entscheidung, welche Behandlung als nächstes durchgeführt wird, wird durch den
verantwortlichen Chef- oder Oberarzt getroffen. Diese Entscheidung legt gleichzeitig fest,
welcher SP als nächstes für den Patienten zuständig ist. Der verantwortliche Arzt trifft diese
Entscheidung auf Grund der Ergebnisse der bereits durchgeführten Untersuchungen und
des aktuellen Zustands des Patienten. Dies kann spontan geschehen, wenn z. B.
98
Serviceflows zur Modellierung klinischer Behandlungsketten
Komplikationen auftreten, die die sofortige Durchführung einer Maßnahme erforderlich
machen. Hierfür greift der Arzt auf sein "Domänenwissen" zurück, grundsätzlich könnte
diese Entscheidung aber auch durch ein Expertensystem unterstützt oder in Zukunft sogar
getroffen werden.
Abb. 4.1: Beispiel für einen Medizinischen Serviceflow. Die Abkürzung "therap. HK" steht für
"therapeutischer Herzkatheter" und "St. 8" für den "stationären Aufenthalt auf Station 8"
Für jeden MSP (medizinischer Servicepoint) ist bekannt, welche medizinischen Maßnahmen
er erbringen kann. Für jede Maßnahme gibt es wiederum Indikationen, die entweder aus
•
Fragestellungen bei der Einweisung, also der Einweisungsdiagnose,
•
Ergebnissen vorhergehender Untersuchungen oder
•
dem Auftreten von medizinischen Ereignissen, wie z. B. Komplikationen,
resultieren.
In dieser Arbeit wird davon abgesehen einen Automatismus für die Behandlungsstrategie
eines Patienten vorzustellen. Dies liegt daran, dass die Behandlung eines Patienten von
vielen nicht eindeutig klassifizierbaren Indikatoren, wie z. B. dem Erscheinungsbild oder dem
99
Serviceflows zur Modellierung klinischer Behandlungsketten
Allgemeinzustand, abhängig ist. Weiterhin schreibt der Gesetzgeber vor,
Entscheidungen über Behandlungen nur durch einen Arzt getroffen werden dürfen.
dass
Für ein allgemeingültiges, formales Modell werden in diesem Kapitel die in dem Beispiel
angeführte Krankenakte, der PS, der MSP und der Serviceflow definiert. Die hierfür
notwendigen einzelnen Bausteine und ihr Zusammenhang sind im Folgenden kurz
zusammengefasst, worauf die formalen Definitionen in den nächsten Abschnitten folgen.
Eine DMM (Dreiphasige Medizinische Maßnahme) ist eine medizinische Maßnahme, welche
in die drei Phasen Vorbereitung, Durchführung einer medizinischen Maßnahme sowie
Nachbereitung zerlegt werden kann. DMMs stellen die Leistungen dar, die von den
einzelnen leistungserbringenden Abteilungen durchgeführt werden können.
Die SK (Strukturierte Krankenakte) dient zur Speicherung medizinisch relevanter
Informationen. Dazu muss sie mindestens Patientendaten, Informationen über klinische
Ereignisse und die Möglichkeit zur Erfassung von Detailinformationen zu medizinischen
Leistungen haben. Hierfür wird die SK in verschiedene Teile zerlegt, in der
zusammengehörige
Informationen
(Patientendaten
PD,
Aufenthaltsdaten
AD,
Leistungsdaten LD) gespeichert werden. Der genaue Inhalt ist abhängig von den klinischen
Abteilungen, die durch die SK abgebildet werden sollen. Somit ist die SK auf der Ebene der
EKAn (elektronische Krankenakte) einzuordnen.
Der PS (Patientenstatus) dient zur Speicherung von aktuellen Informationen zu einem
Krankenhausaufenthalt. Insbesondere sind dies
•
die bei einem Patienten bereits durchgeführten Behandlungen,
•
die bei dem Patienten aktuell geplanten Behandlungen,
•
der aktuelle Aufenthaltsort des Patienten und
•
die nächste durchzuführende Behandlung.
Zu einem PS gehört während eines Krankenhausaufenthaltes immer eine SK.
Eine NLO (Normalisierte Leistungserbringende Organisationseinheit) ist eine spezialisierte
klinische Unterabteilung, die ein bestimmtes Spektrum an DMMn unabhängig von externen
Ressourcen durchführen kann.
Eine ENLO (Erweiterte Normalisierte Leistungserbringende Organisationseinheit) ist eine
formal definierte NLO, für die
•
ein Name,
•
die Menge ihrer erbringbaren DMMn,
•
die Indikation, die zu einer Behandlung in dieser ENLO führen können,
•
Modifikatoren für die SK, welche
Dokumentation ermöglichen, und
100
die
Durchführung
einer
medizinischen
Serviceflows zur Modellierung klinischer Behandlungsketten
•
mögliche Vorschläge für die weitere Behandlung
festgelegt sind.
Ein Aktivator kann einen Hintergrundprozess entweder auf Grund des Eintretens eines
speziellen Ereignisses oder durch manuelles Anstoßen durch einen Anwender initiieren.
Ein MSP (Medizinischer Service Point) ist eine spezialisierte ENLO, der insbesondere
Erweiterungen zur Modifikation des PS und Aktivatoren besitzt. In Abb. 4.2 ist der
Zusammenhang von NLO, ENLO und MSP grafisch dargestellt.
MSP
ENLO
NLO
Klinische Fachabteilungen und leistungserbringende
Unterabteilungen
Abb. 4.2: Der MSP als Spezialisierung von ENLO und NLO, welche eine Teilmenge aller
medizinischen (Unter)Abteilungen bildet.
Ein MSF (Medizinischer Service Flow) ist eine Abfolge, in der der Patient im Rahmen eines
Krankenhausaufenthaltes die einzelnen MSPs durchläuft. Dies bildet also die tatsächlich
durchgeführte Behandlungskette ab.
Der SMSF (Standardisierter Medizinischer Service Flow) ist eine Liste von MSPs, die immer
mit einem AP beginnt und einem EP endet. Die Reihenfolge der MSPs innerhalb der Liste
spielt eine Rolle, da diese Reihenfolge den Behandlungsablauf in Form zu durchlaufender
MSPs wiedergibt. Der SMSF ist somit ein prospektiver Vorschlag für eine wahrscheinliche,
häufig durchgeführte, standardisierte Behandlungskette.
Abb. 4.3 zeigt den Zusammenhang zwischen MSF, MSP, SK und PS. Im Rahmen der
Behandlung sucht der Patient unterschiedliche MSPs auf. Der Weg durch die MSPs beginnt
immer bei einem AP (Aufnahmepunkt) und endet immer bei einem EP (Entlassungspunkt),
da ein Patient für die Durchführung einer klinischen Behandlung stets aufgenommen und
entlassen wird (vgl. Abschnitt. 3.5). Jeder MSP, der eine medizinische Leistung durchführt,
dokumentiert diese in der SK. Zusätzlich wird der PS durch die MSPs modifiziert, sobald der
Patient einen MSP betritt und wieder verlässt.
101
Serviceflows zur Modellierung klinischer Behandlungsketten
Abb. 4.3: Zusammenhang von MSF, MSP, SK und PS
4.2 Dreiphasige Struktur von Behandlungsabläufen
Die "schematische" und nicht im Einzelfall inhaltlich differenzierte Betrachtung der im letzten
Kapitel in den Abschnitten 3.2.3 und 3.2.4 erarbeiteten Ablaufdiagramme der diagnostischen
und therapeutischen Verfahren in der kardiologischen Abteilung zeigt, dass diese durch ein
einheitliches Phasenschema mit den Phasen Vorbereitung, Durchführung und
Nachbereitung beschrieben werden können:
1. Vorbereitung: Zunächst werden die Untersuchungsräume, medizinischen Geräte und
der Patient auf den anstehenden Eingriff durch Ärzte und Pflegepersonal vorbereitet.
2. Durchführung: Hier wird die eigentliche Untersuchung durchgeführt. In diesem Punkt
unterscheiden sich die Abläufe erwartungsgemäß am deutlichsten.
3. Nachbereitung: In dieser Phase laufen wie in der Vorbereitung mehrere gleichartige
Prozesse parallel ab. Diese umfassen immer die Befundung und Dokumentation
durch den Arzt sowie die Nachbereitung des Untersuchungsraumes und der
medizinischen Geräte, meist in Form von Aufräumen und Reinigen. Ist der Patient
wach und ansprechbar, wird zusätzlich das abschließende Gespräch mit dem
Patienten durchgeführt, bevor er auf die Station oder temporär in einen
Überwachungsraum verlegt wird.
102
Serviceflows zur Modellierung klinischer Behandlungsketten
In Abb. 4.4 ist die Einteilung in drei Phasen noch einmal für zwei ausgewählte medizinische
Verfahren (HK und EKG) veranschaulicht.
Patient
abrufen
HK-Labor
vorbereiten
Patient abrufen
EKG
vorbereiten
Vorbereitendes Gespräch,
Patient vorbereiten
(Elektroden aufkleben)
Vorbereitendes Gespräch,
Patient vorbereiten
Vorbereitung:
Patient, Raum und
Untersuchungsgerät
werden vom
medizinischen Personal
auf die Untersuchung
vorbereitet.
EKG einstellen,
ggf. Daten
eingeben
Patientendaten
erfassen
Durchführung:
Nein
Diagnostik
durchführen
Nur Dilatation?
Indikation
zur primavista
Dilatation?
Ja
Daten auswerten,
Nachbesprechung,
Procedere festlegen
Befund
schreiben
Befund mit
Patient
besprechen
Belastung
erhöhen
Nein
Ja
Dilatation
durchführen
Nein
Patient
nachbereiten
(insb.
Abdrücken)
EKG
schreiben
Patient
ausbelastet?
Für jeden Eingriff
unterschiedlich; hier ist
die größte
Wahrscheinlichkeit für
das Auftreten
unvorhergesehener
Ereignisse.
Ja
HK-Labor
nachbereiten
Filme / Bilder
archivieren
Nachbereitung:
Befund schreiben und dabei
mit Patient besprechen
Patient zurück
schicken
EKG
nachbereiten
Parallel wird durch
unterschiedliche
Personen dokumentiert,
der Befund geschrieben
und mit dem Patienten
besprochen, der Raum
nachbereitet und der
Patient schließlich
zurück verlegt.
Patient zurück
schicken
Abb. 4.4: Allgemeiner Aufbau medizinischer Verfahren am Beispiel von Herzkatheter und EKG.
Jeder medizinische Eingriff kann in die drei Phasen Vorbereitung, Durchführung und
Nachbereitung eingeteilt werden.
Diese Einteilung kann aber nicht nur auf diese beiden und auf die vorgestellten
kardiologischen Verfahren angewendet werden, sondern auch für die meisten medizinischen
Verfahren verallgemeinert werden. So wird in [Kut01] der grundsätzliche Arbeitsablauf in der
103
Serviceflows zur Modellierung klinischer Behandlungsketten
Kinder- und Jugendpsychiatrie des Universitätsklinikum Heidelberg auf das in Abb. 4.5
vorgestellte Modell reduziert. Zusammenfassend kann der dort beschriebene Ablauf der
medizinischen Verfahren folgendermaßen dargestellt werden:
1. Klärung der Behandlungsziele in einem vorbereitenden Gespräch
2. Diagnostische Abklärung
3. Therapeutische Verfahren basierend auf den Ergebnissen aus 2.
4. Dokumentation und abschließende Besprechung mit Patient und ggf. Eltern oder
Bezugsperson.
Werden die Punkte 2 und 3 aus Abb. 4.5, welche den eigentlichen medizinischen Eingriff
darstellen, zusammengefasst7, entsteht dasselbe dreiphasige Ablaufmodell wie in dem
vorgestellten Dreiphasenschema für die Kardiologie.
1. Aufnahme
2. Diagnostik
3. Therapie
4. Entlassung
Abb. 4.5: Phasen des Behandlungsprozesses in der
Universitätsklinikum Heidelberg nach [AEE01]
Kinder-
und Jugendpsychiatrie des
Jedoch handelt es sich hier um eine grundsätzlich andere medizinische Abteilung. Die
Kardiologie ist eine internistische Abteilung, in der mit Hilfe hoch technisierter Maschinen
invasive diagnostische und therapeutische Verfahren durchführt werden, bei denen die
Symptome klassischer, einwandfrei nachgewiesener Krankheitsbilder auf Basis
7
Die Punkte 2 und 3 in Abb. 4.3 entsprechen gerade der medizinischen Maßnahme, welche in
anderen Abteilungen wie z. B. der Kardiologie nicht immer in einer Sitzung durchgeführt werden. So
ist z. B. die Ultraschalluntersuchung ein rein diagnostisches Verfahren, das keine Therapie zulässt,
während die Dilatation nur eine Therapie ist. Eine Trennung ist somit für die Kinder- und
Jugendpsychiatrie sinnvoll, für ein allgemeines Modell sollte dies jedoch unter dem Oberbegriff
"Durchführung der medizinischen Maßnahme" zusammengefasst werden.
104
Serviceflows zur Modellierung klinischer Behandlungsketten
physikalischer oder medikamentöser Behandlungsprozesse eliminiert werden. Hingegen
steht in der Psychiatrie die intensive Auseinandersetzung mit der Psyche des Patienten in
Form von therapeutischen Sitzungen, z. B. durch Musik- oder Ergotherapie, im Vordergrund.
Auch in klassischen medizinischen Disziplinen wie der Chirurgie kann diese Einteilung in
drei Phasen vorgenommen werden:
1. Vorbereitung: Hier wird zum einen der Patient auf die OP vorbereitet, meist durch die
Anästhesisten in einem eigenen Vorbereitungsraum. Zum anderen wird der OP-Saal
durch das Pflegepersonal vorbereitet, der Tisch gerichtet und das notwendige
Material, z. B. Prothesen oder Implantate, bereit gelegt.
2. Durchführung: Dies beinhaltet die eigentliche Operation, durchgeführt durch den
Operateur mit Unterstützung weiterer Ärzte und des OP-Personals, meist unter
Überwachung der Vitalfunktionen durch einen Anästhesisten.
3. Nachbereitung: Nach der Operation wird im OP eine OP-Dokumentation
durchgeführt, bei der durch das Pflegepersonal im Rahmen der Zählkontrolle der
korrekte Bestand aller Materialien festgehalten wird, um auszuschließen, dass
Material im Patienten unabsichtlich "vergessen" wurde. Durch den Arzt werden in
Kurzform der durchgeführte Eingriff, die intraoperative Diagnose und eventuelle
Besonderheiten festgehalten. Während dessen wird der OP-Saal aufgeräumt und
gereinigt und der Patient auf die Aufwachstation verlegt. Nachfolgend wird durch den
Operateur der komplette OP-Bericht geschrieben.
Auch außerhalb des klinischen Umfelds ist in ganz anderen Anwendungsdomänen ein
solcher dreiphasiger Aufbau bei der Durchführung von komplexen Handlungsabläufen oder
Arbeitsaufträgen zu finden. So wird im Projekt VirtLab (vgl. [AS03], [Sch01] und [VIRT]) bei
der interaktiven simulations-basierten Durchführungen von Laborversuchen ebenfalls eine
Einteilung in solche Phasen durchgeführt.
In formalen Modellen der Informatik findet sich z. B. bei Hoare (siehe [RH88], [HG92]) ein
ähnlicher Ansatz. Hier werden pre- und post-conditions für Prozesse, bei denen es sich
insbesondere um Baugruppen von Schaltkreisen handelt, definiert. Dieser mathematische
Ansatz dient zur exakten Zusicherung von Bedingungen, die zum Testen des eigentlichen
Produktes herangezogen werden können. Die Verwendung von booleschen Ausdrücken, die
bei Hoare auch schon die Grundlage für die Programmiersprache Occam [SGS95] bildeten,
kann auch auf den medizinischen Anwendungsfall übertragen werden. Hier dient der Ansatz
zur Definition der Indikation und somit zum Festlegen von Bedingungen, unter denen ein
medizinischer Eingriff durchgeführt wird.
Es könnten in der Medizin auch post-conditions definiert werden, die aber nicht immer
zugesichert werden können. Es würde sich hierbei nur um wünschenswerte post-conditions
handeln, die meist einen Inhalt der Art "Bei dem Patient wurde Erkrankung X erfolgreich und
komplikationslos mit dem Verfahren Y behandelt und die Symptome Z konnten beseitigt
werden" hätte. Leider kann aber gerade in der Medizin nicht garantiert werden, dass eine
105
Serviceflows zur Modellierung klinischer Behandlungsketten
Therapie beim Patienten in so zweifelsfreier und unmittelbar verifizierbarer Weise
"anschlägt". Es handelt sich insbesondere in der Kardiologie um alte, teilweise multimorbide
Menschen, die an mehreren, oft verwandten Krankheitsbildern leiden. Ziel ist es daher das
patientenspezifisch Bestmögliche zu erreichen. Eindeutige Postconditions im Sinne auf
jeden Fall zu erreichender Zustände sind im Medizinbereich nicht angemessen. Vielmehr ist
es hier üblich, eine Nachbearbeitung durchzuführen, in der Vorschläge für den weiteren
Behandlungsverlauf unter Berücksichtung des gerade erzielten Resultats erarbeitet werden.
Wichtig ist, dass es sich auch wieder nur um Vorschläge handelt, die an Änderungen im
Krankheitsverlauf adaptiert werden müssen.
Dieser allgemeine, häufig in ähnlichen Varianten verwendete dreiphasige Aufbau soll nun
auf medizinische Verfahren angewendet, in Definition 4.2 festgehalten und dann in dieser
Arbeit weiter verwendet werden. Diese Begriffsbildung bildet eine wichtige Grundlage für die
im folgenden Kapitel vorgestellte Software-Architektur, welche die dokumentarische
Tätigkeit für das Personal dadurch erleichtern soll, dass sie den Ablauf standardisierter
medizinischer Prozeduren nachbildet. Dazu ist es notwendig, dass festgestellt werden kann,
ob eine medizinische Maßnahme mit dem hier vorgestellten Modell abbildbar ist. An dieser
Stelle ist relativierend und einschränkend zu bemerken, dass es sicher in anderen
Abteilungen
oder
Einrichtungen,
insbesondere
Spezialkliniken,
abweichende
Vorgehensmodelle gibt. Aber das hier präsentierte Modell sollte für fast alle Abteilungen in
Akutkliniken einen hohen Abdeckungsgrad haben. Diese Behauptung wird unterstützt durch
die Feststellung, dass der Autor über detaillierte Einblicke in die Arbeitsabläufe von über 40
der insgesamt ca. 200 kardiologischen Fachabteilungen in deutschen Kliniken verfügt.
Definition 4.2: DMM (Dreiphasige Medizinische Maßnahme)
Jedes medizinische Verfahren, unabhängig davon, ob es sich um ein diagnostisches,
therapeutisches oder kombiniertes Verfahren handelt, wird als DMM bezeichnet, wenn
folgendes gilt:
•
Der Ablauf lässt sich in die drei Phasen Vorbereitung, Durchführung und
Nachbereitung einteilen.
•
Die einzelnen Phasen folgen chronologisch (streng sequentiell) aufeinander, d. h. ist
die eine Phase abgeschlossen, so beginnt die nächste.
•
Während der Vorbereitung werden ausschließlich Aktionen durchgeführt, die die
notwendigen Ressourcen (Räume, Maschinen, Patient etc.) in einen Zustand
versetzen, der die Durchführung des eigentlichen medizinischen Verfahrens
ermöglicht.
•
Die Durchführung beinhaltet die geplante Maßnahme, die auf Grund der
Vorbereitung möglich und medizinisch angemessen ist.
106
Serviceflows zur Modellierung klinischer Behandlungsketten
•
In der Nachbereitung wird eine Dokumentation durchgeführt, eine abschließende
Bewertung, meist in Form einer Diagnose, erstellt und alle Ressourcen werden
entsprechend nachbereitet. Dies beinhaltet auch die Verlegung des Patienten.
•
Beim Ablauf der Aktionen innerhalb der Maßnahme wird nur der durch den Chefarzt
(oder verantwortlichen Oberarzt) standardisierte, routinemäßige Vorgang
berücksichtigt und nicht eventuelle, unvorhersehbare Verzweigungen im Workflow,
wie sie z. B. durch Notfallmaßnahmen auftreten könnten, verfolgt.
•
Die Maßnahme kann eindeutig einer leistungserbringenden Abteilung, die diese
Maßname durchführen kann, zugeordnet werden.
Anmerkungen zu Definition 4.2:
•
•
Die chronologische Abfolge der einzelnen Phasen ist bei jeder DMM ohne
Ausnahme notwendig, da selbst bei einem Abbruch innerhalb einer der ersten
beiden Phasen die anderen durchlaufen werden müssen, um einen konsistenten
Endzustand der leistungserbringenden Abteilung zu gewährleisten. Dieser
Endzustand muss so erreicht sein, dass die Abteilung "leer" ist, also keinen
Patienten behandelt, und immer eine Dokumentation für jede Untersuchung
durchgeführt wird, sei es auch nur die Bemerkung, dass die Maßnahme bei einem
Patienten abgebrochen werden musste. Auch dies muss durch den verantwortlichen
Arzt im Rahmen der Dokumentationspflicht medizinisch begründet werden. Daher
muss die Nachbearbeitungsphase immer durchlaufen werden.
Da die Durchführung von der Vorbereitung abhängig ist, wird auch sie immer
ausgeführt. Ist ein frühzeitiger Abbruch der medizinischen Maßnahme, z. B. durch
Komplikationen während der Vorbereitung notwendig, so ist die Durchführung
(ersatzweise für eine fachärztliche Maßnahme) die "leere Maßnahme", welche
repräsentiert, dass nichts durchgeführt wurde.
Diese "leere Maßnahme" muss wiederum auch als medizinische Maßnahme
existieren, da gegenüber dem Kostenträger immer eine Maßnahme, selbst bei einem
Abbruch, dokumentiert werden muss, um eine Begründung des Krankenhaushaltes
durch den Leistungserbringer vorlegen zu können. Hierfür gibt es in Deutschland den
speziellen OPS-Code 5-995 "Vorzeitiger Abbruch einer medizinischen Maßnahme".
Während der Vorbereitung dürfen noch keine therapeutischen oder diagnostischen
Maßnahmen durchgeführt werden, da diese zum Verlauf der Untersuchung gehören,
welche nach Empfehlung der DGK protokollarisch dokumentiert werden müssen. Um
eine Vermischung beim dokumentarischen Vorgehen zu vermeiden und klar
herausarbeiten zu können, was an welcher Stelle protokolliert werden muss und was
nicht, muss eine standardisierte medizinische Maßnahme hier eine klare Trennung
bilden. Dies gilt auch für die Nachbereitung.
107
Serviceflows zur Modellierung klinischer Behandlungsketten
Kommt es bei dieser zu einer Notfallmaßnahme, die einen weiteren Eingriff in
derselben oder einer anderen Abteilung erforderlich macht, so ist dies der Beginn
eines neuen medizinischen Verfahrens. Bevor dieses beginnt, wird aber in jedem Fall
der laufende Eingriff abgeschlossen, da Dokumentation und Verlegung des Patienten
und Raumreinigung stattfinden müssen.
•
Der Abschluss einer medizinischen Maßnahme ist auch auf Grund
abrechnungstechnischer Vorschriften unumgänglich, da in Deutschland jede
Maßnahme eigenständig begonnen, abgeschlossen, dokumentiert und mit
mindestens einem OPS-Code verschlüsselt werden muss. Dies führt soweit, dass,
sollte der Folgeeingriff in derselben Abteilung im selben Raum durchgeführt werden,
eine "virtuelle Verlegung" in denselben Raum mit erneuter Vorbereitung desselben
erfolgt und dann das neue medizinische Verfahren eingeleitet wird. Dieser Fall tritt
z. B. in der Chirurgie manchmal auf, wenn der Patient direkt nach der OP noch
während der Ausschleusung oder auf dem Weg auf die Intensivstation instabil wird
und wieder in den OP-Saal muss.
4.3 Die DMM im klinischen Kontext
Bei jeder der in Kapitel 3 vorgestellten sechs kardiologischen Eingriffe handelt es sich um
eine DMM. Diese werden immer von einer speziellen leistungserbringenden Unterabteilung
der Kardiologie durchgeführt. Die konkrete Zuordnung zwischen DMM und Unterabteilung
kann Tab. 4.1 entnommen werden.
Leistungserbringende kardiologische Unterabteilung
DMM
EKG
EKG
X
Stress-EKG
X
Echo-Labor
Ultraschall
X
Stress-Echo
X
HK-Labor
Diagnostischer HK
X
Therapeutischer HK
X
Angiografie
X
Angioplastie
X
EPU
X
Tab. 4.1:
108
DMM-Verteilung auf leistungserbringende Unterabteilungen der Kardiologie
Serviceflows zur Modellierung klinischer Behandlungsketten
Jede dieser Unterabteilungen kann als eigenständige Einheit angesehen werden. Sie
beginnt die Durchführung einer medizinischen Leistung an einem Patienten, sobald dieser
die Unterabteilung erreicht. Wenn die Behandlung beendet ist, wird der Patient abgeholt und
zurück auf eine Station verlegt. Damit ist die Tätigkeit für diesen Patienten abgeschlossen
und mit dem nächsten Patienten beginnt der Prozess wieder von vorne.
Für die komplexeren Eingriffe im HK-Labor wird durch den zuständigen Oberarzt ein
Tagesplan erstellt, der als Richtlinie gilt, in welcher Reihenfolge die Patienten behandelt
werden sollen. Innerhalb dieses Plans sind kurzfristige Modifikationen möglich, die auf
folgenden Ereignissen basieren können:
•
Ein Notfall wird eingeliefert, der umgehend behandelt werden muss.
•
Eingriffe beanspruchen mehr Zeit als vorgesehen, wodurch die nachfolgend
geplanten Maßnahmen (oder zumindest einige) abgesetzt und auf den folgenden
Tag verschoben werden.
•
Eingriffe können schneller als erwartet durchgeführt werden, wodurch Patienten, die
bereits auf einer kardiologischen Station liegen und auf eine medizinische
Maßnahme warten, vorgezogen werden.
Dabei kommt das Absetzen von Eingriffen auf Grund unvorhergesehener Verzögerungen
gelegentlich, seltener auch das Vorziehen von Maßnahmen vor. Davon sind nur elektive,
also nicht dringliche Fälle betroffen. In dringlichen Fällen wird das Tagesprogramm stets
abgearbeitet, auch wenn die normalen Dienstzeiten der Abteilung dadurch überschritten
werden.
Sämtliche Eingriffe in der Kardiologie werden pro leistungserbringender Unterabteilung stets
nacheinander abgearbeitet, es finden also keine "geschachtelten" Behandlungsabläufe oder
Parallelität innerhalb einer leistungserbringenden Unterabteilung statt. In einem Raum
werden niemals zwei Patienten gleichzeitig behandelt. Für diese unterbrechungsfreie
Abarbeitung der Fälle gibt es u. a. folgende Gründe:
•
Die reinen Untersuchungsdauern für einfache Eingriffe wie EKG und Ultraschall sind
sehr kurz (vgl. Tab. 3.7 in Kapitel 3, Abschnitt 3.3). Die Zeit, die für Abbruch,
Reinigung und ggf. Umrüstung der Geräte und Wiederaufnahme der alten
Untersuchung notwendig wäre, ist gegenüber einer kurzen Wartezeit für den
nächsten Patienten unvertretbar. So werden z. B. für die Patientenvorbereitung im
Ultraschall mit Umkleiden und Lagerung des Patienten auf der Liege, ggf. Aufkleben
von Elektroden, vorbereitendes Gespräch etc. mindestens fünf Minuten benötigt. Der
eigentliche Ultraschall dauert danach im Schnitt weniger als zehn Minuten, also
kaum länger als die Vorbereitung des nächsten Patienten. Durch den Abbruch der
laufenden Maßnahme könnten also für den nächsten Fall nur wenige Minuten
Zeitersparnis erreicht werden und dies auch nur unter der Voraussetzung, dass der
Notfall völlig überraschend "ohne Vorwarnung" erscheint. Dies ist aber sehr
unwahrscheinlich, da ein Notfall durch den Zuweiser (meist Rettungswagen) vorher
109
Serviceflows zur Modellierung klinischer Behandlungsketten
angekündigt wird. Lässt sich also ein solcher Notfall absehen, wird der Routineablauf
kurz unterbrochen, ggf. einige Minuten auf das Eintreffen des Notfalls gewartet,
dieser abgearbeitet und dann das Routineprogramm wieder aufgenommen.
•
Auch die komplexen Eingriffe wie der Herzkatheter sind nicht sehr zeitintensiv und
benötigen inkl. Vor- und Nachbereitung weniger als eine Stunde. Tritt ein
kardiologischer Notfall ein, so wird dieser dem Krankenhaus von den Einsatzkräften
des Kranken- oder Rettungswagens frühzeitig mitgeteilt. Bis der Patient dann das
Krankenhaus erreicht, aufgenommen und von der Notfallaufnahme für den Eingriff
vorbereitet ist, vergeht auch hier so viel Zeit, dass die gerade laufende Untersuchung
entweder beendet werden kann oder so kurz vor ihrem Ende steht, dass ein Abbruch
gegenüber dem Aufwand zur Wiederaufnahme in keinem Verhältnis steht, zumal
bedacht werden muss, dass dem Patienten bei einer Wiederaufnahme eine
zusätzliche Strahlenbelastung und erneute Kathetereinbringung zugemutet würde.
•
Aus Gründen der ärztlichen Schweigepflicht (vgl. [Die93]) und der Diskretion ist es in
Deutschland zumindest bisher undenkbar, dass Patienten gleichzeitig im selben
Raum behandelt werden.
Ambulante Leistungen stellen sich aus Sicht des HK-Labors zunächst wie stationäre Fälle
dar, da der Patient vor und nach dem Eingriff im Krankenhaus auf einer speziellen
"Ambulanz-Station" betreut wird. Es muss nur bei der Tagesplanung beachtet werden, dass
ambulante Patienten
•
nicht als erstes behandelt werden, da sie, bedingt durch Anreise und Aufnahme auf
der Ambulanz-Station, erst später verfügbar sind und
•
nicht zu spät behandelt werden, also möglichst nicht nach 12.00 Uhr, da die
Nachbetreuung auf der Ambulanz-Station mindestens sechs Stunden dauert und der
Patient ohne Übernachtung am selben Tag wieder nach Hause entlassen werden
soll.
Eine typische, auf Grund der hohen Fallzahl aussagekräftige, Zeitverteilung (auf 24 Stunden
eines Tages abgebildet) der Termine für Eingriffe im HK-Labor kann Abb. 4.6 entnommen
werden.
Bei den einfacheren und schnell durchführbaren diagnostischen Maßnahmen im Ultraschall
und EKG werden Anforderungen für die Untersuchungen durch den Stationsarzt, meist nach
Rücksprache mit dem zuständigen Oberarzt, gestellt. Die Patienten werden dazu durch den
diensthabenden Arzt der leistungserbringenden Unterabteilung von den Stationen kurzfristig
abgerufen und die Anforderungen so sequentiell abgearbeitet.
110
Serviceflows zur Modellierung klinischer Behandlungsketten
2000
1926
Stationär
1765
1800
1648
1631
Ambulant
1594
1521
1436
1600
Anzahl HKs
1400
1200
1096
1000
800
621
600
504
374
400
235
200
18 12 13 11 13
7
10
78 43
34 29
11
100
9
4
65 55 34 36
27 31
0
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23
Uhrzeit
Abb. 4.6: Stunden bezüglich Verteilung des Startzeitpunktes von Eingriffen im HK-Labor aufgeteilt
nach stationären und ambulanten Fällen in der Kardiologie der Klinikum Oldenburg
gGmbH im Zeitraum 01/2001 bis 09/2004
Auch hier gibt es eine Ambulanz, bei der aber im Gegensatz zum Herzkatheter keine
vorherige Aufnahme auf einer Ambulanz-Station durchgeführt wird. Die Patienten finden sich
zu einem vorher abgesprochenen Termin in der Klinik ein, nehmen im Wartezimmer Platz
und werden nacheinander zur Untersuchung abgerufen. Der Ambulanzbetrieb beginnt
täglich zu einer festen Zeit (in Oldenburg derzeit um 11:00 Uhr) und endet, wenn der letzte
Patient behandelt wurde, was durchschnittlich zwei Stunden nach dem ersten Termin der
Fall ist. In dieser Zeit werden in der Regel keine Patienten des Krankenhauses im
Ultraschall oder EKG untersucht, außer es handelt sich um Notfälle.
Bei allen Eingriffen kann es zu unvorgesehenen Komplikationen kommen, die zu
unterschiedlichen Notfallmaßnahmen führen können. Diese sollen hier in zwei Klassen
unterteilt werden:
•
Einfache Notfallmaßnahmen, die vom behandelnden Arzt im Rahmen des Eingriffes
durchgeführt werden können und das Gesamtergebnis des Eingriffes nicht
beeinflussen.
•
Komplexe Notfallmaßnahmen, die zum Abbruch des geplanten Eingriffes und ggf. zu
einer Verlegung und Weiterbehandlung in einer anderen Abteilung oder einem
anderen Krankenhaus führen.
111
Serviceflows zur Modellierung klinischer Behandlungsketten
In Tab. 4.2 sind Art, Komplexität und Häufigkeit der Komplikationen für die vier wichtigsten
vorgestellten kardiologischen Verfahren aufgeführt. Die BQS veröffentlicht in [BQS04] im
Rahmen ihrer bundesweiten Qualitätssicherung nur die Komplikationsrate bei allen
Eingriffen im HK-Labor, ohne eine Aufteilung in diagnostische und interventionelle Eingriffe
durchzuführen. Hier lag das Auftreten von komplexen Komplikationen bei 0,2 %8, welche
eine Sterblichkeitsrate von insgesamt 0,07%, bezogen auf alle Eingriffe im HK-Labor,
enthält. Somit kann festgehalten werden, dass die Komplikationsrate bei den Verfahren in
der Kardiologie sehr niedrig ist.
Komplikation
Maßnahme
Diagnostischer
Herzkatheter
Therapeutischer
Herzkatheter
MR
Ultraschall
Tab. 4.2:
Art (Beispiel)
Komplexität
Häufigkeit
Tod, Herzinfarkt, Schlaganfall, Lungenembolie,
Reanimation
Komplex
0,106 %
Gefäßprobleme
peripher,
Nachblutung, Bradykardien
Einfach
1,469 %
Tod, Herzinfarkt, Schlaganfall, Lungenembolie,
Reanimation
Komplex
0,232 %
Gefäßprobleme
peripher,
Nachblutung, Bradykardie
Einfach
1,468 %
KM-Reaktion,
KM-Reaktion,
Tod, Infarkt, Lungenödem, Flimmern
Komplex
0%
Bradykardie, Tachykardie
Einfach
0%
Tod, Infarkt, Lungenödem, Flimmern
Komplex
0%
Bradykardie, Tachykardie
Einfach
0,062 %
Art, Komplexität und Häufigkeit von Komplikationen. Die Häufigkeit wurde aus der
Datenbank der Kardiologie der Klinikum Oldenburg gGmbH im Zeitraum 01/2001 bis
09/2004 entnommen.
Das Auftreten einer Komplikation kann zur Folge haben, dass die Untersuchung
abgebrochen wird. Es wird jedoch in jedem Fall ein "ordnungsgemäßer Abschluss" des
medizinischen Verfahrens inkl. Dokumentation und Nachbereitung durchgeführt. Dies ist
auch dann der Fall, wenn der Patient als Notfall in eine andere Abteilung verlegt und dort
umgehend weiter behandelt werden muss. In der Kardiologie kann eine solche Verlegung in
die Herzchirurgie vorkommen, wenn eine Notfall-Bypass-Operation durch eine Komplikation,
wie z. B. einen Herzinfarkt, notwendig wird. Die Anzahl dieser Notfall-OPs ist in den letzten
Jahren aber stark rückläufig (vgl. Abb. 4.7), da durch die Einführung der Stents und der
Medikamentengruppe der GP-IIb-IIIa-Antagonisten dem Kardiologen Mittel an die Hand
8
Die Oldenburger Kardiologie liegt mit einer kumulativen Komplikationsrate (Betrachtung aller
Komplikationen, also einfache und komplexe Komplikationen) von 1,6% für das Jahr 2003 etwas
besser als der Bundesdurchschnitt, welcher hier 1,9% beträgt. Ebenso lag die Mortalitätsrate im
Herzkatheterlabor mit 0,04 % leicht unter dem Bundesdurchschnitt.
112
Serviceflows zur Modellierung klinischer Behandlungsketten
gegeben wurden, Patienten mit komplexen Komplikationen, denen vor 1998 nur mit einer
Not-OP geholfen werden konnte, im HK-Labor selbst zu stabilisieren.
0,9
Anteil Notfall-OPs in %
0,8
0,7
0,6
0,5
%
0,4
0,3
0,2
0,1
0
1997
1998
1999
2000
2001
2002
2003
2004
Jahr
Abb. 4.7
Prozentualer Anteil von Notfall-Operationen als Folge von Komplikationen an allen
Eingriffen im HK-Labor im Zeitraum 1998 bis 2004. Seit 1998 ist die Zahl der Not-OPs
gegenüber früher deutlich zurückgegangen.
Der einzig zwingende Grund für das Beenden und Neuaufnehmen einer Untersuchung ist
der Ausfall eines notwendigen medizinischen Gerätes während einer Untersuchung. Dies
passiert auf Grund der hohen Qualität der medizinischen Geräte sehr selten. Eine
Auswertung der Datenbank in Oldenburg ergab für die Jahre 2000 bis 2004 einen Wert von
durchschnittlich weniger als zwei Ausfällen pro Jahr und eine gesamte Ausfallquote von
0,013% bezogen auf alle in diesem Zeitraum durchgeführten Untersuchungen im HK-Labor.
In diesen Fällen wurde der Patient im zweiten HK-Labor weiter behandelt, sobald dieses frei
war. Der Arbeitsablauf wurde dort fortgesetzt als ob keine Unterbrechung stattgefunden
hätte, lediglich der Ausfall der Anlage wurde unter "internen Bemerkungen" festgehalten. Bei
Untersuchungen, bei denen kein stationär montiertes medizinisches Großgerät verwendet
wird (z. B. Ultraschall, EKG oder Operation), kann das defekte Gerät während des Eingriffs
durch ein Ersatzgerät ersetzt werden.
Zusammenfassend kann somit für die leistungserbringenden Unterabteilungen der
Kardiologie festgehalten werden, dass der Arbeitsablauf sowohl im Fall von Komplikationen
als auch bei anderweitigen unvorhergesehenen Ereignissen stets durch das
Dreiphasenmodell der DMM abgebildet werden kann. Dies führt zu
113
Serviceflows zur Modellierung klinischer Behandlungsketten
Definition 4.3: NLO (Normalisierte Leistungserbringende Organisationseinheit)
Bei einer NLO handelt es sich um eine Unterabteilung einer klinischen Fachabteilung (oder
um eine klinische Fachabteilung, falls diese nicht in Unterabteilungen organisiert ist),
•
die unabhängig von anderen Ressourcen, sowohl personeller als auch materieller
Art, diagnostische oder therapeutische Verfahren durchführt,
•
die Patienten "von außen" gebracht bekommt und nach der Untersuchung wieder
zurückverlegt, also nicht über eine eigene Patientenbetreuung verfügt, und
•
bei der "fast alle" (in der Praxis ist hier inzwischen durchaus eine untere Schranke
von mindestens 99 % realistisch) durchgeführten Maßnahmen dem Modell einer
DMM entsprechen.
Anmerkung zu Definition 4.3:
•
Die Unabhängigkeit von Ressourcen bezieht sich auf die Durchführung der Leistung
und nicht auf notwendige Voruntersuchungen wie z. B. Laborbefunde oder
Röntgenbilder, ohne die die Untersuchung nicht stattfinden kann. Ein Beispiel für die
Abhängigkeit von Ressourcen wäre z. B. die Defibrillatorimplantation. Hierfür muss
neben dem Chirurgen, der das Gerät einsetzt, ein Kardiologe, der die korrekte
Funktion des Aggregats überprüft und häufig zusätzlich ein Mitarbeiter des
Defibrillatorherstellers, welcher die Programmierung und Einstellung des Gerätes
durchführt, anwesend sein.
•
Bei der Patientenbetreuung ist eine Langzeitbetreuung im Sinne eines stationären
Aufenthaltes oder einer ambulanten Überwachung unterstellt. Jede medizinische
Abteilung ist in der Lage eine kurzzeitige Betreuung von Patienten durchzuführen.
Dies muss sie häufig auch leisten können, z. B. um ein Patientengespräch
durchzuführen, eine Wartezone anbieten zu können oder nach dem Eingriff zu
überwachen, dass keine ungewünschten Komplikationen auftreten. In
Herzkatheterlaboren gibt es dafür in der Regel Stellplätze für zwei bis fünf,
gelegentlich auch mehr Betten. Diese dienen als Wartezonen für Patienten, die als
nächstes behandelt oder abgeholt werden sollen, sowie zum Durchführen
abschließender Tätigkeiten, wie z. B. Abdrücken der Punktionsstelle9, die nicht im
HK-Labor durchgeführt werden müssen. Dadurch wird das HK-Labor nicht länger als
notwendig blockiert.
9
Die Punktionsstelle ist der Ort, an dem die Schleuse für die Herzkatheteruntersuchung in die Arterie
des Patienten eingeführt wird. Auch wenn es sich hierbei nur um eine kleine Verletzung einer
Schlagader handelt, muss diese zunächst kurz mit der Hand und später bis zu zehn Stunden mit
einem Druckverband sorgfältig verschlossen werden.
114
Serviceflows zur Modellierung klinischer Behandlungsketten
Bezogen auf Definition 4.3 sind sämtliche leistungserbringende Unterabteilungen der
Kardiologie der Klinikum Oldenburg gGmbH solche NLOen. Diese Feststellung gilt nach
Einschätzung des Autors auch für die weiteren über 40 Kardiologien in Deutschland, deren
Arbeitsabläufe dem Autor hinreichend bekannt sind.
4.4 Die strukturierte Krankenakte
Bevor die Struktur der leistungserbringenden medizinischen Abteilung weiter im Sinne eines
Serviceflows formalisiert werden kann, muss der Datenbestand, der im Rahmen der
dokumentarischen und administrativen Leistungen bearbeitet wird, definiert werden.
Jede NLO kann nur eine bestimmte Menge an Dienstleistungen erbringen, die durch ihren
Auftrag und die dazu angemessene personelle und materielle Ausstattung festgelegt ist.
Dies ist auch notwendig, da der behandelnde Arzt nur so entscheiden kann, welche
Abteilung er ansprechen muss, um die als nächstes geplante Maßnahme zu beantragen.
Somit kann für jede NLO festgelegt werden, welche dokumentarischen und administrativen
Aufgaben neben den medizinischen Leistungen erbracht werden müssen.
In der Krankenakte werden dabei in den drei Phasen einer DMM durch das verantwortliche
medizinische Personal die in Tab. 4.3 abgebildeten Leistungen dokumentiert. Jede Phase
einer DMM kann wiederum zusätzliche administrative Aufgaben beinhalten.
Phase
Dokumentarische Leistung
Administrative Durchgeführt
Leistung
von
Vorbereitung
Stammdaten, allgemeine Untersuchungsdaten
Pflegepersonal
Durchführung
Untersuchungsverlauf
Pflegepersonal
Nachbereitung
Prüfung und ggf. Korrektur der bisher erfassten
Daten
Dokumentation der gesamten medizinischen
Daten der Untersuchung von der Anamnese über
die Indikation bis zum Befund
Festlegen von Diagnose, Therapieempfehlung
und Procedere
Tab. 4.3:
Festlegen der
Ziffern für die
Liquidation
Erstellen aller
notwendigen
Reporte und
Briefe
Arzt
Dokumentarische und administrative Leistungen während der einzelnen Phasen einer
DMM
Die administrativen Daten werden zum einen der abrechnenden Stelle, die zumeist in der
Verwaltung zu finden ist, und zum anderen den im Rahmen des Eingriffs relevanten
Empfängern, wie z. B. dem Hausarzt, zugestellt. Informationen, die als Teil der
115
Serviceflows zur Modellierung klinischer Behandlungsketten
dokumentarischen Leistungen erfasst werden, werden in der Krankenakte abgelegt. In der
klassischen Form handelt es sich hierbei um eine Akte in Papierform.
In digitalen klinischen Informationssystemen ist die Krankenakte dargestellt durch eine
strukturierte Sammlung von Datenfeldern. Dies kann in unterschiedlichen Formen realisiert
sein, z. B. in einer relationalen oder hierarchischen Datenbank, im XML-Format mit oder
ohne eigenständiger "XML-Datenbank-Engine" oder in einem proprietären Format als
Sammlung von Dateien.
Derzeit gibt es aber keinen Standard, der den Aufbau oder Inhalt einer Krankenakte formal
definiert. Hinreichende Standardisierungen in der Medizinischen Informatik gibt es nur bei
der Kommunikation. Hier existieren mit HL7 und DICOM Standards, die genau definieren,
welche Informationen wie zwischen Modalitäten und Informationssystemen ausgetauscht
werden können.
Es gibt jedoch Standards und Vorgaben, die herangezogen werden können, um notwendige
Inhalte der Krankenakte abzuleiten:
•
Kommunikationsstandards: Sowohl in DICOM als auch in HL7 wird semantisch
und syntaktisch definiert, welche Daten wie in welcher Form zu übermitteln sind. Da
moderne klinische Abteilungsinformationssysteme mit Schnittstellen zur
Kommunikation ausgestattet sein sollten (vgl. z. B. [Hau95], [HAB01] oder
[WABH02]), ist es beim Entwurf sinnvoll, die in den Standards vorgeschriebenen
Datenfelder zu unterstützen.
•
Gesetzliche Richtlinien: Diese umfassen in Deutschland zum einen die für die
Leistungsübermittlung an die Krankenkassen relevanten Standards ICD, OPS-301,
GOÄ und EBM und zum anderen die an die BQS zu meldenden Daten für die
Qualitätssicherung der medizinischen Verfahren. In der Kardiologie betrifft dies die
Module "20/1 Perkutane Transluminale Angioplastie (PTA)" und "21/3
Koronarangiographie und perkutane transluminale Koronarangioplastie (PTCA)".
•
Leitlinien der Fachgesellschaften: In der Kardiologie sind hier besonders die
Empfehlungen der DGK zu beachten, welche für die Herzkatheteruntersuchung (vgl.
[EEK97]) und die Ultraschalluntersuchung des Herzens (siehe [HBL04] und [VKF04])
existieren.
•
Metamodelle klinischer Informationssysteme: Eines der bekanntesten Modelle ist
hier das 3LGM2 (vgl. [WBW03]). Ein Teil des 3LGM2-Baukastens ist auch ein
Referenzmodell, welches Objekte, die physische oder virtuelle Objekte eines
Krankenhauses repräsentieren, beschreibt (vgl. [Hübn04]). Diese Objekte wiederum
werden durch Daten repräsentiert. Ein anderer, mehr informeller Ansatz zur
Modellierung der Krankenakte findet sich in [HWAB04]. Hier werden grundsätzliche
Anforderungen gestellt, die für die speziellen Bedürfnisse der klinischen Abteilungen
durch das Experten- und Domänenwissen von Modellierer und Anwender
vervollständigt werden sollen.
116
Serviceflows zur Modellierung klinischer Behandlungsketten
Für die Definition der SK wird hier eine formale Definition der Grundstruktur auf der Basis
des Relationenmodells nach [Cod70] gegeben. Dies basiert auf der Überlegung, dass später
bei der Vorstellung des Frameworks die Datenhaltung durch ein RDBMS (relationales
Datenbankmanagementsystem) realisiert wird. Diesem klassischen Ansatz wurde der
Vorzug gegenüber anderen Ansätzen wie z. B. XML- oder Objektdatenbanken gegeben, da
RDBMSe derzeit eine höhere Performance bieten und das zu Grunde liegende Projekt GOKard
(siehe
[GOKARD])
ein
relationales
Datenmodell
verwendet,
dessen
Erstimplementierung auf das Vorläuferprojekt INKA (siehe [AZM92], [Rei90]) aus dem Jahr
1989 zurückgeht.
Für dieses Grundgerüst wird dann auf informeller Ebene festgelegt, welche Informationen in
der SK enthalten sein sollen. Die konkrete Umsetzung für das Beispiel Kardiologie kann der
Webseite von GO-Kard (www.gokard.de) entnommen werden.
Jedes Feld repräsentiert einen zu dokumentierenden Teil der medizinischen Leistung. Dies
kann z. B. ein Messwert, eine Fragestellung bei der Indikation, die nur mit "Ja" oder "Nein"
zu beantworten ist, oder auch ein Freitext sein.
Es können sechs grundsätzliche Typen von Datenfeldern identifiziert werden, aus denen die
SK aufgebaut ist:
•
Messwerte, die durch Zahlen repräsentiert sind. Diese können entweder Ganz- oder
Dezimalzahlen sein. Sie können im Rahmen der medizinischen Leistung nur Werte
innerhalb eines für dieses Feld eindeutigen Intervalls mit endlicher oberer und
unterer Grenze annehmen. Wurde die Messung nicht durchgeführt, kann das
entsprechende Datenfeld auch leer sein (null - Wert).
•
Zeitfelder, die entweder Datumsangaben, Uhrzeiten oder Kombinationen aus
beidem enthalten.
•
Auswahlfelder, die nur diskrete Werte aus einer vorgegebenen Menge von Werten
annehmen können. Insbesondere umfasst dies Fragestellungen, die nur mit Ja oder
Nein beantwortet werden können.
•
Freitexte, die beliebige, aber natürlich in der Länge beschränkte Zeichenketten, z. B.
für Befunde oder Bemerkungen, enthalten können.
•
Binäre Objekte (BLOB = Binary Large Object), die beliebige, aber in ihrer Länge
beschränkte Binärdaten, zumeist Multimedia-Objekte wie Filme, Bilder oder Töne,
enthalten können.
•
ID-Felder, die Identifikationsnummern zur eindeutigen Identifikation von Datensätzen
enthalten.
Für jedes Feld gibt es Merkmale, die teilweise abhängig von ihrem Typ sind. Diese
Merkmale und die Typen, für die sie zutreffen, sind Tab. 4.4 zu entnehmen.
117
Serviceflows zur Modellierung klinischer Behandlungsketten
Merkmal
Messwert
Zeitfeld
Auswahlfeld
Freitext
Binäres
Objekt
ID-Feld
Eindeutiger
Name
Pflicht
Pflicht
Pflicht
Pflicht
Pflicht
Pflicht
Semantische
Bedeutung
Pflicht
Pflicht
Pflicht
Pflicht
Pflicht
Pflicht
Datentyp
Zahl
Datum inkl.
Uhrzeit
Text
Text
Binär
Zahl
Dimension
Zahl mit
fester
Anzahl an
Vor- und
Nachkommastellen
Jahr, Monat, beschränkte
Tag, Stunde, Länge
Minute,
Sekunde,
Millisekunde
beschränkte
Länge
theoretisch
unbeschränkte
Länge,
praktische
Beschränkung durch
Hard-/
Software
Ganzzahl mit
fester Anzahl
an Stellen
Messwertdimension /
Einheit
Optional
n. a.
n. a.
n. a.
n. a.
n. a.
Codetabelle
Optional
Optional
Pflicht
Optional
n. a.
n. a.
Bereichsgrenzen
minimal und
maximal
Pflicht
Pflicht
n. a.
n. a.
n. a.
>0
Normwert /
Normwertbereich
Optional
Optional
Optional
Optional
n. a.
n. a.
Tab. 4.4:
Merkmale von Datenfeldern. "Pflicht" bedeutet, dass das Feld dieses Merkmal haben
muss, "Optional" steht für Merkmale, die das Feld haben kann, aber nicht muss und "n. a."
bedeutet, dass das Merkmal für das Feld nicht anwendbar ist.
Weiterhin muss die hier vorgestellte Akte eine interne Struktur aufweisen, die in natürlicher
"Weise" aus drei Ebenen besteht. Diese sind Patientenstammdaten, anamnestische
Einträge und die Dokumentation der einzelnen medizinischen Eingriffe. Jeder Patient besitzt
mehrere anamnestische Einträge. Dies können klinische Ereignisse oder Aufenthalte
innerhalb einer medizinischen Institution, wie z. B. ein Besuch bei einem niedergelassenen
Arzt oder ein Krankenhausaufenthalt, sein. Für jeden Aufenthalt in einer medizinischen
Institution gibt es wiederum einen oder mehrere Einträge, die die Dokumentation der
medizinischen Leistungen, welche in den unterschiedlichen NLOen während des
Aufenthaltes erbracht wurden, repräsentieren (vgl. Abb. 4.8).
Die Erfassung der Daten in der zweiten und dritten Ebene erfolgt stets mit einem Zeitbezug.
Handelt es sich um einen Aufenthalt in einer medizinischen Institution wie z. B. einer Klinik,
so muss eine Zeitspanne dokumentiert sein. Neben dem Erbringungszeitpunkt ist für die
Dokumentation in der NLO auch die Angabe des verantwortlichen Arztes notwendig.
118
Serviceflows zur Modellierung klinischer Behandlungsketten
Patient
Anamnestischer
Eintrag 1
Dokumentation für
NLO 1
Anamnestischer
Eintrag 2
Dokumentation für
NLO 2
Anamnestischer
Eintrag 3
...
...
Anamnestischer
Eintrag n
Dokumentation für
NLO m
Abb. 4.8: Die drei Ebenen "Patient", "Anamnese" und "Leistungsdokumentation" und deren
Zusammenhang innerhalb der SK
Dies ist insbesondere bei Akten chronisch Kranker wichtig, da hier häufig zu
unterschiedlichen Zeiten dieselben NLOen den Patienten behandeln und somit dieselben
Krankheitsbilder befundet werden. Diese müssen in chronologischer Reihenfolge darstellbar
sein, um dem behandelnden Arzt den Krankheits- und Behandlungsverlauf zu zeigen.
Weiterhin kann nur durch die zeitliche Kennzeichnung von Datensätzen eine chronologische
Synchronisation zur Darstellung von Diagnose-Therapie-Erfolg- und Ursache-WirkungKetten erzielt werden.
Im Folgenden wird die Definition des relationalen Modells nach [Cod70] zu Grunde gelegt.
Zunächst werden die drei Ebenen der SK als Datenschemata definiert:
Hilfsdefinition 4.4a: Patientendatenschema PD
PD = (pd1, ..., pdn) mit n ∈ IN und n > 0 ist ein nicht leeres n-Tupel von Relationenschemata
pdi mit
•
pd1 enthält Attribute für grundlegende Patientenstammdaten, die den Patienten identifizieren, mindestens Nachname, Vorname, Geburtsdatum, Geburtsort, Anschrift.
•
pd1 besitzt ein Attribut vom Feldtyp ID-Feld, welches hier als PID bezeichnet werden
soll, und eindeutig ist, also gilt:
∀ PIDi und PIDj ∈ pd1 mit i ≠ j : PIDi ≠ PIDj.
Dieses Feld PID ist die eindeutige Identifikationsnummer des Datensatzes eines
Patienten, also ein Primärschlüssel.
•
Alle Relationen pdl mit l > 1 enthalten ebenfalls ein Attribut PID und sind darüber
funktional von pd1 abhängig. Diese Relationen enthalten somit weitere relevante
Informationen, die einzig vom Patienten abhängig sind und nicht von medizinischen
Leistungen (z. B. unveränderbare Informationen wie die Blutgruppe).
119
Serviceflows zur Modellierung klinischer Behandlungsketten
Hilfsdefinition 4.4b: Anamnestisches Datenschema AD
AD = (ad1, ..., adn) mit n ∈ IN und n > 0 ist ein nicht leeres n-Tupel von Relationenschemata
adi mit
•
ad1 besitzt ein Attribut vom Feldtyp ID-Feld, welches hier als ANR bezeichnet werden
soll, und für jeden Datensatz eindeutig ist, also gilt:
∀ ANRi und ANRj ∈ ad1 mit i ≠ j : ANRi ≠ ANRj.
•
ad1 enthält Attribute, die grundlegende Informationen zu einem anamnestischen
Ereignis darstellen. Mindestens müssen ein ID-Feld (die ANR) zur eindeutigen
Identifikation des Eintrages, ein ID-Feld PID als Fremdschlüssel, welcher der
Verweis auf die zugehörigen Patientendaten ist, ein Startdatum (von), ein
Endedatum (bis) und eine Beschreibung des Ereignisses enthalten sein (das
Endedatum ist für die Dokumentation von Aufenthalten in medizinischen Institutionen
erforderlich).
•
Alle Relationen adl mit l > 1 enthalten ebenfalls ein Attribut ANR und sind darüber
funktional von ad1 abhängig. Diese Relationen enthalten somit weitere relevante
Informationen, die einzig vom anamnestischen Ereignis bzw. Aufenthalt abhängig
sind und nicht vom Patienten oder medizinischen Leistungen (z. B.
Einweisungsdaten).
Hilfsdefinition 4.4c: Datenschema zur Dokumentation medizinischer Leistungen LD
LD = (ld1, ..., ldn) mit n ∈ IN und n > 0 ist ein nicht leeres n-Tupel von Relationenschemata ldi
mit
•
ld1 besitzt ein Attribut vom Feldtyp ID-Feld, welches hier als DOKNR bezeichnet
werden soll, und eindeutig ist, also gilt:
∀ DOKNRi und DOKNRj ∈ ld1 mit i ≠ j : DOKNRi ≠ DOKNRj.
•
ld1 enthält Attribute, die grundlegende Informationen zur Dokumentation einer
medizinischen Leistung repräsentieren. Mindestens müssen ein ID-Feld (die DOKNR)
zur eindeutigen Identifikation des Eintrages, ein ID-Feld ANR als Fremdschlüssel,
welcher der Verweis auf den zugehörigen anamnestischen Eintrag ist,
Erbringungsdatum, verantwortlicher Arzt, Ort und Räumlichkeit vorhanden sein.
•
Alle Relationen ldl mit l > 1 enthalten ebenfalls ein Attribut DOKNR und sind darüber
funktional von ld1 abhängig. Diese Relationen enthalten weitere relevante
Informationen, die einzig von der Dokumentation der medizinischen Leistung
abhängig sind und nicht vom Patienten oder dem Aufenthalt (z. B. Messwerte oder
Verlaufsprotokoll).
120
Serviceflows zur Modellierung klinischer Behandlungsketten
•
Es gibt Relationen ldo, ..., ldp mit 1 < o ≤ p, in welchen die folgenden Informationen zu
einer medizinischen Leistung erfasst werden können:
o
Indikation
o
Materialverbrauch inkl. Medikamenten
o
Verlauf der Untersuchung inkl. Komplikationen
o
Diagnose
o
Befund
o
Procedere (Vorschlag für die kurzfristige weitere Behandlung in der Klinik)
o
Therapieempfehlung (Vorschlag für die langfristige weitere Behandlung, auch
außerhalb der Klinik)
o
Daten zur Kommunikation mit Drittsystemen
o
Abrechnungsinformationen, insbesondere Codes nach den aktuell gesetzlich
vorgeschriebenen Codierungsschemata (derzeit sind dies in Deutschland für
Krankenhäuser der "ICD Version 2.0" und der "OPS-301").
Auf Basis dieser Hilfsdefinitionen kann nun die "Strukturierte Krankenakte" definiert werden.
Definition 4.4: SK (Strukturierte Krankenakte)
Eine SK ist ein Tupel (P, A, L1, ..., Ln, C) mit
•
P ist ein PD.
•
A ist ein AD.
•
L1, ..., Ln sind jeweils LD.
•
C = {c1, ..., cm} mit m ∈ IN ist ein Datenschema mit zusätzlichen Relationen, die
Zusatzinformationen wie z. B. Codeschemata für die Abrechnung (Liste aller ICDund OPS-Codes) oder das Personal enthalten.
•
Jeder anamnestische Eintrag hat einen Fremdschlüssel PID, über den er eindeutig
einem Patienten zugeordnet ist. Also ist a1 über die PID funktional abhängig von p1:
∀ pidi ∈ a1i ∃ 1 pidj ∈ p1 mit pidi = pidj.
•
Jede medizinische Leistung hat einen Fremdschlüssel ANR, über den sie eindeutig
einem anamnestischen Eintrag zugeordnet ist. Also sind l11, ... , l1n über ihre ANR
funktional abhängig von a1:
∀ anr1k ∈ l1k mit 1 ≤ k ≤ n ∃ 1 anrm ∈ a1 mit anrm = anr1k.
121
Serviceflows zur Modellierung klinischer Behandlungsketten
4.5 Die NLO im klinischen Kontext
Jede NLO kann als "black box" angesehen werden, die eine genau definierte Menge
medizinischer Maßnahmen durchführen kann (vgl. Abb. 4.9). Grundsätzlich könnten die
NLOen auch "losgelöst vom Rest der Klinik" für sich alleine existieren. Diese Sichtweise ist
auch nicht völlig praxisfremd, da beim Outsourcen klinischer Fachabteilungen in
eigenständige Facharztpraxen genau dies bereits mitunter geschieht. Hier werden
Abteilungen, die nicht auf eine klinische Integration, insbesondere eine längere stationäre
Betreuung, angewiesen sind, zu eigenständigen Institutionen. Diese wiederum haben eine
hohe Spezialisierung, die dazu führt, dass Patienten mit enger abgegrenztem Krankheitsbild
hierhin überwiesen, genau bezüglich dieses Krankheitsbilds behandelt und wieder zurück
überwiesen werden.
Patient mit eng abgegrenztem
Krankheitsbild
NLO:
Behandlung des Patienten
Behandelter Patient
Befund
Abb. 4.9: Die NLO als "black box". Von außen gesehen wird der Patient auf Grund seines
Krankheitsbildes behandelt und nachher mit dem Befund, der im Rahmen der
Dokumentation erstellt wird, wieder zurück überwiesen.
In Deutschland wurden in den letzten Jahren bereits einige Fachabteilungen, insbesondere
Radiologien, Labore und Kardiologien, erfolgreich "outgesourced". Namhafte Beispiele aus
dem kardiologischen Bereich sind hier "Mathey, Schofer und Partner" in Hamburg oder
"Prof. Reifart und Partner" in Frankfurt. Tatsächlich ist die ambulante Behandlung der
Patienten durch die Kardiologie der Klinikum Oldenburg gGmbH auch keine klinische
Tätigkeit, sondern eine medizinische Maßnahme, die selbstständig ohne Nutzung weiterer
klinischer Ressourcen durch die entsprechende NLO durchgeführt wird. Während des
Ambulanzbetriebs wird also auch in der Klinik wie in einer "outgesourcten" Fachabteilung
gearbeitet.
Die gesamte Kardiologie kann als Zusammenstellung einzelner, unabhängig
operationsfähiger Einheiten gesehen werden. Diese verfügen jeweils über unterschiedliche
medizinische Geräte und haben als Gemeinsamkeit die Behandlung des Krankheitsbildes
der Herzerkrankungen (vgl. Abb. 4.10).
122
Serviceflows zur Modellierung klinischer Behandlungsketten
Station inkl. Ambulanz-Station
EKG
Echo
MR
HK-Labor
Ambulanz
Abb. 4.10: Unterabteilungen innerhalb der kardiologischen Abteilung: Jede Einheit kann selbständig
arbeiten. Zugeführt (rote Pfeile mit durchgezogener Linie) werden Patienten mit
Herzerkrankungen von den zuständigen Stationen oder der Ambulanz. Nach
Durchführung der medizinischen Maßnahme werden die Patienten wieder zurück
überstellt (grüne Pfeile mit gestrichelter Linie).
Es stellt sich nun die Frage, wie sich diese Unterabteilungen in den klinischen
Behandlungsablauf einfügen. Bisher wurde nur betrachtet, welche Maßnahmen durch eine
solche Abteilung durchgeführt werden können. Wie wird aber die Entscheidung getroffen,
wann welcher Patient unter welchen Bedingungen durch welche Abteilungen versorgt wird?
Wie in Abb. 4.10 zu erkennen ist, wird der Patient in der Regel über die zuweisende Station
verlegt. Hier hält sich der Patient in der Zeit auf, in der er nicht durch leistungserbringende
Unterabteilungen behandelt wird. In dieser Zeit wird die Entscheidung, welche Maßnahme
als nächstes angewendet wird, durch den zuständigen Ober- oder Chefarzt getroffen (vgl.
Abb. 4.11).
Dieser orientiert sich dazu
•
am aktuellen Erscheinungs- und Krankheitsbild des Patienten,
•
an den Ergebnissen der bereits durchgeführten Maßnahmen,
•
an den Behandlungsrichtlinien der Fachgesellschaften (im Falle der Kardiologie ist
dies die DGK) und
•
an den eigenen Erfahrungen.
Zusätzlich kann der behandelnde Arzt auf das Fachwissen von Kollegen zurückgreifen.
Dazu kann auch die Meinung eines Arztes aus einer anderen Disziplin im Rahmen eines
Konsils eingeholt werden.
123
Serviceflows zur Modellierung klinischer Behandlungsketten
Einweisung
Ober-/Chefärztliche
Entscheidung
EKG notwendig
Echo notwendig
Externe Leistung
notwendig
HK notwendig
MR notwendig
EKG
Echo
MR
Ober-/Chefärztliche
ProcedereEntscheidung
HK-Labor
Externe
Leistung (z.B.
Labor)
Weitere Maßnahme notwendig
Patient muß überwiesen werden
Patient entlassbar („geheilt“)
Überweisung in
andere Abteilung /
Klinik
Entlassung
Abb. 4.11: Entscheidung für die nächste Maßnahme durch den Chef-/Oberarzt. Nach jeder Leistung
durch eine NLO liegt ein Befund vor, der wiederum Grundlage für die Entscheidung in
"Procedere-Entscheidung" ist.
Werden nun nicht die einzelnen leistungserbringenden Abteilungen unterschieden, sondern
diese als "black boxes" betrachtet, so kann der gesamte Behandlungsprozess innerhalb der
Klinik durch den in Abb. 4.12. dargestellten Ablaufprozess abgebildet werden.
124
Serviceflows zur Modellierung klinischer Behandlungsketten
Einweisung
Erhebung der Einweisungs- und
Aufnahmediagnose
Patient wird stationär behandelt/betreut und
wartet auf Entscheidung des zuständigen
Arztes
Ober-/Chefärztliche
Entscheidung anhand des
aktuellen Patientenstatus
Maßnahme notwendig
Patient muß durch
andere Abteilung/Klinik
behandelt werden
Patient geheilt
oder nicht weiter
behandelbar
Verlegung
Leistungserbringende
Abteilung führt
Maßnahme durch
Entlassung
nach Hause
Abb. 4.12: Verallgemeinerter Ablauf der Behandlung in einer Klinik. Der "Sonderfall", dass der Patient
verstirbt, wurde hier nicht betrachtet. In diesem Fall wird direkt zur "Entlassung"
übergangen und keine weitere Aktion durchgeführt.
Hierbei ist zu beachten, dass durch jede Maßnahme, beginnend mit der Erhebung der
Einweisungs- und Aufnahmediagnose, die Informationen über das Krankheitsbild des
Patienten ständig aktualisiert und Krankheitssymptome bekämpft werden. Dadurch ändert
sich die Entscheidungsgrundlage für den zuständigen Arzt, wodurch die Behandlung
fortschreitet.
Im Folgenden soll aus Gründen einer vollständigen und konsistenten Modellierung auch die
stationäre Behandlung/Betreuung, also das Warten auf die nächste ärztliche Entscheidung,
125
Serviceflows zur Modellierung klinischer Behandlungsketten
als medizinische Maßnahme betrachtet werden, die durch die Station erbracht wird, damit
der Zustand eines Patienten im Rahmen seines Krankenhausaufenthaltes zu jedem
Zeitpunkt t durch folgende zwei Parameter charakterisiert werden kann:
1. das aktuelle Krankheitsbild, für den Arzt repräsentiert durch die SK,
2. die Maßnahme, die gerade am Patienten durchgeführt wird.
Nun kann die Definition der NLO [Def. 4.3] um die Aspekte der Vorbedingungen und
Modifikation der SK erweitern werden.
Hilfsdefinition 4.5a: Menge aller erbringbaren medizinischen Dienstleistungen
DA wird definiert als nicht leere, endliche Menge aller bekannten und von einer NLO
erbringbaren medizinischen Dienstleistungen.
Hilfsdefinition 4.5b: Text-, Zahlen und Datumsgeneratoren für Attribute (TGATXT, NGANUM
und DGADAT)
Sei Z = {0, ..., 9, A, ..., Z, a, ..., z, ä, ö, ü, Ä, Ö, Ü, ß, , !, ..., .} die Menge aller Zeichen,
Sonderzeichen und Ziffern, die beim Schreiben deutscher Dokumentationseinträge
Anwendung finden können. Dann ist Z* die Menge aller schreibbaren Texte, welche auch
den leeren Text beinhaltet.
Sei weiterhin ATXT ein Attribut einer SK vom Datentyp Freitext. Dann ist TGATXT ein
Textgenerator, welcher einen beliebigen Text T ∈ Z* generieren kann, der die
Merkmalsbeschreibungen von ATXT nicht verletzt, also keine Texte generiert, die länger als
die maximale Länge von ATXT sind und, wenn ATXT auf einer Codeliste basiert und somit
ein Aufzählungstyp ist, nur Texte aus dieser Codeliste generiert. Analog existieren
Zahlengeneratoren NGANUM für Messwerte ANUM und Datumsgeneratoren DGADAT für
Zeitfelder ADAT.
Definition 4.5: ENLO (Erweiterte NLO)
Sei sk eine SK. Eine ENLO EN = (Bez, D, V, M, N) ist ein Quintupel, für das gilt:
•
•
Bez ist eine eindeutige Bezeichnung der ENLO.
D = {d1, ..., dn} ⊆ DA mit n ∈ IN ist eine nicht leere Menge von Dienstleistungen
(DMM), die von der ENLO erbracht werden können und den Anforderungen von
medizinischen Leistungen, die eine NLO erbringen kann, gerecht werden (also
Unabhängigkeit von externen Ressourcen, keine Langzeitbetreuung von Patienten
und alle Dienstleistungen sind DMM) .
126
Serviceflows zur Modellierung klinischer Behandlungsketten
•
V = {v1, ..., vm} mit m ∈ IN und m ≥ n ist eine nicht leere Menge von Vorbedingungen,
die Indikationen zur Anwendung aller durch diese Abteilung erbringbaren
Dienstleistungen aus D sind.
•
Für jede Dienstleistung gibt es mindestens eine Vorbedingung (Indikation). Es gilt
also:
∀ di ∈ D mit 1 ≤ i ≤ n ∃ vj ∈ V mit 1 ≤ j ≤ m: vj ist Vorbedingung (Indikation) von di.
•
•
Seien {T1, ..., To} mit o ∈ IN0 alle Attribute von sk, die vom Datentyp Freitext sind,
{N1, ..., Np} mit p ∈ IN0 alle Attribute von sk, die vom Datentyp Messwerte sind und
{D1, ..., Dq} mit q ∈ IN0 alle Attribute von sk, die vom Datentyp Datum sind (dann
entspricht {T1, ..., To} ∪ {N1, ..., Np} ∪ {D1, ..., Dq} also gerade allen Attributen von sk
außer den ID-Feldern).
Dann ist M = {TGT1, ..., TGTo} ∪ {NGN1, ..., NGNp} ∪ {DGD1, ..., DGDq} die Menge der
Modifikatoren, bestehend aus Textgeneratoren TGT1, ..., TGTo, Zahlengeneratoren
NGN1, ..., NGNp und Datumsgeneratoren DGD1, ..., DGDq, mit deren Hilfe der Inhalt von
sk angelegt und verändert werden kann.
N = {n1, ..., np} mit p ∈ IN ist eine nicht leere Menge von Nachbedingungen, die
Empfehlungen für das mögliche Procedere nach Erbringung der Dienstleistung sind.
Anmerkung zu Definition 4.5:
•
Die Schritte zur Durchführung der Dienstleistungen können als Workflows angesehen und mit bekannten Sprachen des Workflow-Managements modelliert werden.
•
In der Praxis entspricht M einer Software zum Laden, Anzeigen, Manipulieren und
Speichern von Einträgen der SK.
4.6 Der medizinische Service Point
Im Sinne des in Kapitel 2 eingeführten Konzepts "Serviceflow" entspricht eine ENLO einem
SP und die SK dem Servicefloat. Dieses wird durch die Anspruchnahme der Dienstleistung
des Servicepunkts durch den Kunden, in diesem Fall repräsentiert durch den Patienten,
modifiziert. Im Kontext dieser Arbeit werden noch einige zusätzliche Objekte, Bedingungen
und Zustände benötigt, die dann den medizinischen Service Point definieren.
Neben der SK muss der aktuelle Status des Patienten als eigenständiges Objekt
festgehalten werden. Teilweise ist dieser Aspekt auch im Serviceflow-Modell durch die
Orientierung abgebildet. Im klinischen Kontext muss aber neben der Darstellung der
127
Serviceflows zur Modellierung klinischer Behandlungsketten
möglichen Optionen für die Weiterführung der Dienstleistung mehr Information für die ober/chefärztliche Entscheidung bzgl. der Behandlungsfortführung vorgehalten werden. Dies
beinhaltet neben der Information, wo sich der Patient gerade aufhält, die Historie der bereits
bei ihm durchgeführten, angeforderten und geplanten Leistungen.
Dieser PS ist für die Entscheidungsträger, also die Chef- und Oberärzte, wichtig, da sie so
einen schnellen Überblick über den aktuellen Verlauf bekommen und den nächsten
Behandlungsschritt planen, anordnen und/oder durchführen können. Diese Entscheidung
durch einen verantwortlichen Arzt ist wiederum ein Aspekt, der als generelle Vorbedingung
für eine medizinische Leistung modelliert werden muss. Im klinischen Serviceflow
entscheidet in vielen Situationen der Arzt, also der Dienstleister, und nicht der Kunde, also
der Patient, über den Fortlauf der Behandlung. Dies ist insbesondere dann der Fall, wenn
der Patient nicht entscheidungsfähig, z. B. weil er bewusstlos oder vorübergehend nicht
entscheidungsfähig ist. Auch bei Entscheidungen, die in Abstimmung mit dem Patienten
oder sogar auf dessen Wunsch gegen den ärztlichen Rat getroffen wurden, muss häufig
durch einen Arzt die Anordnung, Überweisung oder Entlassung durchgeführt werden.
Im Fall des medizinischen Service Points hat der zuständige Chef- oder Oberarzt als
Entscheidungsträger dafür zu sorgen, dass es eine passende Indikation, welche in der SK
festgehalten wird, für die Behandlung gibt. Bei den medizinischen Leistungen, für die im
Rahmen der Bundesqualitätssicherung ein Dokumentationsbogen an die BQS zu melden ist,
ist die Angabe der Indikation daher auch ein verpflichtender Teil.
Da innerhalb einer ENLO unterschiedliche Eingriffe durchgeführt werden können, muss dies
auch für den medizinischen Service Point modelliert werden. Konsequenter Weise müssen
Hintergrund-, Support-Prozesse und Kooperationserfordernisse auch der durchzuführenden
Leistung und nicht nur dem Service Point zugeordnet werden.
In Abb. 4.13 ist der grundsätzliche Aufbau des medizinischen Service Point grafisch
dargestellt.
Vor der Definition des medizinischen Service Points als Erweiterung einer ENLO muss noch
der PS definiert werden:
Definition 4.6a: Bezeichnung einer medizinischen Dienstleistung.
Sei DA die Menge aller Dienstleistungen, ist
•
B(DA) die Menge aller Bezeichnungen von Dienstleistungen und
•
b(di) ∈ B(DA) die Bezeichnung einer Dienstleistung di ∈ DA.
128
Serviceflows zur Modellierung klinischer Behandlungsketten
Verlegung
Setzen
Medizinischer Service Point
Indikation
...
Vorbereitung
Aktivieren
Daten
Hintergrundprozesse /
Leistungen in
anderen
Abteilungen
A1
A1
A1
Frage?
Frage?
Frage?
A2
A3
A2
A3
V1
A4
V2
A4
A2
...
Mod.
A3
A4
Vn
SK
(Service
-float)
Durchführung
Daten
A1
A1
A1
Frage?
Frage?
Frage?
A2
D1
A3
A2
A3
A4
D2
A4
...
Status
Mod.
A2
A3
Dm
A4
Aktivieren
Nachbereitung
Daten
Aktivieren
A2
Daten
N1
A1
A1
A1
Frage?
Frage?
Frage?
A3
A2
A3
A4
N2
A4
A2
...
Nl
Mod.
A3
A4
Setzen
Verlegung
Abb. 4.13: Aufbau des Medizinischen Service Points. Zunächst wird im PS die aktuelle Situation "In
den Service Point verlegt" vermerkt. Anhand der Indikation wird dann entschieden,
welches Verfahren angewendet wird. Innerhalb der einzelnen Phasen wird die SK
modifiziert und ggf. Hintergrundprozesse ausgelöst, die eventuell Daten (z. B.
Untersuchungsergebnisse von Blutproben) umgehend oder zur späteren Verwendung
zurück liefern. Schließlich verlässt der Patient den Service Point wieder, was seinen
Status in den Zustand "Untersuchung X mit Ergebnis Y durchgeführt" verändert.
129
Serviceflows zur Modellierung klinischer Behandlungsketten
Definition 4.6b: PS (Patientenstatus)
PS = (L, G, K, O, pid) ist ein nicht leeres Quintupel mit
•
pid ist ein ID-Feld, welches eine eindeutige Patienten-ID enthält
•
L = {l1, ..., ln} mit n ∈ IN. Die einzelnen Elemente li = (lbi, ldi) mit 1 ≤ i ≤ n, wobei lbi die
Bezeichnung einer Dienstleistung und ldi die Bezeichnung eines Datums inkl. Uhrzeit
sind, sind Tupel, welche die im Rahmen des Aufenthaltes bereits durchgeführten
Leistungen bzgl. Bezeichnung und Datum repräsentieren. L ist bei der Aufnahme des
Patienten leer.
•
G = {g1, ..., gm} mit m ∈ IN. Die einzelnen Elemente gj = (gbj, gdj) mit 1 ≤ j ≤ m, wobei
gbj ∈ DA die Bezeichnung einer Dienstleistung und gdj die Bezeichnung eines
Datums inkl. Uhrzeit sind, sind Tupel, welche die geplanten Leistungen bzgl.
Bezeichnung und gewünschtem Erbringungsdatum darstellen. G ist bei der
Aufnahme des Patienten nicht leer und enthält die geplante Leistung, wegen der der
Patient aufgenommen wurde. Diese ist immer bekannt, da im Normalfall eine
Einweisungsdiagnose durch einen niedergelassenen Arzt gestellt wird oder bei
Notfällen der Notarzt oder die Notfallaufnahme der Klinik die Indikation zur klinischen
Behandlung stellt.
•
K = (kb, kd), wobei kb ∈ DA die Bezeichnung einer Dienstleistung und kd die
Bezeichnung eines Datums inkl. Uhrzeit sind, welche die beim Patienten aktuell
durchgeführte Dienstleistung bzgl. Bezeichnung und Datum inkl. Uhrzeit, zu der
diese Dienstleistung begonnen wurde, repräsentiert.
•
O = {o1, ..., op} mit p ∈ IN. Die einzelnen Elemente ok = (obk, odk) mit 1 ≤ k ≤ p, wobei
obk ∈ DA die Bezeichnung einer Dienstleistung und odk die Bezeichnung eines
Datums inkl. Uhrzeit sind, sind Tupel, welche die noch bei dem Patienten offenen
Dienstleistungen bzgl. Bezeichnung und Datum darstellen. Im Gegensatz zu G
werden in O nur Dienstleistungen vermerkt, die abgearbeitet werden müssen, wie
z. B. das Schreiben des Entlassungsbriefes nach der Entlassung. Die Angabe des
Datums inkl. Uhrzeit od bezieht sich auf den Zeitpunkt zu dem festgestellt wurde,
dass ob durchgeführt werden muss.
Definition 4.6c: Zusammengehörigkeit von SK und PS
Sei ps ein PS und sk eine SK. Sei weiterhin pd das Patientendatenschema von sk. ps und sk
sind genau dann zusammengehörig, wenn Sie sich auf denselben Patienten beziehen, also
pidps = PIDpd.
130
Serviceflows zur Modellierung klinischer Behandlungsketten
Definition 4.6d: Krankenakte SKpid und PS PSpid eines Patienten
Sei pid die eindeutige Patienten-ID eines Patienten, dann ist
•
SKpid die Krankenakte, die durch den Eintrag in der Relation pd1 (vgl. Hilfsdefinition
4.3.a) des Patientendatenschemas repräsentiert wird, welcher als Inhalt des IDFeldes PID den Wert pid hat.
•
PSpid ist der PS dessen PID den Wert pid hat.
Definition 4.6e: Aktivatoren
Ein Aktivator A = (ABT, AUF, pid, TA) ist ein Quadrupel mit
•
ABT = {D, V, M} ist der eindeutige Name einer ENLO, die durch den Aktivator den
Auftrag zur Durchführung der Dienstleistung AUF erhält.
•
AUF ∈ D ⊆ DA ist eine Dienstleistung, die von ABT durchgeführt werden kann, und
den Arbeitsauftrag, der aktiviert werden soll, repräsentiert. Es muss also stets darauf
geachtet werden, dass die gewünschte Dienstleistung auch tatsächlich von ABT
durchgeführt werden kann.
•
pid ist die eindeutige Patienten-ID des Patienten, für den der Auftrag durchgeführt
werden soll. Darüber kann ABT zur Abarbeitung des Auftrags auch Zugriff auf den
PS PSpid und die Krankenakte SKpid des Patienten bekommen und auf alle dort
verfügbaren Informationen zurückgreifen.
•
TA ist ein Zeitpunkt zu dem der Auftrag möglichst abgearbeitet sein soll. TA liegt somit
immer in der Zukunft und kann von der Stelle, die den Auftrag erhält, als
Anhaltspunkt für die Dringlichkeit in Abhängigkeit vom Auftrag gesehen werden. So
kann bei nicht dringlichen Aktionen, wie z. B. pathologische Befunde, TA als
"gewünschter Zeitpunkt" interpretiert werden. Bei Aktionen, die auf Grund einer für
einen Patienten lebensbedrohlichen Situation, wie z. B. "Durchführung eines CT bei
Verdacht auf Aortendissektion" oder "Akut-PTCA bei Verdacht auf Herzinfarkt",
angeordnet werden, kann TA als spätester Zeitpunkt interpretiert werden. Meistens
wird in dringlichen Fällen von einem schnellst möglichen Beginn der medizinischen
Maßnahme ausgegangen.
Jetzt kann der medizinische Service Point als Erweiterung und Präzisierung der ENLO
definiert werden:
131
Serviceflows zur Modellierung klinischer Behandlungsketten
Definition 4.6: Medizinischer Service Point MSP
Sei ps = (L, G, K, O, pid) ein PS nach [Def. 4.5] und sk eine SK, die zusammengehörig sind.
Dann ist ein MSP eine Erweiterung der ENLO und definiert als MSP = (Bez, D, V, M, N, A):
•
Bez, D, V, M, N entsprechen der Definition einer ENLO nach [Def. 4.6b].
•
Sei di ∈ D mit 1 ≤ i ≤ n die geplante Dienstleistung, die beim Patienten durchgeführt
werden soll.
•
Sei K = (kb, kd) die Bezeichnung einer Dienstleistung mit Datum nach [Def. 4.6b].
•
Die Bezeichnung kb des aktuellen Status K von ps wird auf den Wert b(di) gesetzt,
sobald der Patient den MSP erreicht, wobei b(di) die Bezeichnung der aktuellen
Dienstleistung nach [Def. 4.6a] ist. Weiterhin wird das Datum kd auf das aktuelle
Datum und die Uhrzeit gesetzt. Es wird also folgendes ausgeführt:
kb := Bez
kd := Datum und Uhrzeit zu der der Patient die MSP erreicht.
•
Die aktuelle Untersuchung wird, sobald der Patient den MSP erreicht, aus der Liste
der geplanten Untersuchungen für diesen Patienten entfernt:
G := G \ { gj = (gbj, gdj) ∈ G | gbj = Bez }.
•
A = {a1, ..., am} mit m ∈ IN0 ist eine Menge von Aktivatoren, die Hintergrundprozesse
auslösen können. Jeder Aktivator ist dabei mindestens einer Aktion in einer der drei
Phasen von D zugeordnet. Er wird ausgelöst, sobald die Aktion, der er zugeordnet
ist durchgeführt wird. Dies kann z. B. das Versenden einer entnommen Blutprobe an
das Labor sein. Dies löst im Labor den Auftrag zur Analyse der Blutprobe und
Übermittlung eines Befundes aus.
•
Am Ende der Dienstleistung wird die durchgeführte Dienstleistung als letzter Eintrag
der Liste der durchgeführten Leistungen L hinzugefügt:
L := L ∪ {K}.
•
Die Bezeichnung kb des aktuellen Status K von ps wird auf den Wert b(di) + "wurde
durchgeführt" gesetzt, sobald die Dienstleistung abgeschlossen ist. Weiterhin wird
das Datum kd auf das aktuelle Datum und die Uhrzeit gesetzt, welches jetzt dem
Endedatum der Dienstleistung entspricht. Es wird also folgendes ausgeführt:
kb := b(di) + " wurde durchgeführt"
kd := Datum und Uhrzeit, zu der die Dienstleistung beendet wurde.
132
Serviceflows zur Modellierung klinischer Behandlungsketten
Anmerkungen zu Definition 4.6:
•
Die Aktivatoren werden als Wenn-Dann-Bedingungen realisiert. Dies hat den Vorteil,
dass sie zunächst einmal unabhängig von einem Workflow-Modell definiert werden
können und erst dann der Aktion, die innerhalb des Workflows den Wenn-Teil
erfüllen kann, zugeordnet werden. So können z. B. auch "elegant"
Notfallmaßnahmen modelliert werden, ohne dass das Workflow-Diagramm mit
unnötigen Verzweigungen verkompliziert werden muss. Ein konkretes Beispiel dazu
folgt in Abschnitt 4.10.
•
Die in der Definition genannten Bedingungen für die Modifikation von ps werden
chronologisch ausgeführt. Der Ablauf ist also "Setzen von K", "Durchführung der
Vorbereitung",
"Durchführung
der
Untersuchung",
"Durchführung
der
Nachbereitung", "Setzen von G", "Setzen von L", "Setzen von K".
4.7 Der MSP im klinischen Kontext
Mit dem Medizinischen Servicepoint (MSP) steht ein allgemeines Modell für die Abbildung
der medizinischen leistungserbringenden Unterabteilungen zur Verfügung. Es muss jedoch
noch festgelegt werden, wie sich dieser in den klinischen Behandlungsablauf einbetten lässt.
Da der MSP auf der erweiterten normalisierten leistungserbringenden Organisationseinheit
(ENLO) basiert, gelten für die Zuführung von Patienten zunächst einmal dieselben
Bedingungen, insbesondere die Abhängigkeit dieser Entscheidung vom verantwortlichen
Chef- oder Oberarzt. Dieser kann aber durch Abruf des PS jederzeit einen Überblick über
den aktuellen Behandlungsablauf bekommen.
Weiterhin ist es aus Sicht des MSP möglich ein geplantes Tagesprogramm zu erstellen.
Dazu kann die Menge GPT (Geplante Patienten eines Tages) der Patienten, die an einem
Tag T für einen MSP, der die Leistungen L erbringen kann, wie folgt ermittelt werden:
Sei PS = {ps1, ..., psn} mit n ∈ IN die Menge aller Patientenstati der Patienten und D ⊆ DA
die Menge der Dienstleistungen, die der gewünschte MSP erbringen kann.
Dann ist GPT = {pidi | gbi, ∈ D und Tag(gdi) = T mit gi = (gbi gdi) mit 1 ≤ i ≤ n}.
So kann für jeden MSP mit Hilfe von GPT geplant werden, welcher Patient behandelt wird.
Da in gdi weiterhin eine Uhrzeit abgelegt werden kann, kann für jeden MSP sogar eine
Reihenfolge festgelegt werden, in der die Patienten behandelt werden sollen. Da die
Behandlungszeiten der medizinischen Dienstleistungen stark variieren, kann der Termin
nicht als exakt betrachtet werden, als ungefährer Richtwert kann er jedoch verwendet
werden.
133
Serviceflows zur Modellierung klinischer Behandlungsketten
Es ist aber möglich festzustellen, welcher MSP voraussichtlich wie ausgelastet ist, und es
können kurzfristige Dispositionen zu einer gleichmäßigen Auslastung von Unterabteilungen
durchgeführt werden. Zusätzlich kann diese Information durch das Personal auf den
Stationen genutzt werden, welches so abschätzen kann, wann welcher Patient für welchen
Eingriff vorbereitet werden muss und wann welcher Patient aus einer MSP voraussichtlich
auf die Station zurück verlegt wird.
Es fehlt jedoch noch ein Verfahren, mit dem der Verlauf des Aufenthalts innerhalb einer
medizinischen Institution simuliert werden kann. In Abb. 4.14 ist ein typischer Verlauf eines
Aufenthalts eines Patienten abgebildet.
Aufnahme
NormalStation
EKG
NormalStation
Labor
Zeit
Ultraschall
NormalStation
HK
Diag. +
PTCA
NormalStation
Verlegung auf Grund ärztlicher Entscheidung
Entlassung
Aktivator: aktiviert Hintergrundprozeß
Abb. 4.14: Typischer Verlauf eines Patientenaufenthaltes modelliert als Aufenthalte innerhalb
unterschiedlicher MSPs
Der abgebildete Verlauf dauert ungefähr drei Tage. Am ersten Tag werden die
Voruntersuchungen durchgeführt, die bei erfolgreichem Abschluss die Herzkatheter134
Serviceflows zur Modellierung klinischer Behandlungsketten
untersuchung ermöglichen. Etwaige dort diagnostizierte Stenosen werden direkt mittels
einer Dilatation (PTCA) behandelt. Danach wird der Patient noch eine Nacht stationär
überwacht und bei komplikationslosem Verlauf am nächsten Tag entlassen.
Zu beachten ist, dass ständig SK und PS modifiziert werden. Insbesondere beim Wechsel
zwischen den MSPs wird der Status angepasst und am Ende jedes Eingriffs die
Krankenakte aktualisiert. Nur dadurch ist der zuständige Facharzt in der Lage zu
entscheiden, ob und wann eine Maßnahme durchgeführt werden kann.
Dieser Ablauf innerhalb der Klinik soll noch formal definiert werden. Dazu müssen zunächst
die speziellen Service Points, die für Aufnahme und Entlassung zuständig sind, betrachtet
werden.
Bei der Aufnahme muss dafür gesorgt werden, dass SK und PS initialisiert werden. PS kann
immer neu angelegt werden, SK hingegen ist unabhängig von der Tatsache, ob der Patient
im Krankenhaus ist oder nicht. Es soll sogar dafür gesorgt werden, dass, wenn schon eine
SK für einen Patienten existiert, diese fortgeführt wird. Der Aufnahmepunkt wird somit
definiert als:
Definition 4.7a: Aufnahmepunkt AP
Sei pid die Identifikationsnummer eines neu aufzunehmenden Patienten, für den am Datum
dat die medizinische Leistung med geplant ist. Dann ist ein AP ein MSP mit folgenden
zusätzlichen Bedingungen:
•
Innerhalb des Service Flow wird ein AP als erstes aufgesucht und darf danach vor
einer Entlassung (siehe weiter unten Entlassungspunkt) nicht wieder aufgesucht
werden.
•
Ein AP führt keine medizinischen Dienstleistungen durch, sondern nur administrative
Aufgaben.
•
Sobald der Patient den AP erreicht, wird ein neuer PS ps mit der folgenden initialen
Belegung angelegt:
ps = (Ø, (med, dat), ("Aufgenommen", aktuelles Datum), Ø, pid)
•
Existiert für die pid noch keine SK,
Patientenstammdaten eine solche angelegt.
•
In der SK wird ein neuer anamnestischer Eintrag für den aktuellen Aufenthalt in der
medizinischen Institution angelegt. An diesen werden alle innerhalb des Aufenthaltes
durchgeführten, medizinischen Leistungen von den durchlaufenen MSPs angehängt.
•
Der AP sollte einen Aktivator, der eine Nachricht über die Patientenaufnahme
auslöst, besitzen. Dies ist meistens eine ADT-Nachricht im HL7-Standard.
so
wird
unter
Verwendung
der
135
Serviceflows zur Modellierung klinischer Behandlungsketten
Anmerkungen zu Definition 4.7a:
In der Praxis wird diese Definition aus folgenden Gründen relaxiert:
•
Wird nur durch ein AIS das Serviceflow-Modell unterstützt und die Aufnahme von
einem Modul des KIS durchgeführt, so versendet dieses nach erfolgter
Patientenaufnahme eine Nachricht an alle AISe. Dies geschieht in der Regel als
ADT-Nachricht im HL7-Standard. Diese Nachricht wird von einem Serverprozess des
AIS verarbeitet, welcher dafür sorgt, dass alle Einträge angelegt werden. In diesem
Fall ist der AP also ein Programm und kein Ort, den der Patienten aufsucht. Es wird
auch kein Aktivator benötigt, der eine Aufnahmenachricht versendet.
•
Verfügt die Klinik über ein Terminplanungssystem, so kann dieses dem AP bei der
Aufnahme die geplante medizinische Leistung med und das Datum dat über eine
Schnittstelle (z. B. HL7) übermitteln. Ist dieses bei der Aufnahme nicht bekannt, so
dürfen Dummy-Tupel der Art ("Kardiologische Diagnostik", "Aktuelles Datum")
verwendet werden. Dies ist immer möglich, da das aktuelle Datum bekannt ist und
ebenso eine Abteilung, in der der Patient zunächst aufgenommen wird. Diese kann
sich zwar später ändern, wenn andere Diagnosen oder Symptome dies verlangen.
Das wiederum ist bei der Aufnahme zunächst gleichgültig und vernachlässigbar.
•
Außerhalb der normalen Dienstzeiten, wenn die Patientenaufnahme nicht besetzt ist,
muss auch eine Aufnahme von Notfällen möglich sein. Dies geschieht durch die
Notfallaufnahme, welche in diesem Fall ist der AP ist.
Bei der Entlassung muss dafür gesorgt werden, dass der aktuelle Aufenthalt der SK
geschlossen wird und alle für die Entlassung notwendigen administrativen Tätigkeiten
durchgeführt werden. Weiterhin muss der PS geschlossen werden. Der Entlassungspunkt
wird somit definiert als:
Definition 4.7b: Entlassungspunkt EP
Seien ps = (L, G, K, O, pid) der PS und sk, eine SK, die zusammengehörig sind und zu einem
zu entlassenden Patienten gehören, der zum Datum dat entlassen wird. Dann ist ein EP ein
MSP mit folgenden zusätzlichen Bedingungen:
•
Ein EP ist immer eine Station und nie eine dienstleistende Abteilung. Die Entlassung
wird stets durch den verantwortlichen Stationsarzt, ggf. auf Anordnung seines
vorgesetzten Chef- oder Oberarzt, veranlasst. Dies ist auch der Fall, wenn die
Entlassung auf Wunsch des Patienten gegen ärztlichen Rat geschieht.
•
Innerhalb des Serviceflow wird die Entlassung durch den EP nur zum Abschluss
durchgeführt. Danach wird innerhalb der Institution kein MSP mehr durch den
Patienten aufgesucht.
136
Serviceflows zur Modellierung klinischer Behandlungsketten
•
Nach der Entlassung werden im PS alle geplanten Leistungen gelöscht und die
aktuelle Leistung auf "Entlassen" gesetzt:
ps = (L, Ø, ("Entlassen", dat), O, pid).
•
In der sk wird der aktuelle Aufenthalt abgeschlossen, also mindestens Endzeitpunkt
des Aufenthaltes, Entlassungsgrund und Zustand des Patienten bei Entlassung
festgehalten.
•
Der EP besitzt einen Aktivator, der eine Nachricht über die Patientenentlassung
auslöst. Dies ist meistens eine ADT-Nachricht im HL7-Standard.
•
Es existieren Aktivatoren, die das Versenden aller noch nicht übermittelten
administrativen Daten an die Abrechnungsstelle aktivieren. Zusätzlich müssen noch
Hintergrundprozesse zum Abarbeiten von abschließenden Tätigkeiten wie z. B. das
Schreiben des Arztbriefes aktiviert werden.
•
Es existieren Aktivatoren, die, falls der Patient verstorben ist, die notwendigen
administrativen Prozesse, wie z. B. Ausfüllen des Totenscheins, anstoßen.
Anmerkungen zu Definition 4.7b:
Die Entlassung kann auch ohne Anwesenheit des Patienten erfolgen:
•
Sollte der Patient in einer dienstleistenden Unterabteilung, z. B. während eines
Eingriffes versterben, so wird die Entlassung trotzdem von der Station veranlasst, auf
der der Patient zuletzt lag.
•
Bei einer Notfallverlegung in eine andere Institution wird dies ebenfalls von der
Station veranlasst, auf der der Patient zuletzt lag.
Dies liegt in beiden Fällen daran, dass bei der Verlegung die notwendigen Papiere in Form
von Überweisung, Verlegungsbericht, Krankenakte etc. und persönliche Gegenstände und
Kleidungsstücke des Patienten an die richtigen Stellen weitergeleitet werden müssen. Dies
wird immer auf der Station vorgehalten und nicht zu einer medizinischen Behandlung
mitgenommen.
Der tatsächliche Serviceflow zwischen den Start- und Endpunkten steht erst am Ende des
Aufenthalts fest. Es existiert bei diesem Ansatz kein fest vorgegebener Pfad für die
medizinische Leistung. Dies ist aber gerade so gewollt, da es eben keinen standardisierten
"Idealweg" gibt, nach dem eine Behandlung mit Erfolgsgarantie durchführbar ist. Vielmehr ist
die Möglichkeit einer dynamischen Anpassung des Behandlungsablaufs an Änderungen des
Krankheitsbildes notwendig. Die Entscheidung der Behandlungsfortführung liegt also einzig
bei den verantwortlichen Ärzten und ist nicht durch vorgeschriebene Arbeitsabläufe
festgelegt.
137
Serviceflows zur Modellierung klinischer Behandlungsketten
Der medizinische Serviceflow wird folgendermaßen definiert:
Definition 4.7: MSF (Medizinischer Serviceflow)
Ein MSF = ((MSP0, t0), (MSP1, t1), ..., (MSPn, tn), pid) ist eine chronologisch sortiere Liste von
Tupeln, die jeweils aus einem MSP und einem Zeitpunkt bestehen, und eine pid, welche
eindeutig einen Patientendatensatz identifiziert. Die MSPs repräsentieren die im Rahmen
einer Behandlung von einem Patienten in Anspruch genommenen Fachabteilungen. Es gilt:
•
Die Liste ist zeitlich aufsteigend, also
ti < tj für 0 ≤ i < j ≤ n
•
MSP0 ist immer ein AP.
•
Ist der Patient entlassen, so ist MSPn immer ein EP, ist der Patient noch nicht
entlassen, so darf MSPn kein EP sein.
•
MSP1 bis MSPn-1 sind weder AP noch EP.
•
Zu pid gibt es genau einen Datensatz, der diesen Patienten in PD (vgl. [Def. 4.4])
abbildet.
Anmerkung zu Definition 4.7:
•
Gleiche MSPs dürfen in einem MSF auch mehrfach von einem Patienten aufgesucht
werden.
•
Der Serviceflow kann für einen Patienten durch ps abgebildet werden. Er entspricht
gerade der Menge L der im Rahmen des Aufenthaltes bereits durchgeführten
Leistungen.
•
Die Fortführung des MSFs ist einzig von der Entscheidung der verantwortlichen
Ärzte abhängig, welche neben ihrem Domänenwissen, Konsilen, Leitlinien der
Fachgesellschaften und dem aktuellen Erscheinungsbild des Patienten (vgl.
Abschnitt 4.5) auch die Informationen des PS und der SK bei der
Entscheidungsfindung nutzen. Es kann somit keine formale Vorschrift für die Findung
des nächsten MSPn+1 für einen MSF erstellt werden.
Das Serviceflow-Konzept ist bzgl. seiner Erweiterbarkeit bei strukturellen Änderungen in
einer klinischen Abteilung sehr flexibel. Wird eine neue Behandlungsmethode Bx etabliert, so
wird diese einem MSP, der sie durchführen kann, zugeordnet. Die Vorbedingungen des
MSP werden um die Indikationen für die neue Behandlung erweitert und ggf. noch
Aktivatoren, die die neue Behandlungsmethode auslösen können, festgelegt. Schließlich
wird ein neues Dokumentationsschema Lbx definiert und in das vorhandene Datenschema
138
Serviceflows zur Modellierung klinischer Behandlungsketten
integriert. Dieses muss dem Workflow der Behandlung angepasst sein und sämtliche
relevante Daten, insbesondere gesetzlich vorgeschriebene, aufnehmen können.
Auf ähnliche Weise wird eine zusätzliche leistungserbringende Abteilung in einen
existierenden MSF integriert. Der neuen Abteilung, die in Form eines MSPs modelliert ist,
wird zunächst ein neuer, eindeutiger Name zugewiesen. Danach werden alle medizinischen
Leistungen, die diese Abteilung erbringen kann, als neue Behandlungsmethoden nach
obigem Vorgehen hinzugefügt. Es wird somit bei Erweiterungen der klinischen Struktur
durch neue Ateilungen nur etwas hinzugefügt und es muss nicht das gesamte bestehende
Modell angepasst werden.
Wird eine Behandlungsmethode By nicht mehr angeboten, so wird diese aus der Menge D
der durchführbaren Leistungen der MSPs entfernt. Zusätzlich werden aus der Menge V der
Vorbedingung (Indikationen), alle die Einträge gelöscht, die nur für By eine Vorbedingung
sind. Es kann auch ein kompletter MSP entfernt werden, wenn z. B. eine Abteilung
geschlossen wird. Dann werden alle seine Behandlungsmethoden entfernt und schließlich
der MSP.
Behandlungen, die nicht durch einen MSP in der eigenen Institution durchgeführt werden
können, führen stets zu einer Überweisung des Patienten in eine medizinische Institution,
die die Behandlung anbietet.
Ebenso beeinflussen Änderungen bei der Durchführung von Behandlungsmethoden
zunächst nur die Abläufe in den MSPs. Auswirkungen entstehen nur indirekt durch neue
Nachbedingungen, die die Modellerweiterungen oder –modifikationen nach sich ziehen. Da
hierauf aber dynamisch während des Behandlungsablaufs durch die übrigen MSPs reagiert
wird und nicht in einem statischen, vorgeschriebenen Ablauf, werden Seiteneffekte und
größere Änderungen des gesamten Modells vermieden.
Hier besteht eine große Ähnlichkeiten zum Konzept der Kapselung aus der
objektorientierten Programmierung. Bei diesem Konzept werden Implementierungsdetails
verborgen. Der Zugriff auf das Objekt erfolgt nur über seine Schnittstelle. Damit soll
vermieden werden, dass Änderungen an der internen Implementierung zu Änderungen
anderer Programmteile führen.
Genauso kapselt der MSP Details bzgl. der durchgeführten Maßnahme innerhalb eines
MSPs. Nur die Tatsache, dass die medizinische Maßnahme mit einer gewissen Zielsetzung,
die durch die Indikation (Vorbedingung) vorgegeben ist, durchgeführt wird und der Patient
mit einem Ergebnis der Behandlung den MSP wieder verlässt, ist für die gesamte
Behandlungskette von Interesse.
139
Serviceflows zur Modellierung klinischer Behandlungsketten
4.8 Der Standardisierte Medizinische Serviceflow
Zwar kann der Verlauf der Behandlung nicht vorhergesehen werden und somit existiert kein
standardisierter Plan, nach dem der Patient die einzelnen MSPs durchläuft, es ist aber
möglich Standards festzulegen. Dies erfolgt unter der Annahme, dass es sich um eine
komplikationslose Behandlung mit eindeutiger Diagnose und keinen erschwerenden
Nebenbefunden handelt.
Dies kann in der Kardiologie insbesondere bei der Behandlung der KHK Anwendung finden.
Hier sieht der normale Behandlungsablauf so aus:
•
Einweisung des Patienten durch einen niedergelassenen Arzt mit der Einweisungsdiagnose "KHK" oder "V. a. KHK", abhängig von den Untersuchungsergebnissen
•
Stationäre Aufnahme des Patienten inkl. Blutentnahme für Laboruntersuchung
•
Erstellen eines EKG
•
Ultraschalluntersuchung
•
Herzkatheteruntersuchung mit Dilatation und Stentimplantation
•
Entlassung des Patienten.
Der gesamte Aufenthalt dauert in der aktuellen klinischen Praxis drei Tage, wobei der
Haupteingriff des Herzkatheters am zweiten Tag stattfindet. Am ersten Tag erfolgen die
notwendigen Voruntersuchungen und die Aufklärung des Patienten, am zweiten Tag wird
die Behandlung im HK-Labor durchgeführt und der letzte Tag dient zur Überwachung des
Patienten. Der zugehörige Serviceflow sieht dann z. B. so wie in Abb. 4.15 dargestellt aus.
Erwartungsgemäß entspricht dies dem Beispiel aus Abb. 4.14, da in beiden Fällen von
einem identischen klinischen Verlauf und Krankheitsbild ausgegangen wird.
Labor
Patientenaufnahme
Station
EKG
Station
Ultraschall
Station
Herzkatheter
Station
Entlassung
Abb. 4.15: Reihenfolge der besuchten MSPs bei einem typischen Behandlungsverlauf eines
Patienten mit KHK. Das Labor wird als Hintergrundprozess aktiviert, die Entlassung erfolgt
durch die Station, der letzte Schritt ist also keine Verlegung in eine neue MSP.
140
Serviceflows zur Modellierung klinischer Behandlungsketten
In der Praxis ist es sinnvoll, standardisierte MSFs zur Verfügung zu haben. Diese finden in
erster Linie bei der Belegungsplanung Anwendung. Das leitende Personal kann abschätzen,
wie lange Patienten voraussichtlich stationär betreut werden und welche Untersuchungen
für welchen Patienten wann durchgeführt werden sollten. Die Definition standardisierter MSF
erfolgt analog zur Definition des MSF und sieht folgendermaßen aus:
Definition 4.8: SMSF (Standardisierter Medizinischer Serviceflow)
Ein SMSF = ((MSP0, z0), (MSP1, z1), ..., (MSPn, zn)) ist eine chronologisch geordnete Liste von
Tupeln, bestehend aus einem MSP und einer optionalen Zeitspanne, für die gilt:
•
MSP0 ist immer ein AP.
•
MSPn ist immer ein EP.
•
MSP1 bis MSPn-1 sind weder AP noch EP.
Anmerkung zu Definition 4.8:
•
Im Gegensatz zu [Def. 4.7] ist diese Definition unabhängig von einem speziellen
Patienten.
•
Es dürfen auch hier gleiche MSPs mehrfach aufgesucht werden.
•
Die Zeitspannen repräsentieren die Dauer, die der Patient in der MSP verbringt.
Diese kann auch leer sein, womit es möglich ist, einfach nur den Behandlungsablauf
abzubilden, ohne konkrete Zeitpläne festzulegen. Dies ist sinnvoll, da meist geplant
werden kann, an welchem Tag eine Untersuchung stattfindet, aber nicht genau
wann.
•
Die Reihenfolge in der Menge ist entscheidend, da nur so ein Ablauf dargestellt
werden kann.
•
Hintergrundprozesse und deren Aktivatoren wurden hier nicht betrachtet. Bei einem
standardisierten Behandlungsablauf wird immer davon ausgegangen, dass im
Hintergrund durchgeführte Untersuchungen, wie z. B. Erstellung eines Blutbildes
durch das Labor, immer zu einem positiven Ergebnis im Sinne der Durchführbarkeit
der medizinischen Leistung in der Behandlungskette führen.
Für eine konkrete Implementierung bietet sich eine weitere Formalisierung an. In diesem
Fall kann hierfür ein endlicher Automat verwendet werden, dessen Aufbau im folgenden
Abschnitt vorgestellt wird.
141
Serviceflows zur Modellierung klinischer Behandlungsketten
4.9 Darstellung des MSF als endlicher Automat
Der MSF kann als endlicher Automat mit Ausgabe modelliert werden. Hierfür wird folgende
Vorgehensweise verwendet:
•
Die einzelnen Zustände des Automaten repräsentieren die MSPs, die ein Patient
innerhalb der Behandlungskette durchlaufen kann.
•
Der aktuelle Zustand des Automaten wird durch die aktuelle Belegung von PS
repräsentiert.
•
Der Startzustand des Automaten repräsentiert immer einen AP.
•
Ein Zustandswechsel erfolgt, wenn der Patient von einem MSP zum Nächsten
wechselt.
•
Bei jedem Zustandswechsel wird die erbrachte Leistung, also gerade die Eingabe,
wieder ausgegeben. Der Zustand kann mit ausgegeben werden, da von der
erbrachten Leistung eindeutig auf den verlassenen MSP geschlossen werden kann,
weil spezielle Leistungen nur von dazu befähigten MSPs ausgeführt werden können.
•
Der Automat bleibt so lange in seinem Zustand wie der Patient durch den MSP
behandelt wird. Dann werden die Prozesse innerhalb des MSP durchgeführt, also die
Phasen Vorbereitung, Durchführung und Nachbereitung abgearbeitet und im
Rahmen der Dokumentationspflicht die Krankenakte erweitert. In dieser Zeit ändert
sich der Zustand des Automaten also nicht.
•
Jederzeit ist es möglich, z. B. auf Grund von Komplikationen oder
Notfallmaßnahmen, den Zustand des Automaten zu verändern. Dies entspricht der
Verlegung des Patienten in einen anderen MSP, resultierend aus einer
unvorhergesehenen Komplikation oder Notfallmaßnahme.
•
Jeder EP ist ein Endzustand.
•
Die gesamte Ausgabe des Automaten entspricht der vom Patienten durchlaufenen
Behandlungskette, also dem abgearbeiteten MSF.
Da es nur eine begrenzte Anzahl an MSPs, die gerade den Zuständen entsprechen,
innerhalb einer Klinik gibt, ist die Anzahl der Zustände des Automaten endlich. Konkret kann
der endliche Automat mit Ausgabe als Mealy-Automat (vgl. [HUM02]) modelliert werden.
Dieser Variante eines DEA (deterministischen endlichen Automaten) wurde gegenüber
einem NDEA (nicht deterministischen endlichen Automaten) oder einem Moore-Automaten
der Vorzug gegeben, da bei einem Mealy-Automaten der Zustandsübergang von der
Eingabe, welche in diesem Fall die vom Arzt gestellte Indikation ist, abhängig ist. Dies hebt
die Tatsache, dass die ärztliche Entscheidung den Behandlungsablauf bestimmt, hervor.
142
Serviceflows zur Modellierung klinischer Behandlungsketten
Sei A = (X, Y, Z, δ, λ, z0, E) ein endlicher Automat mit:
•
X, das Eingabealphabet, ist eine nicht leere, endliche Menge von Eingabezeichen
•
Y, das Ausgabealphabet, ist eine nicht leere, endliche Menge von Ausgabezeichen
•
Z, die Zustandsmenge, ist eine nicht leere, endliche Menge
•
δ: X × Z → Z ist die Überführungsfunktion, welche Paaren (Eingabezeichen, Zustand)
einen Folgezustand zuordnet
•
λ: X × Z → Y* ist die Ausgabefunktion, welche Paaren (Eingabezeichen, Zustand) ein
Ausgabewort (endliche Folge von Ausgabezeichen) zuordnet
•
z0 ∈ Z ist der Anfangszustand
•
E ⊆ Z, die Endzustände, ist eine nicht leere, endliche Teilmenge von Z.
Hier wird der Automat jedoch nicht total definiert, da die Funktionen δ und λ als partielle
Überführungsfunktionen realisiert sind. Es werden nur Übergänge zugelassen, die
medizinisch sinnvoll sind. Zur Abbildung des MSF wird folgendermaßen vorgegangen:
•
X ist die Menge der Vorbedingungen, die zu einer Behandlung in einem MSP führen.
•
Y enthält die Namen aller Behandlungen.
•
Z ist die Menge aller Behandlungen, die die MSPs, die ein Patient innerhalb der
Behandlungskette in der modellierten klinischen Institution aufsuchen kann,
erbringen können. Dies beinhaltet auch alle APe und EPe, also insbesondere die
Patientenaufnahme. Z entspricht somit der Menge D aus [Def. 4.5].
•
δ: X × Z → Z ist die Überführungsfunktion, welche jedem Paar (Eingabezeichen,
Zustand) einen Folgezustand zuordnet. Es werden dabei nur medizinisch sinnvolle
Übergänge zugelassen. Die Eingabe (Indikation), muss also zu einem Folgezustand
führen, der einem MSP entspricht, welcher eine zur Indikation passende Behandlung
durchführen kann. Alle übrigen Übergänge sind nicht erlaubt, weswegen der Automat
nur partiell definiert ist10. Somit ist δ einzig von X und nicht auch von Z abhängig.
•
λ ist abhängig von der Eingabe (Behandlung), da ein MSP unterschiedliche Behandlungen durchführen kann, und gibt nach Verlassen eines Zustandes den aktuellen
Zustand, also den Namen der Abteilung und die durchgeführte Behandlung aus.
Dadurch wird die Liste der durchgeführten Untersuchungen ständig aktualisiert.
•
z0 ∈ Z ist ein ausgewählter AP, in der Regel die Patientenaufnahme.
•
E ⊆ Z sind die EP.
10
Der Mealy-Automaten kann leicht total gemacht werden, indem man einen zusätzlichen
Fehlerzustand hinzunimmt, zu dem alle nicht-definierten Übergänge führen (vgl. z. B. [HUM02]).
143
Serviceflows zur Modellierung klinischer Behandlungsketten
Für die Modellierung des MSF gibt es noch die grundsätzliche Einschränkung, dass bei
Erreichen der Endzustände, die gerade die EPe darstellen, keine weitere Behandlung durch
die modellierte klinische Abteilung erfolgt. Es gilt also:
Sei xi ∈ X die Indikation, die zur Behandlung durch zj ∈ Z \ {z0} führt. Dann gilt:
∀ zn ∈ Z \ E: δ(xi, zn) = zj.
Weiterhin muss es möglich sein, dass auf Grund einer ärztlichen Entscheidung jederzeit
jeder MSP aufgesucht werden kann. Es muss also möglich sein, von jedem Zustand zu
jedem zu gelangen. Dies gilt nicht für den AP, welcher nicht wieder aufgesucht werden darf,
da ein bereits aufgenommener Patient nicht innerhalb einer Behandlungskette ein zweites
Mal aufgenommen werden darf. Abschließend sei noch angemerkt, dass ein direkter
Übergang von einem AP zu einem EP denkbar ist, aber normalerweise nicht vorkommt, da
der Patient dann ohne irgendeine medizinische Behandlung direkt wieder entlassen wird.
Als Beispiel soll eine einfache kardiologische Abteilung bestehend aus den MSPs
•
PA (Patientenaufnahme),
•
St (Station),
•
US (Ultraschalllabor),
•
HK (HK-Labor) und
•
El (Entlassung)
modelliert werden. Hinter den MSPs ist in Klammern jeweils eine Abkürzung für die weitere
Verwendung der Namen im Rahmen der Automatenmodellierung angegeben. Die
Entlassung ist in der Realität ein Teil der Station, muss hier aber extra hervorgehoben
werden, da sonst nie ein Endzustand erreicht wird. In der Praxis könnte dies z. B. ein
Stationszimmer sein, in dem der Patient seine Entlassungsunterlagen erhält und ein
abschließendes Beratungsgespräch mit ihm geführt wird.
Für die Behandlung durch die MSPs wurden für dieses Beispiel folgende Indikationen, die in
Kapitel 3 vorgestellt wurden, ausgewählt:
•
Station: "stationäre Überwachung (St 1)"
•
Ultraschalllabor: "V. a. Klappenerkrankung (US 1)", "Ultraschall auf Grund sonstiger
Indikation (US 2)"
•
HK-Labor: "V. a. KHK (HK 1)", "geplante Dilatation (HK 2)", " HK auf Grund sonstiger
Indikation (HK 3)"
•
Entlassung: "Patient gesund (El 1)", "Patient wünscht Entlassung gegen ärztlichen
Rat (El 2)", "Patient verstorben (El 3)".
Auch hier wurden Abkürzungen in Klammern hinter den Indikationen eingeführt, unter denen
diese im Weiteren verwendet werden. In der Praxis existieren viel mehr Indikationen (vgl.
144
Serviceflows zur Modellierung klinischer Behandlungsketten
Kapitel 3), damit das Beispiel übersichtlich bleibt, wurde die Einschränkung auf die oben
aufgeführten Indikationen durchgeführt.
Der Mealy-Automat A = (X, Y, Z, δ, λ, z0, E) hierzu kann folgendermaßen definiert werden:
•
X = {"St 1", "US 1", "US 2", "HK 1", "HK 2", "HK 3", "El 1", "El 2", "El 3"}
•
Y = {"Aufnahme", "Stationärer Aufenthalt", "Ultraschall", "Diagn. HK", "Therapeut.
HK", "HK", "Gesund", "Gg. Rat entl.", "Tot"}
•
Z = {"PA", "St", "US", "HK", "El"}
•
δ: siehe Tab. 4.5
•
λ: siehe Tab. 4.6
•
z0 = "PA"
•
E = {"El"}.
Aktueller Zustand
Eingabe
PA
St
US
HK
El
St 1
St
St
St
St
--
US 1
US
US
US
US
--
US 2
US
US
US
US
--
HK 1
HK
HK
HK
HK
--
HK 2
HK
HK
HK
HK
--
HK 3
HK
HK
HK
HK
--
El 1
--
El
El
El
--
El 2
--
El
El
El
--
El 3
--
El
El
El
--
Tab. 4.5:
Überführungsfunktion δ: Der jeweils neue Zustand ist angegeben, wenn sich der Automat
im "Aktuellen Zustand" befindet und die "Eingabe" eingegeben wird. "--" bedeutet, dass
diese Kombination nicht gestattet, die Übergangsfunktion somit nicht definiert ist.
In Abb. 4.16 ist der Automat für dieses Beispiel grafisch dargestellt. Die aus medizinischer
Sicht seltener vorkommenden Wechsel sind mit gestrichelten Linien eingezeichnet. So ist es
z. B. üblich, dass sich der Patient nach der Aufnahme zunächst zur Station begibt und nicht
direkt in den Ultraschall oder das HK-Labor. Da dies in dringlichen oder akuten Notfallsituationen auch vorkommen kann, dürfen diese Zustandswechsel nicht weggelassen werden.
Oberhalb der Pfeile, die den Zustandswechsel repräsentieren, steht jeweils die Eingabe, die
den Zustandswechsel auslöst, darunter in kursiver Schrift die resultierende Ausgabe. Gibt es
mehrere Eingaben, die ein und denselben Zustandswechsel auslösen, so stehen diese alle
oberhalb des Pfeils. Jeweils zentriert darunter steht die aus der Eingabe resultierende
Ausgabe. Diese Darstellung wurde gewählt, damit die Grafik übersichtlich bleibt.
145
Serviceflows zur Modellierung klinischer Behandlungsketten
Zustand
Eingabe
PA
St
US
HK
St 1
Stationärer
Aufenthalt
Stationärer
Aufenthalt
Stationärer
Aufenthalt
Stationärer
Aufenthalt
US 1
Ultraschall
Ultraschall
Ultraschall
Ultraschall
US 2
Ultraschall
Ultraschall
Ultraschall
Ultraschall
HK 1
Diagnost. HK
Diagnost. HK
Diagnost. HK
Diagnost. HK
HK 2
Therap. HK
Therap. HK
Therap. HK
Therap. HK
HK 3
HK
HK
HK
HK
El 1
Gesund
Gesund
Gesund
Gesund
El 2
Gegen Rat entl.
Gegen Rat entl.
Gegen Rat entl.
Gegen Rat entl.
El 3
Tot
Tot
Tot
Tot
Tab. 4.6:
Ausgabefunktion λ: Ausgabewort, das bei einem Zustandswechsel, abhängig von der
Eingabe, ausgegeben wird. Dies ist einzig von der Eingabe abhängig. "--" bedeutet, dass
diese Kombination auf Grund der Definition von δ nicht auftreten kann.
Abb. 4.16: Grafische Darstellung des Beispiel-Automaten. Oberhalb der Pfeile stehen jeweils die
Eingaben, die die Zustandswechsel auslösen, darunter die zugehörige Ausgabe.
146
Serviceflows zur Modellierung klinischer Behandlungsketten
Das Beispiel des MSF aus der Einleitung von Kapitel 4 würde z. B. durch den vorgestellten
Automaten durch die Eingaben
Einweisung → St 1 → HK 2 → St 1 → El 1
realisiert. Diese führt den Patienten durch die MSPs PA, St, HK, St und El und es wird
dadurch die Ausgabe
"Aufnahme", "Stationärer Aufenthalt", "Therapeutische HK", "Stationärer Aufenthalt",
"Gesund"
erzeugt. Dies entspricht gerade den Angaben unter "Durchgeführt:" des PS.
Genau genommen müssen mehrere Startzustände erlaubt sein, da der Patient auch über
eine Ambulanz oder die Notfallaufnahme aufgenommen werden kann. Am grundsätzlichen
Modell ändert dies jedoch nichts. Zur Modellierung dieses Sachverhaltes kann entweder
eine Menge von Startzuständen zugelassen werden oder vor die tatsächlichen
Startzustände noch ein Startzustand gesetzt werden, der, abhängig von der Art der
Einweisung, z. B. "Notfall", "normale Aufnahme" oder "ambulante Zuweisung", auf den
tatsächlichen Startzustand verweist. Danach verhält sich der endliche Automat wieder wie
oben beschrieben. In Abb. 4.17 ist dieser Aufbau mit vorgeschaltetem Startzustand
abgebildet.
Abb. 4.17: Vorgeschalteter Startzustand zur Bestimmung des in der Klinik in Frage kommenden AP.
Somit können der PS und der MSF durch einen endlichen Automaten beschrieben werden.
Durch den hier vorgestellten Mealy-Automaten kann jedoch nicht die medizinische
Dokumentation modelliert werden. Diese findet innerhalb des MSPs statt und muss an die
dort durchgeführten Arbeitsprozesse angepasst werden. Der Automat kann zur Steuerung
des Ablaufs der Behandlungskette herangezogen werden. Mit seiner Hilfe wird entschieden,
wann wo welche Daten für wen verfügbar gemacht werden müssen. Diese Entscheidung
wird immer bei den Zustandswechseln getroffen. Hier muss den Mitarbeitern des MSPs, den
147
Serviceflows zur Modellierung klinischer Behandlungsketten
der Patient betritt (dies entspricht gerade dem Zustandswechsel des Automaten), die
Krankenakte des Patienten zugänglich gemacht werden. Zusätzlich müssen Werkzeuge zur
Verfügung gestellt werden, die, abhängig von der Indikation (welche gerade der Eingabe
des Automaten entspricht, die den Zustandswechsel ausgelöst hat), dem medizinischen
Personal eine adäquate Dokumentation erlaubt.
Die in Abschnitt 4.7 angesprochene einfache Erweiterbarkeit und Flexibilität des MSFKonzepts kann auch auf den vorgestellten Automaten übertragen werden. Eine neue
Behandlungsmethode hinzuzufügen ist trivial: Es wird lediglich die neue Indikation als
Eingabe und die dazu passende Ausgabe dem zugehörigen MSP hinzufügt. Es muss also
nur darauf geachtet werden, dass die Übergangsfunktion δ weiterhin nur "medizinisch
sinnvolle" Übergänge enthält.
Eine neue Abteilung, also ein neuer MSP, kann ebenfalls einfach hinzugefügt werden.
Zunächst wird ein neuer Zustand Zneu definiert, der den MSP repräsentiert. Von jedem
bereits existierenden Zustand, der kein EP ist, wird dann ein Übergang für jede Indikation
der Leistungen, die der MSP erbringen kann, zu Zneu hinzugefügt. Als Ausgabe werden die
zu den Eingaben gehörenden Leistungen gewählt.
Diese Ideen werden in Kapitel 5 bei der Vorstellung der Software-Architektur wieder
aufgegriffen. Es sei hier noch angemerkt, dass der Automat bei vielen MSPs, Diagnosen
und Leistung sehr schnell sehr groß und somit unübersichtlich werden kann. Eine grafische
Repräsentation empfiehlt sich dann nicht, eine tabellarische Darstellung ist jedoch gut
möglich. Diese kann so erfolgen, dass aufgelistet wird, welche MSPs es gibt und welche
diese unter welcher Indikation jeweils erbringen können. Zu jeder Leistung kann dann die
zugehörige Ausgabe festgehalten werden.
4.10 Beispiel für einen MSF
Im letzten Abschnitt dieses Kapitels soll als Beispiel die Behandlungskette für die invasive
Herzkatheteruntersuchung als MSF modelliert werden. Es wird dabei von der
Standardvorgehensweise ausgegangen, und es werden exemplarisch die wichtigsten
Notfallmaßnahmen modelliert.
Bei der primavista Dilatation handelt es sich in der invasiven Kardiologie unterdessen um
das Standardverfahren bei der Behandlung der KHK. Moderne Entwicklungen haben es in
den letzten Jahren ermöglicht, dass Diagnostik und Therapie in einer einzigen Sitzung
durchgeführt werden können (vgl. Abb. 4.18). Dies verringert die Belastung für den
Patienten um bis zu 50 % und spart Behandlungskosten.
148
Serviceflows zur Modellierung klinischer Behandlungsketten
3000
Diagnostik
Dilatation
Diagnostik + Dilatation
2500
Anzahl
2000
1500
1000
500
0
1997
1998
1999
2000
Jahr
2001
2002
2003
Abb. 4.18: Entwicklung der invasiven kardiologischen Eingriffe im Herzkatheterlabor der Klinikum
Oldenburg gGmbH in den Jahren 1997 bis 2003. Bei den therapeutischen Verfahren ist
ein deutlicher Trend weg von der Dilatation hin zur primavista PTCA (Diagnostik und
Dilatation in einer Sitzung) zu erkennen.
In diesem Beispiel soll die Behandlung eines Patienten mit Verdacht auf KHK in
fortgeschrittenem Stadium betrachtet werden. Die Einweisung erfolgt durch einen
niedergelassenen Facharzt für Kardiologie, der die vermutete Diagnose, die sich auf APBeschwerden abstützt, durch ein EKG, welches typische ST-Strecken-Veränderungen (vgl.
Kapitel 3) zeigt, abgesichert hat. Das Krankheitsbild erfordert eine dringliche Behandlung
des Patienten, die zu einer kurzfristigen Terminvergabe in der Klinik führt. Die Durchführung
diagnostischer Maßnahmen vor dem Herzkatheter ist also nicht mehr notwendig.
Der Aufenthalt gliedert sich somit in folgende Schritte:
1. Aufnahme
2. Stationärer Aufenthalt mit Blutentnahme
Blutparameter durch das Labor
zur
Bestimmung
aller
relevanten
3. Durchführung des Herzkatheters als primavista PTCA, also als Kombination aus
Diagnostik und Dilatation
4. stationäre Überwachung
5. Entlassung.
Es muss somit für zwei MSPs, die Station und das Herzkatheterlabor, Datenschemata
erstellt werden, welche zur medizinischen Dokumentation in diesen MSPs verwendet
149
Serviceflows zur Modellierung klinischer Behandlungsketten
werden können. Die Patientenaufnahme wird hier nicht als AP abgebildet, sondern als
Serverprozess, der auf HL7-Nachrichten reagiert. Dies entspricht der Praxis, da hier das KIS
für die Patientenaufnahme sorgt und diese dem AIS per Schnittstelle mitteilt. Weiterhin
werden noch der SMS, die SK und der PS benötigt.
Die Funktionsweise der SK wird in diesem Beispiel anhand ausgewählter Einträge gezeigt.
Dieser Mechanismus kann dann auf weitere Felder, die in der Praxis für eine vollständige
Dokumentation notwendig sind, übertragen werden.
In der SK ist hier durch L1 das Datenschema der Station und durch L2 das der
leistungserbringenden Abteilung exemplarisch definiert:
SK = (P, A, L1, L2, C) mit
P = {Stammdaten}
A = {Aufenthalt}
L1 = {Station, StaProtokoll, StaMaterial, StaICD, StaOPS}
L2 = {HK, HKProtokoll, HKMaterial, HKStenose, HKDilatation, HKICD, HKOPS}
C = {ArztCode, IndikationCode, ICDCode, OPSCode}.
In Abb. 4.19 ist der Aufbau der SK als ER-Diagramm dargestellt. In Anhang C werden die
einzelnen Felder der Relationen mit ihren Merkmalen aufgeführt.
Der PS PS = (L, G, K, O, pid) ist vor der Aufnahme noch undefiniert. Erst beim
Aufnahmeprozess wird er initialisiert.
Sei GENP = {TGName, TGVorname, NGGeboren, TGStrasse, TGPLZ, TGOrt, TGTelefon, TGKrankenkasse} die Menge
aller Modifikationen für die Attribute außer den ID-Feldern des Patientendatenschemas P
dieses Beispiels. Analog existieren GENA für Aufenthalte, GENL1 für die Stationsdaten L1 und
GENL2 für die Herzkatheterdaten L2.
Die Station ST = {BezST, DST, VST, MST, NST, AST} ist dann nach [Def. 4.6] ein MSP mit
BezST = "Station 8"
150
DST =
{"Stationäre Betreuung kardiologischer Patienten auf Station 8",
"Aufnahmeuntersuchung", ...}
VST =
{"Verdacht auf KHK", "Angina Pectoris", "Z. n. HK", ...}
MST =
GENP ∪ GENA ∪ GENL1
NST =
{"Diagnostischer Herzkatheter", "Koronarangioplastie", "Herzkatheter in
Dilatationsbereitschaft", "Medikation mit ASS und Clopidogrel 75 mg",
"Kontrollen durch Facharzt", "Überweisung in Herzchirurgie", ...}
AST =
{(" Labor", "Kleines Blutbild", pid)}.
Serviceflows zur Modellierung klinischer Behandlungsketten
P
Stammdaten
PK
Aufenthalt
A
HKICD
PID
PK
ANR
Name
Vorname
Geboren
Strasse
PLZ
...
FK1
PID
Von
Bis
Eingriff
Ort
KISNR
Station
StaICD
PK,FK1
PK
DOKNR
ICDNR
PK
DOKNR
FK1
ANR
Start
Stopp
Station
Arzt
Indikation
Befund
...
StaOPS
PK,FK1
PK
DOKNR
OPSNR
StaProtokoll
PK,FK1
PK
DOKNR
Zeit
L1
StaMaterial
PK,FK1
PK
DOKNR
Material
Text
PK,FK1
PK
PK
PK,FK1
PK
DOKNR
Start
Stopp
Labor
Untersucher
EF
Indikation
Befund
Procedere
...
HKOPS
PK,FK1
PK
HKProtokoll
HK
DOKNR
ICDNR
DOKNR
OPSNR
DOKNR
Zeit
Text
HKMaterial
PK,FK1
PK
DOKNR
Material
HKDilatation
PK,FK1
PK
DOKNR
Gefäß
HKStenose
PK,FK1
PK
StenosePrä
StenosePost
Verfahren
ICDCode
PK
PK
ICDNR
Version
Stenosegrad L2
OPSCode
PK
PK
DOKNR
Gefäß
OPSNR
Version
IndikationCode
PK
Code
ArztCode
PK
Code
ICD
ICDText
OPSText
C
Abb. 4.19: ER-Diagramm zur SK des angeführten Beispiels. Die Fremdschlüssel-beziehungen sind
mit FK und die Primärattribute mit PK markiert. Die einzelnen Subschemata P, A, L1, L2, C
sind, soweit sie aus mehreren Relationen bestehen, durch Rahmen zusammengefasst.
Das HK-Labor HK = (BezHK, DHK, VHK, MHK, NHK, AHK) ist dann nach [Def. 4.6] ein MSP mit
BezHK = "HK-Labor 1"
DHK =
{"Diagnostischer Herzkatheter", "Koronarangioplastie", "Herzkatheter in
Dilatationsbereitschaft", "Angiografie", " Angioplastie"...}
VHK =
{"Verdacht auf KHK", "Ausschluss KHK", "Geplante PTCA", "Angina Pectoris",
"Z. n. HK", "Periphere AVK", "Geplante Angioplastie", ...}
MHK =
GENP ∪ GENA ∪ GENL2
NHK =
{"Stationäre Betreuung kardiologischer Patienten", "Druckverband 8 Std.",
"Konservativ", "Dilatation", "Bypassoperation", "Medikation mit ASS und
Clopidogrel 75 mg", "Kontrollen durch Facharzt", ...}
AHK =
{("Herzchirurgie", " Herzchirurgische Notoperation ", pid)}.
151
Serviceflows zur Modellierung klinischer Behandlungsketten
Der Arbeitsablauf in den MSPs kann den Abschnitten 3.2.3 und 3.2.4 aus Kapitel 3
entnommen werden. Der Aktivator AST kann der Vorbereitungs- und Durchführungsphase der
HK-Untersuchung zugeordnet werden. Die Aktivierung erfolgt manuell durch den
verantwortlichen Arzt.
Der Serverprozess, der den AP darstellt, kann als MSP nach [Def. 4.6] folgendermaßen
abgebildet werden: AP = (BezAP, DAP, VAP, MAP, NAP, AAP) mit
BezAP = "HL7 AP client"
DAP =
{"Verarbeiten von Aufnahmenachricht im HL7-Format"}
VAP =
{"Patientenaufnahme"}
MAP =
GENP ∪ GENA ∪ GENL1
NAP =
{"Stationäre Betreuung kardiologischer Patienten auf Station 8",
"Aufnahmeuntersuchung auf Station 8", ...}
AAP =
Ø.
Der SMSF nach [Def. 4.8] für das medizinische Vorgehen dieses Beispiels ist
SMSF = ((AP, 5 sec.), (ST, 1 Tag), (HK, 45 Min.), (ST, 1 Tag)).
Die Zeitspannen sind hier als Richtwert zu sehen. Es wird ausgedrückt, dass der Patient im
Normalfall am Tag nach der Aufnahme im HK-Labor behandelt und am dritten Tag, also
nach der zweiten Übernachtung, entlassen wird. Die Zeiten können z. B. bei der
Terminplanung im HK-Labor oder auf der Station verwendet werden.
In diesem Beispiel sei die pid des Patienten 1 und der Patient zum ersten Mal in der Klinik.
Es existiert also noch keine Krankenakte.
Sobald der Patient in der Patientenaufnahme aufgenommen wurde, wird durch das KIS eine
entsprechende Nachricht an AP gesendet. Es wird davon ausgegangen, dass die Nachricht
alle zur Aufnahme relevanten Daten wie Personalien, Krankenkasse und Station enthält.
Dadurch wird der PS PS initialisiert zu:
PS = (Ø, Ø, "Verarbeiten von Aufnahmenachricht im HL7-Format", Ø, 1)
Nach Auswerten der Aufnahmenachricht wird ein Datensatz für den Patienten in der
Krankenakte angelegt, ein stationärer Aufenthalt eröffnet und alle bekannten Daten
eingetragen (vgl. Tab. 4.7). Abschließend wird der PS modifiziert zu
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15)), Ø,
("Stationäre Betreuung kardiologischer Patienten auf Station 8", 12.11.2004
09:16), ("Aufnahmeuntersuchung auf Station 8", 12.11.2004 09:16), 1)
und Patient und Servicefloat somit an den nächsten Service Point, nämlich die Station,
weiter gereicht.
152
Serviceflows zur Modellierung klinischer Behandlungsketten
Tabelle Stammdaten
pid
Name
1
Test
Vorname
Peter
Geboren
PLZ
10.01.1920
12345
Ort
Telefon
Testort
0123 4567
Krankenkasse
AOK Testort
Tabelle Aufenthalt
pid
anr
1
2
Von
Eingriff
Ort
12.11.2004
Stationäre Betreuung kardiologischer Patienten
auf Station 8
Testort
KISNR
44556
Tabelle Station
anr
doknr
2
4
Tab. 4.7:
Start
09:32
Station
Station 8
Belegung der Felder, deren Inhalt verändert wird, nach der Patientenaufnahme. Alle
anderen Tabellen und Felder der SK des Patienten mit der PID 1 sind leer.
Der Patient begibt sich zur Station, auf der die Aufnahmeuntersuchung vom diensthabenden
Arzt durchgeführt wird. Durch den PS ist der Arzt in der Lage sofort den Patienten zu
identifizieren und die korrekte SK zu bearbeiten. Bei der Aufnahmeuntersuchung, welche
hier 27 Minuten dauern soll, wird der aktuelle PS erhoben, die Einweisungsdiagnose
verifiziert und eine Blutprobe entnommen, welche zum Labor weitergeleitet wird. Um dies
dem Labor mitzuteilen wird AST aktiviert. Die Änderungen an der SK können Tab. 4.8
entnommen werden. Nach der Aufnahme hat PS den folgenden Zustand:
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15),
("Aufnahmeuntersuchung auf Station 8" , 12.11.2004 10:38)), ("Herzkatheter in
Dilatationsbereitschaft", 13.11.2004), ("Stationäre Betreuung kardiologischer
Patienten auf Station 8", 12.11.2004 11:05), Ø, 1)
Zu beachten ist hier, dass für den geplanten Herzkatheter keine Uhrzeit, sondern nur ein
Datum angegeben ist.
Tabelle Station
anr
doknr
2
4
Arzt
Dr. Station
Indikation
AP
III,
Verdacht
pathologisches EKG
Diagnose
auf
KHK,
AP III, Verdacht auf KHK
Tabelle StaICD
doknr
4
Tab. 4.8:
ICD
I20.9
Belegung der Felder, deren Inhalt sich durch die Aufnahmeuntersuchung verändert hat.
153
Serviceflows zur Modellierung klinischer Behandlungsketten
Nach Abruf der Laborwerte entscheidet der verantwortliche Oberarzt, dass der Patient am
nächsten Tag standardmäßig der HK-Untersuchung zugeführt wird. Dies wird in PS
vermerkt:
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15),
("Aufnahmeuntersuchung auf Station 8" , 12.11.2004 10:38)), ("Herzkatheter in
Dilatationsbereitschaft", 13.11.2004), ("Stationäre Betreuung kardiologischer
Patienten auf Station 8", 12.11.2004 11:05), ("Herzkatheter in
Dilatationsbereitschaft", 13.11.2004 13:40), 1)
Nach einer komplikationslosen Nacht wird der HK am nächsten Tag durchgeführt. Zu Beginn
wird PS modifiziert zu:
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15),
("Aufnahmeuntersuchung auf Station 8" , 12.11.2004 10:38), ("Stationäre
Betreuung kardiologischer Patienten auf Station 8", 12.11.2004 11:05)), Ø,
("Herzkatheter in Dilatationsbereitschaft", 13.11.2004 13:48), Ø, 1)
Die Untersuchung erfolgt komplikationslos. Es werden diverse Parameter am Herzen
vermessen und als primärer Grund für die Krankheitssymptome eine Zweigefäßerkrankung
mit zwei signifikanten Stenosen, einer 90 %igen Stenose des medialen RIVA und eine 70
%ige Stenose der distalen RCA, diagnostiziert. Der Arzt entscheidet sich nur die RIVAStenose zu behandeln, da die andere keine hämodynamische Relevanz hat. Die Dilatation
mit primärer Stentimplantation erfolgt ebenfalls komplikationslos. Die Änderung von SK nach
der Dokumentation durch den Arzt kann Tab. 4.9 entnommen werden. PS hat nach
Rückverlegung auf die Station den Zustand:
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15),
("Aufnahmeuntersuchung auf Station 8" , 12.11.2004 10:38), ("Stationäre
Betreuung kardiologischer Patienten auf Station 8", 12.11.2004 11:05),
("Herzkatheter in Dilatationsbereitschaft", 13.11.2004 13:48)), Ø, ("Stationäre
Betreuung kardiologischer Patienten auf Station 8", --), Ø, 1)
Bis zum nächsten Tag wird der Patient auf der Normalstation überwacht und nach einem
komplikationslosen Verlauf entlassen. Die entsprechende Modifikation von SK kann Tab.
4.10 entnommen werden. Genau genommen hätte eigentlich der stationäre Aufenthalt
geschlossen und wieder ein neuer nach dem HK unter einer neuen doknr eröffnet werden
müssen. PS hat nach der Entlassung den Zustand:
PS = ((("Verarbeiten von Aufnahmenachricht im HL7-Format", 12.11.2004 09:15),
("Aufnahmeuntersuchung auf Station 8" , 12.11.2004 10:38), ("Stationäre
Betreuung kardiologischer Patienten auf Station 8", 12.11.2004 11:05),
("Herzkatheter in Dilatationsbereitschaft", 13.11.2004 13:48), ("Stationäre
Betreuung kardiologischer Patienten auf Station 8", 14:46)), Ø, Ø, ("Arztbrief
schreiben", 14.11.2004 15:10), 1)
154
Serviceflows zur Modellierung klinischer Behandlungsketten
Tabelle: HK
doknr
5
Start
Stop
13.11.2004 11:20
PAoAscSys
120
Labor
13.11.2004 11:20
PAoAscDia
90
1
Indikation
AP III, Verdacht auf
KHK, pathologisches
EKG
Diagnose
Procedere
Zweigefäßerkrankung
Druckverband 8 Stunden
Untersucher
Chefarzt Prof. Dr. Chef
EF
53
Befund
Eingeschränkte EF, 90 %ige Stenose des
medialen RIVA,70 %ige Stenose der
distalen RCA
Therapieempfehlung
Konservativ, Medikation mit ASS und
Clopidogrel 75 mg
Tabelle HKStenose
doknr
Gefäß
Stenosegrad
5
prox. RIVA
25
5
med. RIVA
90
5
dist. RCA
70
Tabelle HKDilatation
doknr
5
Gefäß
med. RIVA
StenosPrä
90
StenosePost
0
Verfahren
Direkte Stentimplantation
Tabelle HKICD
doknr
ICD
5
I25.12
5
I20.9
Tabelle HKOPS
doknr
OPS
5
1-275.0
5
8-837.k0
Tab. 4.9:
Belegung der Felder, deren Inhalt verändert wird, nach dem HK. Auf Protokoll und
Material wurde verzichtet.
Nachdem der Patient entlassen wurde, ist noch die abschließende Tätigkeit des
Arztbriefschreibens durch den zuständigen Stationsarzt zu erledigen. Nachdem dieser
Schritt abgearbeitet wurde, kann PS gelöscht und die SK archiviert werden.
Wäre es in dem Beispiel zu einer Komplikation im HK-Labor gekommen, die eine
Notoperation erforderlich gemacht hätte, so wäre ein Aktivator aus AHK aktiviert und PS
angepasst worden. Die Dokumentation durch den Kardiologen im HK-Labor wäre mit
anderen Inhalten ebenfalls erfolgt. Der weitere Verlauf des Krankenhausbesuches wäre
dann über die Herzchirurgie fortgesetzt worden. Durch die dynamische Anpassbarkeit von
PS und SK muss nur die Notfallmaßnahme modelliert werden. Der restliche Ablauf ergibt
155
Serviceflows zur Modellierung klinischer Behandlungsketten
sich einzig aus dem tatsächlichen Krankheitsverlauf. Das Dokumentationssystem passt sich
aus Sicht des Anwenders diesem an und zwingt den Systemnutzer nicht zu speziellen oder
schwer nachvollziehbaren Sonderaktionen um Ausnahmefälle abzufangen.
Tabelle Aufenthalt
pid
anr
1
2
Bis
Eingriff
14.11.2004
HK 123/04: Erfolgreiche primäre Stentimplantation med. RIVA 90->0%,
dist. RCA 70%, EF: 53%
Tabelle: Station
doknr
4
Stop
Befund
14.11.2004 15:10
Diagnose
Zweigefäßerkrankung
Eingeschränkte EF, 90 %ige Stenose des medialen RIVA, 70 %ige
Stenose der distalen RCA
Therapieempfehlung
Konservativ, Medikation mit ASS 100 und Clopidogrel 75 mg
Tabelle StaICD
doknr
ICD
4
I25.12
4
I20.9
Tabelle StaOPS
doknr
OPS
4
1-275.0
4
8-837.k0
Tab. 4.10: Belegung der Felder, deren Inhalte bis zur Entlassung verändert wurden.
156
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
5 Eine Software-Architektur zur Implementierung
kardiologischer Abteilungsinformationssysteme
In diesem Kapitel wird eine Software-Architektur vorgestellt, welche die Umsetzung des im
vorhergehenden Kapitel erarbeiteten Modells ermöglicht. Weiterhin verfügt diese Architektur
über Bausteine, die grundsätzliche Funktionen medizinischer AIS, wie sie in Kapitel 3
hergeleitet wurden, abdeckt.
Basierend auf dieser Architektur wurde bereits ein Prototyp im OFFIS im Projekt "GO#"
(ausgesprochen GO-Sharp11) entwickelt, der in der Kardiologie der Klinikum Oldenburg
gGmbH zum Einsatz kommt. Bei der im Folgenden vorgestellten Architektur wurde daher
Wert auf deren praktische Realisierbarkeit gelegt. Zentrale Anforderungen an die SoftwareArchitektur sind daher unter anderen:
•
Die Software soll auf einer möglichst breiten Basis installierter Betriebssysteme
funktionsfähig sein. Wünschenswert ist eine vollständige Unabhängigkeit vom
Betriebssystem. Ist diese nicht möglich, soll zumindest Microsoft Windows, welches
auf über 90 % aller Desktop-PCs anzutreffen ist (vgl. [Wil04]), unterstützt werden.
•
Bei der Vernetzung der PCs wird von Fast-Ethernet mit einer Bandbreite von
maximal 100 MBit/s (für Nutzdaten bleiben netto ca. 9 MByte/s übrig) ausgegangen.
•
Zur Entwicklung der Software wird eine moderne, objektorientierte und kommerziell
verfügbare Programmiersprache verwendet. Da diese Programmiersprachen an das
Englische angelehnt sind, wurden bei der Implementierung von GO# zur besseren
Lesbarkeit des Programmcodes nur englischsprachige Bezeichner für Klassen,
Methoden, Variablen etc. verwendet. Daher werden in diesem Kapitel bei Auszügen
aus der Implementierung wie z. B. Variablenbezeichnungen oder Methodennamen
englische Bezeichnungen verwendet.
•
Zur Datenhaltung werden kommerziell verfügbare, bzgl. Zuverlässigkeit
Geschwindigkeit erprobte DBMSe verwendet, die Standards wie SQL92 (vgl.
[EN02])
genügen
und
nicht
über
spezielle
Optimierungen
Konfigurationsmöglichkeiten z. B. zur Priorisierung von Datentransfers
Verwaltung proprietärer Datentypen verfügen.
und
z. B.
oder
oder
11
Der Name GO# wurde in Anlehnung an das existierende Projekt "GO-Kard" und die
Programmiersprache "C#", in der die neuen Programme implementiert werden, gewählt.
157
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Diese Implementierung erlaubt erste kritische Betrachtungen der serviceflow-basierten
Modellierung klinischer Behandlungsketten und der Umsetzung der vorgestellten
Anforderung an medizinische AISe.
In Kapitel 5 wird zunächst die grundsätzliche Struktur der Software-Architektur beschrieben.
Danach werden die einzelnen Bausteine näher betrachtet und ihr interner Aufbau
vorgestellt. Am Ende dieses Kapitels werden die Implementierung von GO# und Ergebnisse
der Testphase vorgestellt und diskutiert.
5.1 Architektur
Die hier vorgestellte Implementierung soll zu dem bereits im Produktiveinsatz befindlichen
System "GO-Kard" kompatibel sein. Daher wird eine klassische Client-Server-Architektur
unter Nutzung eines RDBMS, zurzeit ORACLE 9i, verwendet. Auf diese gemeinsame
Datenbasis können sowohl ältere GO-Kard-Clients, als auch neue Programme, die mit Hilfe
der neuen Software-Architektur entwickelt wurden, zugreifen.
Auf Grund des modularen Aufbaus ist es aber auch durch Änderung der Schnittstelle zu den
Datenspeichern möglich, andere Architekturen zu realisieren. So wäre z. B. die Anbindung
an eine XML- oder objektrelationale Datenbank denkbar, die aber zurzeit wegen der
Kompatibilität zur relationalen Datenbank von GO-Kard nicht realisiert ist.
Ein browserorientierter Ansatz, bei dem die Software auf dem Client in einem Web-Browser
läuft, konnte auch nicht gewählt werden, da hier der Zugriff auf Hardware-Ressourcen wie
Netzwerkkarten oder serielle Schnittstellen nur stark eingeschränkt möglich ist. Diese
direkten Zugriffe werden aber für Kommunikationsschnittstellen wie DICOM und HL7 ebenso
wie zur Kommunikation mit medizinischen Geräten benötigt.
Da die Visualisierung und Verarbeitung multimedialer Daten, insbesondere Filme und Bilder
aus medizinischen Großgeräten, unterstützt werden soll, empfiehlt sich die Verwendung
eines Applikationsservers nicht. Dieser müsste z. B. einen Herzkatheterfilm mit einer
Auflösung von 512 x 512 Pixeln bei 8 Bit Farbtiefe und 25 Bildern pro Sekunde an den Client
übertragen. Da der Applikationsserver die Filmdaten dekomprimiert und die endgültige
Anzeige an das angeschlossene Terminal weiterleitet, würde hier eine Bandbreite von
512 x 512 x 1 x 25 [Byte/s] = 6.553.600 [Byte/s] ≈ 6,5 [MB / s]
benötigt. Dies würde bereits bei nur zwei abgespielten Filmen ein Fast-Ethernet-Netzwerk
überlasten. Im Gegensatz dazu benötigt der Originalfilm, welcher im Fall des
Herzkatheterfilms nach dem DICOM-Standard mit dem verlustfreien "JPEG lossless"
Verfahren (Joint Picture Expert Group, siehe [JPEG]) komprimiert ist, nur eine Bandbreite
von durchschnittlich ca. 3 MByte/s. Noch weniger Bandbreite benötigen Filme, die durch
verlustbehaftete Verfahren wie z. B. MPEG4 (Motion Picture Expert Group, siehe [MPEG])
158
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
komprimiert wurden. Der Qualitätsverlust durch die Komprimierung reicht dann selbst bei
Bandbreiten von weniger als 0,4 MB/s für die Nachbetrachtung zu medizinischen Zwecken
vollkommen aus (vgl. [CKRE01], [KCHM01], [KVCM01] und [Voc02]). Der komprimierte
Datenstrom muss jedoch vom Client dekomprimiert und angezeigt werden. Hierfür verfügen
PCs aber schon seit mehreren Jahren über ausreichend Rechenleistung (vgl. [CAKR00]).
Da weder eine web-basierte Architektur noch ein Applikationsserver verwendet werden
können, wurde eine klassische Client-Server-Architektur unter Implementierung eines FatClients gewählt. Um die Antwortzeit aus Sicht des Clients gering zu halten, können
unterschiedliche Serverdienste durch verschiedene Server bearbeitet werden. Es wird hier
zwischen vier Diensten unterschieden:
•
Datenbank
•
Gemeinsam genutzte Dateien (Filesharing), insbesondere multimediale Daten
•
DICOM
•
HL7.
Diese Verteilung der Dienste ermöglicht eine einfache Nutzung von verteilten Hardwareressourcen. Würden z. B. multimediale Objekte in der Datenbank in spezielle Attributtypen
abgelegt, belegten diese bei der Anforderung durch einen Client relativ viel Bandbreite der
Festplatten- und Netzwerkressourcen des Datenbankservers. Greifen in diesem Moment
mehrere andere Clients auf den Datenbankserver zu, die nur kleine Texteinträge anfordern,
so würden diese durch den Transfer der multimedialen Daten unnötig behindert.
Daher ist es hier sinnvoll, dass der Client aus der Datenbank nur die Information bekommt,
wo sich die multimedialen Daten befinden, und diese dann von einem dedizierten Fileserver
anfordert. Dieser Fileserver kann zusätzlich für die Verwaltung, Organisation und
Bereitstellung von Dateien optimiert werden. Für den Datenbankserver kann wiederum
Hard- und Software verwendet wird, die für den Betrieb eines RDBMs ausgelegt ist. In Abb.
5.1 ist die grundsätzliche Netzwerkstruktur, auf der GO# aufsetzt, abgebildet.
Für die Implementierung der Software wurde ein objektorientierter Ansatz in Verbindung mit
einer Komponentenarchitektur (vgl. [ABCW02], [BMRS00], [Mic05]) gewählt. Der Einsatz
komponentenorientierter Softwarearchitekturen für medizinische Anwendungsgebiete hat
sich schon in anderen Projekten bewährt (vgl. z. B. [AFGW01]) und kommt unter anderen
aus folgenden Gründen zum Einsatz:
•
Konfigurierbarkeit: Einzelne Komponenten können, je nach Anwenderwunsch, in
unterschiedlichen Konfigurationen zu Applikationen zusammengefügt werden.
•
Wartbarkeit: Komponenten können einzeln getestet und gewartet werden.
Seiteneffekte durch Änderungen von Code können verringert werden. Fehlerhafte
Komponenten können einzeln ausgetauscht werden, ohne jedes Mal die gesamte
Applikation zu ersetzen.
159
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
•
Widerverwendbarkeit: Komponenten können in unterschiedlichen Applikationen für
ähnliche Aufgaben eingesetzt werden.
•
Erweiterbarkeit: Durch das zusätzliche Einbinden neuer oder den Austausch
bestehender Komponenten kann die Applikation um neue Funktionen erweitert
werden. Dies ist z. B. bei der "Internationalisierung" der Software interessant. Hier
können Komponenten für länderspezifische Aufgaben, wie automatisierte
Textgenerierung
oder
Ermittlung
von
Abrechungsziffern,
je
nach
Anwenderanforderungen durch länderspezifische Versionen realisiert werden. Die
jeweils für die Installation passende Variante wird dann zur Laufzeit bestimmt,
geladen und ausgeführt.
•
Entwicklung im Team: Nachdem die gemeinsam genutzten Bausteine der
Software-Architektur fertig gestellt sind, können Komponenten unabhängig
voneinander durch unterschiedliche Personen entwickelt werden, ohne dass der
einzelne Entwickler auf Ressourcen oder Programmcode anderer Entwickler
angewiesen ist.
IDC
Abb. 5.1: Architektur zur Verwendung unterschiedlicher, dedizierter Server für die einzelnen
Dienste. Die Verbindungen zwischen den Rechnern ist in logischer und nicht in
physikalischer Sicht dargestellt.
160
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Die Komponenten sind in ein Rahmenfenster eingebettet, welches zusätzlich grundlegende
Funktionen wie z. B. Kommunikation mit der Ereignisweiterleitung und -verarbeitung
(Eventqueue) des Betriebssystems bereitstellt. Der Aufbau der Komponenten und der
Rahmenarchitektur wird in Abschnitt 5.3 näher erläutert, eine Übersicht kann Abb. 5.2
entnommen werden.
Aus logischer Sicht gibt es grundsätzlich drei verschiedene Arten von Komponenten:
•
GUI-Komponenten (graphical userinterface), welche die Schnittstelle zum
Anwender bilden, Informationen anzeigen und Funktionen zur Manipulation von
Daten bereitstellen.
•
Steuerkomponenten, welche dem Anwender die Möglichkeit zur Auswahl eines
gewünschten Datensätze geben. Nach erfolgter Selektion eines Datensatzes durch
den Anwender versenden die Steuerkomponenten eine Nachricht an die GUIKomponenten und initiieren bei letzteren das Laden, Anzeigen und Verwalten der
gewählten Daten.
•
Hintergrundkomponenten, die nur Funktionalitäten zur Verarbeitung von an sie
gesendete Daten zur Verfügung stellen und keiner Interaktion durch den Anwender
bedürfen. Diese Komponenten werden entweder durch äußere Ereignisse (z. B. das
Eintreffen einer HL7-Nachricht) oder durch Anwenderaktionen, die von einer GUIKomponente entgegen genommen und an die Hintergrundkomponente
weitergeleitet werden, aktiviert. Hierunter fallen insbesondere die Datenbank-,
Geräte-, und Kommunikationsschnittstellen.
Um das in Kapitel 4 vorgestellte Konzept des medizinischen Serviceflows abzubilden, wird
die aktuelle Ausprägung des PS für jeden Patienten in der Datenbank gespeichert. Auf die
dort hinterlegten Informationen über den Patienten haben die Steuerkomponenten Zugriff
und können so entscheiden, welche Informationen wann an welchem Ort wem zur Auswahl
angeboten werden.
Für die Modifikation des PS, z. B. beim Abschluss der Dokumentation eines Engriffs, gibt es
spezielle GUI-Komponenten, welche in Abschnitt 5.3 näher vorgestellt werden. Die logische
Struktur zur Umsetzung des MSF-Konzepts wird in Abschnitt 5.4 im Detail betrachtet.
Bevor im Detail auf die Software-Architektur eingegangen wird, werden vorher noch im
folgenden Abschnitt Besonderheiten des Datenmodells vorgestellt. Dieses sichert gewisse
Eigenschaften zu, die notwendig sind, um das MSF-Konzept abzubilden. Diese
Eigenschaften werden in Abschnitt 5.3 bei der Beschreibung des Aufbaus der Komponenten
wieder aufgegriffen.
161
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Rahmenfenster
Steuerkomponenten
GUI-Komponenten
Hintergrundkomponenten
(Canvas, Menüs,
Optionen, ...)
(Auswahllisten für
Datensätze)
(Document + Controller
oder property-basiert)
(Model + Controller)
Interner Kommunikationsbus
Datenbankschnittstelle
(Hintergrundkomponente)
Geräteschnittstellen
(Hintergrundkomponenten)
HL7
DICOM
XDT
Proprietär (Cardis, PKI, etc)
Modalitäten
PostgreSQL
Oracle
weitere
Datenquellen
Abb. 5.2: Übersicht über die Komponentenarchitektur der Client-Software.
5.2 Das Datenschema
Neben den in Abschnitt 4.4 vorgestellten Datenschemata zur Dokumentation der
medizinischen Leistungen werden in der Datenbank noch der PS, Voreinstellungen
(Preferences) und Optionen für die Client-Software und allgemein gültige
Systemeinstellungen gespeichert. Sämtliche Einstellungen und Optionen werden in der
Datenbank und nicht lokal auf den Clients in Konfigurationsdateien gehalten. Dies
ermöglicht eine zentrale Verwaltung und Wartung aller Konfigurationen der einzelnen
Arbeitsplätze. So kann eine externe Wartung oder Aktualisierung der Software ohne Zugriff
auf die einzelnen Clientrechner erfolgen. Zugriffsrechte von außen auf den Datenbankserver
reichen aus, um sämtliche Einstellungen und Modifikationen vorzunehmen oder aktuelle
Konfigurationen einzelner Arbeitsstationen zum Testen oder Entfernen von Fehlern
einzusehen. Weiterhin wird der Austausch von Client-Rechnern vereinfacht, da keine
Dateien gesichert werden müssen. Die zusätzliche Belastung des Datenbankservers kann
vernachlässigt werden, da Tests mit dem Prototypen von GO# zeigten, dass beim Transfer
der Konfigurationsdaten und Optionen weniger als 500 Byte an ASCII-Daten zwischen Client
und Server ausgetauscht werden.
162
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Das Datenschema besteht somit aus folgenden Teildatenschemata:
•
Patientendatenschema (PD)
•
Anamnestisches Datenschema (AD)
•
Datenschemata zur Dokumentation medizinischer Leistungen (LD1, …, LDn)
•
Datenschema zum Speichern des PS (PSD)
•
Datenschema für Optionen, Systemeinstellungen und Codetabellen (OSCD).
Der grundsätzliche Aufbau von PD, AD und LD1, …, LDn kann den Abschnitten 4.3 und 4.10
(siehe hierzu insbesondere Abb. 4.19) entnommen werden. In Abb. 5.3 ist PSD als ERDiagramm dargestellt. Die konkrete Implementierung von L, G, K und O (vgl. Abschnitt 4.6,
[Def. 4.6b]) wurde folgendermaßen realisiert:
•
L, die Menge der durchgeführten Leistungen, wird durch diejenigen Zeilen in
P_Abteilungen, deren Start- und Stopp-Zeitpunkt gesetzt und kleiner oder gleich
dem aktuellen Zeitpunkt sind, repräsentiert. Weiterhin muss in Typ eine Leistung
eingetragen sein. Das Feld darf also nicht den Wert "geplanter Termin" oder "offene
Leistung" haben.
•
G, die Menge der geplanten Leistungen, besteht aus allen Zeilen, die in PS_Termin
zu finden sind und deren Datum größer oder gleich dem aktuellen Zeitpunkt ist.
Weiterhin muss Typ in P_Abteilungen den Inhalt "geplanter Termin" oder "offene
Leistung" aufweisen.
•
K, der aktuelle Aufenthaltsort des Patienten, ist durch die Relation PS_Status
abgebildet. Der aktuell durchgeführte Eingriff mit Aufenthaltsort ist über die Referenz
auf P_Abteilungen durch den Wert des Attributs DOKNR zu erhalten.
•
O, die Menge der offenen Leistungen, die durchgeführt werden müssen, besteht aus
allen Zeilen in PS_Termin, deren Datum größer oder gleich dem aktuellen Zeitpunkt
ist und bei denen Pflicht die Ausprägung "J" hat. Weiterhin muss Typ in
P_Abteilungen den Inhalt "geplanter Termin" oder "offene Leistung" aufweisen.
Die Zuordnung zu einem Patienten erfolgt entweder direkt über die PID (PS_Termin) oder
über die DOKNR und die Relationen P_Abteilungen und P_Aufenthalt.
Es ist Aufgabe der Client-Software und somit eine zentrale Anforderung an die SoftwareArchitektur, dafür zu sorgen, dass, sobald der Patient den MSP wechselt, die dort
vorhandene Software die Einträge in der Datenbank korrekt aktualisiert.
163
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Abb. 5.3: Datenschema zur Speicherung des PS (PSD) als ER-Diagramm. Die Erklärungen zu den
Tabellen und Attributen finden sich in Anhang D
In Abb. 5.4 sind exemplarisch Ausschnitte aus den Optionen, Systemeinstellungen und
Codetabellen abgebildet. In diesem Zusammenhang ist zu beachten, dass PSD relational
von PS über die PID abhängig ist, jedoch die Relationen in OSCD zunächst nichts mit einem
Patientendatensatz oder der Dokumentation von medizinischen Leistungen zu tun haben.
Diese in Abb. 5.4 dargestellten Relationen von OSCD dienen zunächst zum Speichern der
Konfiguration der Anwendungsprofile (Tabelle CFG_Profile) innerhalb der SoftwareArchitektur. Über die Relation CFG_Profile_Canvas_Def wird jedem Anwendungsprofil
eine Menge von Bildschirmseiten (engl. Canvas) zugeordnet. Jeder Canvas, der in
CFG_Canvas definiert ist, besteht wiederum aus mehreren Komponenten, die diesem durch
die Relation CFG_Canvas_Component zugeordnet werden. Wie diese Informationen durch
die Rahmenapplikation genutzt werden, wird im nächsten Abschnitt ausgeführt. Eine
Beschreibung der Tabellen und Attribute findet sich in Anhang E.
Abb. 5.4: Ausschnitt aus dem Datenschema zur Speicherung von Optionen, Systemeinstellungen
und Codetabellen (OSCD) als ER-Diagramm
164
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Für die Software-Architektur kann abschließend festgehalten werden, dass die Attribute, die
Datensätze innerhalb der Datenschemata zur medizinischen Dokumentation identifizieren,
PID, ANR und DOKNR (siehe zu deren Definition Abschnitt 4.4) sind. Dabei kann von einer
DOKNR stets eindeutig die zugehörige ANR und zu jeder ANR wiederum eindeutig die
zugehörige PID ermittelt werden. Weiterhin bleibt festzuhalten, dass PID, ANR und DOKNR
nach [Def. 4.4a], [Def. 4.4b], [Def. 4.3c] und [Def. 4.4] eindeutig sind, da
•
jede Relation aus PD eine PID,
•
jede Relation aus AD eine ANR und
•
jede Relation aus LDi (1 ≤ i ≤ n) eine DOKNR
haben muss. Es reicht also aus, PID, ANR und DOKNR zu kennen, um sämtliche
Informationen einer Untersuchung aus der Datenbank zu lesen. Somit sind auch die
Informationen, die durch die einzelnen Komponenten der Client-Software im Rahmen der
medizinischen Dokumentation verwaltet werden, immer von einer dieser drei
Identifikationsnummern abhängig.
5.3 Die Komponentenarchitektur
Beim Start der Applikation wird als Parameter der Name eines Applikationsprofils
übergeben. Dieses steht für mehrere Fenster, die in Form von sog. Canvastabs (Reiter)
verwaltet werden. Jedes dieser Fenster besteht wiederum aus mehreren Komponenten, die
jeweils ihre eigenen Oberflächenelemente zur Interaktion mit dem Anwender besitzen.
Die Konfigurationsinformationen, die festlegen, welche Applikation aus welchen Fenstern
und Komponenten besteht, werden in der Datenbank gespeichert. Deren Aufbau wurde im
vorherigen Abschnitt vorgestellt (vgl. Abb. 5.4).
In Abb. 5.5 ist die Benutzungsoberfläche für eine Beispielapplikation abgebildet. Das
Applikationsprofil "Lager" besitzt zwei Fenster "Produkte" und "Firmen". Davon ist beim Start
das erste Fenster zu sehen, welches vier Komponenten beinhaltet:
•
ProductSelectionTree: Dies ist eine Steuerkomponente mit deren Hilfe der
Anwender Datensätze auswählen kann.
•
Product: Diese GUI-Komponente dient zum Anzeigen und Manipulieren von Daten
zum Produkt.
•
OrderedProducts: Hier werden in einer GUI-Komponente die zurzeit offenen
Bestellungen eines Produkts angezeigt
•
Deliveries: Diese GUI-Komponente verwaltet Informationen
Lieferchargen, deren Artikel sich gerade im Lager befinden.
zu
einzelnen
165
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
ProductSelectionTree
OrderedProducts
Product
Deliveries
Abb. 5.5: Oberfläche einer Beispielapplikation zur Lagerverwaltung
Dieses Laden und Aufbauen der Applikation an Hand der Konfigurationsdaten übernimmt
die zentrale Steuerungskomponente der Applikation, der sog. Initializer. Nachdem
dieser die Applikation initialisiert hat, wird das erste Fenster vom Typ "Steuerungsfenster"
angezeigt und sämtliche "Datenfenster" ausgeblendet.
"Steuerungsfenster" repräsentieren Bildschirmseiten, die Steuerkomponenten enthalten und
dem Anwender die Möglichkeit zur Selektion von Datensätzen aus Listen geben.
"Datenfenster" enthalten ausschließlich GUI-Komponenten. Ihr Inhalt wird geladen, wenn ein
Datensatz mit Hilfe einer Steuerkomponente ausgewählt wurde, und dieser Datensatz Daten
enthält, die in mindestens einer GUI-Komponente des "Datenfensters" angezeigt werden.
Diese Fenster dienen also zur Visualisierung, Erfassung und Manipulation von Datensätzen.
Die gesamte Kommunikation erfolgt dabei über den Initializer. Wählt der Anwender
einen Datensatz mit Hilfe einer Steuerkomponente aus, so teilt diese dem Initializer
die Primärschlüssel, also PID, ANR und DOKNR, des ausgewählten Datensatzes mit. Der
166
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Initializer schickt nacheinander allen bei ihm registrierten GUI-Komponenten den
geänderten Primärschlüssel, woraufhin diese die von ihnen verwalteten Daten aus der
Datenbank laden. Jede GUI-Komponente teilt dem Initializer als Rückmeldung zwei
Dinge mit:
1. Ob die Komponente überhaupt von einem Primärschlüssel abhängig ist.
Dies ist notwendig damit der Initializer entscheiden kann, ob die Komponente
aktiviert wird. Hat diese nichts mit dem gesendet Primärschlüssel zu tun, so bleibt sie
inaktiv, damit nicht Daten erfasst werden können, die gar nicht zu dem Datensatz
gehören. Weiterhin werden nur Fenster aktiviert und ansteuerbar gemacht, die
mindestens eine aktive Komponente enthalten.
2. Informationen, ob weitere Abhängigkeiten zu beachten sind.
Dies ist dann der Fall, wenn zu einem Datensatz ein "untergeordneter" Datensatz im
Sinne einer Master-Detail-Relation existiert. So beinhaltet z. B. ein kardiologischer
Eingriff Informationen über durchgeführte Dilatationen an einem oder mehreren
Gefäßabschnitten. Im Rahmen jeder Dilatation können ein oder mehrere Stents
implantiert werden. Dies kann in der Datenbank durch zwei Relationen, die jeweils
eine 1:nc-Beziehung zu ihrer übergeordneten Relation haben, repräsentiert werden
(vgl. Abb. 5.6). Wird nun eine Dilatation eines speziellen Gefäßabschnittes geladen,
so dürfen nur die für diese Dilatation verwendeten Stents angezeigt werden und nicht
alle Stents, die während der Intervention verwendet wurden (es könnten auch noch
Stents in anderen Gefäßabschnitten eingesetzt worden sein). Somit muss die GUIKomponente, die Daten zur Dilatation verwaltet, dem Initializer mitteilen, dass
eine spezielle Intervention, die z. B. eindeutig durch eine DOKNR und eine
Interventionsnummer (IVNR) in der Datenbank identifiziert werden kann, geladen
wurde. Damit liegen alle Informationen zur eindeutigen Identifizierung der Dilatation
vor und alle hiervon abhängigen GUI-Komponenten können ihren Inhalt unter
Verwendung der eindeutigen Identifikationsinformationen (in diesem Beispiel
DOKNR und IVNR) laden.
Abb. 5.6: Beispiel der Speicherung von Informationen zu Dilatationen mit von diesen abhängigen
Daten über verwendete Stents
167
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Dieses kaskadierende Laden kann in beliebiger Tiefe von Master-Detail-Relationen
fortgesetzt werden. Ob und welche Abhängigkeiten bestehen, kann zur Laufzeit des
Programms dem Datadictionary der Datenbank entnommen werden. In diesem sind
sämtliche Fremdschlüsselbeziehungen zwischen Relationen abgelegt. Besitzt also eine
GUI-Komponente Attribute aus einer Tabelle, die Master im Sinne einer Master-DetailRelation ist, so teilt diese dem Initializer mit, dass ein weiteres Laden von
Informationen aus der abhängigen Tabelle notwendig sein kann12. Beim Entwurf des
Datenschemas muss sorgfältig vorgegangen werden und strikt auf das Einhalten der dritten
Normalform (vgl. [EN02]), insbesondere auf
•
Vermeidung von Zyklen im Datenschema und
•
Zusicherung, dass jede Tabelle einen Primärschlüssel hat,
geachtet werden.
Während des Ladevorgangs merkt sich jede Komponente den Primärschlüssel, der an sie
übergeben wurde und von ihr zum Identifizieren und Laden von Daten verwendet wurde.
Dies ist notwendig, um nach der Manipulation von Feldinhalten die geänderten Daten wieder
in die Datenbank zurück zu schreiben.
Sind alle Daten eines Datensatzes geladen, werden alle "Datenfenster", welche
Komponenten mit aktualisierten Inhalten enthalten, angezeigt. Schließlich wird die
Eingabeaufforderung in der ersten aktiven und sichtbaren GUI-Komponente, die aus der
Konfiguration ausgelesen wurde, platziert und der Canvas dieser GUI-Komponente in den
Vordergrund geholt.
Der Anwender kann nun mit Hilfe der Oberflächenelemente Daten manipulieren und
gewünschte Aktionen ausführen. Das Speichern von Daten stößt jede Komponente von sich
aus an, sobald der Anwender Feldinhalte manipuliert hat. Dazu teilt die Komponente dem
Initializer mit, was verändert wurde und übergibt gleichzeitig den Primärschlüssel, der
zum Laden verwendet wurde. Der Initializer reicht dann die Daten zum Speichern an
die Datenbank weiter. Weiterhin benachrichtigt er alle abhängigen Komponenten darüber,
dass ein Wert geändert wurde. Diese können nun entsprechend reagieren und ggf.
Feldinhalte aktualisieren, wenn z. B. Berechnungen auf den geänderten Werten basieren.
Zusätzlich stellt der Initializer noch jeder Komponente Methoden zum Abfragen von
Werten zur Verfügung. So muss es z. B. für die Altersberechnung Methoden geben, mit
denen das Geburtsdatum und das aktuelle Untersuchungsdatum abgefragt werden können.
Wird nun ein Wert angefordert, so prüft der Initializer zunächst, ob dieser lokal in einer
GUI-Komponente verfügbar ist. Für den Fall des Geburtsdatums würde z. B. nachgesehen,
12
Ein weiteres Laden muss nicht unbedingt durchgeführt werden. Wenn z. B. im Applikationsprofil
keine Komponente, die Attribute der abhängigen Detail-Relation verwaltet, definiert ist, würde kein
weiterer Ladevorgang durchgeführt.
168
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
ob eine Komponente mit Patientenstammdaten initialisiert wurde, und bei dieser das
Geburtsdatum angefordert. Konnte der gewünschte Wert auf diese Weise nicht ermittelt
werden, wird er aus der Datenbank geladen. Durch dieses Vorgehen wird die Anzahl der
Zugriffe auf die Datenbank verringert.
Bei der GO#-Architektur übernimmt der Client die Transaktionssteuerung. Durch das direkte
Speichern wird dafür gesorgt, dass Oberfläche und Datenbank bzgl. ihrer Inhalte stets
synchronisiert sind. Ebenso werden Informationen zum Rückgängig-machen von Aktionen
durch den Client gespeichert und durchgeführt. Nur bei längeren Aktionen, wie z. B. das
Abbuchen von vordefinierten Materialstandards, können Komponenten Sperren auf Tabellen
oder Datensätzen in der Datenbank setzen. Dies wird aber durch die einzelnen
Komponenten mit Hilfe einer Anforderung an die Datenbankschnittstelle initiiert und muss
somit nicht als allgemeine Funktionalität durch den Initializer bereitgestellt werden.
Konflikte, die sich daraus ergeben, dass ein Feldinhalt eines Datensatzes von zwei
Anwendern gleichzeitig verändert wurde, müssen durch den Anwender aufgelöst werden.
Bei der klinischen Dokumentation werden Informationen in der Datenbank gespeichert und
nicht aufeinander aufbauende Transaktionen, wie z. B. bei der Änderung eines
Kontostandes, der durch Additionen und Subtraktionen verändert wird, ausgeführt. Daher
kann durch die Software in den meisten Fällen nicht entschieden werden, ob ein Feldinhalt
korrekt ist. Speichert z. B. ein Anwender für einen Patienten X dessen Anschrift als "Bremer
Str. 33" und ein anderer Anwender für denselben Patienten X die Anschrift "Oldenburger Str.
33" kann dieser Konflikt nur durch Rückfrage beim Anwender gelöst werden. Ob ein solcher
Konflikt auftritt, überprüft GO# indem vor dem Speichern eines Feldes der Wert des Feldes
aus der Datenbank ausgelesen und mit dem Wert verglichen wird, der ursprünglich vom
Client gelesen wurde. Hat sich hier etwas gegenüber dem ursprünglichen Wert geändert,
kann dies nur auf Manipulation durch einen anderen Client zurückzuführen sein und der
Anwender wird gefragt, welche Information korrekt ist und in der Datenbank abgelegt
werden soll. Es wird somit ein optimistisches Verfahren ohne exklusive Sperren von
Datensätzen angewendet. Dieses Verfahren wird auch von anderen Programmen, z. B.
ORACLE Forms 6 (vgl. [Ora99]) verwendet, wenn die Anwendung nur Daten verwaltet und
keine aufeinander aufbauenden Transaktionen benötigt.
In Abb. 5.7 ist ein Beispiel für das Vorgehen beim Speichern zu sehen. Zwei Clients, Client
A und Client B, laden nacheinander aus der DB den Inhalt des Feldes “Adresse“ von
demselben Datensatz des Patienten X, welcher den Wert “Bremer Str. 30“ hat. Client A
modifiziert diesen Wert zu “Bremer Str. 33“ und löst damit das Speichern in der DB aus.
Dies wird ohne Rückfrage durchgeführt, da der Wert in der DB von niemand anderem
modifiziert wurde und somit noch dem von Client A geladenen Wert entspricht. Etwas später
verändert Client B den Wert der Adresse des Patienten X zu “Oldenburger Str. 33“. Dies löst
wieder den Speichervorgang aus, der jedoch nicht ohne Rückfrage durchgeführt wird, da der
Wert in der DB zwischenzeitlich von Client A verändert und somit nicht mehr dem von Client
B ursprünglich geladenen Wert entspricht. Daher fragt Client B beim Anwender nach,
169
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
welcher der beiden Werte, “Bremer Str. 33“ oder “Oldenburger Str. 33“ korrekt ist. Da sich
der Anwender für “Oldenburger Str. 33“ entscheidet, wird dies in der DB gespeichert.
Abb. 5.7: Vorgehen beim Speichern von Daten in der Datenbank
Zusammenfassend ist der Initializer die zentrale Komponente,
•
welche anhand der Konfigurationsdaten die gewünschten Komponenten initialisiert
und auf die Canvases verteilt,
•
bei der alle Komponenten registriert sind,
•
die für die Kommunikation mit der Datenbank und weitere Peripherie sorgt und
•
für die Bereitstellung von Daten verantwortlich ist.
170
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Der Initializer stellt die Kommunikationsinfrastruktur für die gesamte Applikation zur
Verfügung. Er entspricht also gerade dem in Abb. 5.2 dargestellten internen
Kommunikationsbus, an den unabhängige Komponenten über eindeutig definierte
Kommunikationsschnittstellen angebunden werden.
Neben den Steuerkomponenten, die auf einer speziellen Architektur aufbauen, können die
GUI-Komponenten, welche die Grundbausteine der Benutzungsoberfläche sind, zwei
unterschiedlichen Konzepten folgen:
•
dem Document-View-Konzept, welches eine Abwandlung des klassischen ModellView-Controller-Ansatzes ist, und
•
einem Konzept, das an C# (vgl. [VC#H]) und Microsofts .NET-Architektur (vgl.
[MNET]) im Zusammenspiel mit dem VisualStudio 2005 angelehnt ist und hier mit
"property-basiert" bezeichnet werden soll.
In den folgenden Abschnitten werden diese drei Konzepte (Steuerkomponenten, DocumentView-Konzept, "property-basiert") näher vorgestellt. Danach wird noch kurz auf den Aufbau
der Hintergrundkomponenten eingegangen.
5.3.1 Steuerkomponenten
Diese Komponenten dienen zur Auswahl von Datensätzen und bestehen meistens aus einer
Auswahlliste und Schaltflächen, die zum Suchen von Datensätzen, die in der Liste nicht
verfügbar sind, verwendet werden. An Hand von Auswahlkriterien, die in Form des WHERETeils eines SQL-SELECT-Kommandos implementiert sind, werden dem Anwender
Datensätze präsentiert. Durch die Auswahlkriterien sollen dem Anwender, abhängig vom
Arbeitsplatz an dem er sich befindet, immer genau die Patienten und Untersuchungen zur
Auswahl angeboten werden, die hier entweder als nächstes behandelt werden oder deren
Datensätze noch vervollständigt werden müssen. Dies entspricht gerade den Datensätzen,
die im Sinne des MSF zu den Patienten gehören, die durch den MSP bereits aktuell oder als
nächstes behandelt werden. MSPs, die nur Hintergrundprozesse bearbeiten und nicht der
Anwesenheit des Patienten bedürfen, können die Listen auch Datensätze anzeigen, für die
noch Aufgaben, wie z. B. das Schreiben eines Entlassungsbriefs oder die Analyse einer
Blutprobe, ausstehen.
Die für diese Auswahllisten notwendigen Informationen können dem PS entnommen
werden, da in diesem geplante Dienstleistungen mit Zeiten festgehalten sind. Ein Beispiel
zur Selektion eines Tagesplans wurde bereits in Abschnitt 4.7 vorgestellt.
Steuerkomponenten besitzen einen direkten Zugriff auf den Benachrichtigungsmechanismus
des Initializers und können Ladevorgänge aktivieren. Dazu schicken Sie nach
Auswahl eines Datensatzes eine Nachricht an den Initializer. Diese Nachricht
beinhaltet den Primärschlüssel des Datensatzes und führt dazu, dass allen GUI-
171
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Komponenten mitgeteilt wird, dass sie ihre Oberflächen mit den Daten, die sie an Hand des
Primärschlüssels aus der Datenbank laden können, aktualisieren sollen.
Der Aufbau der Steuerkomponenten kann einfach gehalten werden. Die SoftwareArchitektur stellt hierfür die spezielle Klasse ListManager für Auswahllisten mit
Suchfunktionen zur Verfügung. Diese Listen können in Containerobjekten, die von der
allgemeinen Basisklasse GSView abgeleitet werden und beliebige Oberflächenelemente (in
.NET werden diese allgemein als “Controls“ bezeichnet) aufnehmen können, eingebettet
werden. Diese Containerobjekte werden wiederum in den einzelnen Fenstern der
Benutzungsoberfläche eingeblendet. Das zugehörige Klassendiagramm zeigt Abb. 5.8.
Steuerkomponenten nutzen von der Basisklasse GSView nur mInitializer, über den der
Zugriff auf den Kommunikationsbus und die Rahmenarchitektur möglich ist. Das Document
mDocument wird nur von GUI-Komponenten, die auf dem Document-View-Konzept (siehe
nächster Abschnitt) basieren, benötigt und ist für andere Komponenten undefiniert, also mit
dem Wert null belegt. Weiterhin werden folgende Methoden, die die Basisklasse zur
Verfügung stellt, genutzt:
•
GSInitialize: Initialisiert die Komponente, darf nur einmal bei der Instanziierung
aufgerufen werden
•
FindControl: Sucht ein Control in der Komponente mit einem bestimmten Namen
innerhalb der Komponente
•
ActivateAllControls: Aktiviert alle Controls der Komponente, so dass sie auf
Benutzerinteraktionen reagieren können
•
DeactivateAllControls: Deaktiviert alle Controls der Komponente, so dass sie
nicht mehr vom Benutzer verwendet werden können
•
ClearAllFields: Setzt alle Feldinhalte zurück und versetzt die Komponente in
ihren Ausgangszustand, stößt bei Steuerkomponenten das Aktualisieren der Liste an
•
LoadAllFields: Stößt das Neuladen aller Feldinhalte abhängig von einem
Primärschlüssel an, wird von Steuerkomponenten nicht benötigt
•
Notify: Diese Methode wird vom Initializer aufgerufen, um der Komponente
beliebige Ereignisse mitzuteilen, auf welche die Komponente reagieren kann, wenn
sie von dem Ereignis betroffen ist
•
SendNotification: Über diese Methode kann die Komponente Nachrichten an
den Initializer und somit an alle anderen dort registrierten Komponenten
versenden.
Die Ableitungen implementieren nur das Verhalten der Komponente, wenn ein Datensatz in
der Liste durch den Anwender ausgewählt wurde und ihre Reaktion auf Nachrichten, die
ihnen vom Initializer zugesendet werden. Ersteres wird in dem Beispiel aus Abb. 5.7
172
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
durch Reaktion auf die Ereignisse RowSelected und BeforeSelect in den Methoden
mScheduledPatientsList_RowSelected und productTreeView_BeforeSelect,
erledigt. Letzteres wird, soweit notwendig, durch Überschreiben der Klasse Notify
ermöglicht.
Abb. 5.8: Beispiel des Klassendiagramms der Steuerkomponenten an hand der Klassen
"SelectionTree" und "ScheduledPatients". Diese sind Ableitungen der allgemeinen
Containerklasse GSView.
Bei den Member-Variablen fällt auf, dass diese alle entweder "privat" (gekennzeichnet durch
ein "-" vor dem Namen) oder "protected" ("#"-Symbol) sind. Dies ist in der Unabhängigkeit
der Komponenten voneinander begründet. Nur über die Methoden, die die
Kommunikationsschnittstelle zur Rahmenarchitektur darstellen, ist ein Datenaustausch
möglich.
Die einzelnen von GSView abgeleiteten Container sind wieder Controls im Sinne von .NET,
da sie dem Anwender Funktionalität an der Benutzungsoberfläche zur Programmkontrolle
zur Verfügung stellen. In der vorliegenden Software-Architektur werden die GSViews direkt
als Controls in die Fenster eingebunden. Dazu haben sie eine rechteckige Grundfläche, die
einer von zehn vordefinierten Rastergrößen von 50 x 50 bis 1.000 x 650 Pixeln entspricht.
Da der Anwender individuell zusammenstellen kann, welche Komponente auf welcher Seite
angezeigt wird, stellt das Raster sicher, dass die Steuerkomponenten bündig und
ausgerichtet in unterschiedlichen Anordnungen und Applikationsprofilen platziert werden
können.
173
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
5.3.2 Document-View-basierte GUI-Komponenten
Ein bekannter Ansatz zur Implementierung interaktiver Anwendungen ist das MVC-Muster
(Model-View-Controller). Hierbei wird der Programmcode zur Implementierung jeder
Oberflächenkomponente in drei logische Einheiten zerlegt, die jeweils in Form einer Klasse
implementiert werden:
1. Model enthält Kernfunktionalitäten und Daten.
2. View repräsentiert die grafische Darstellung an der Benutzungsoberfläche, über die
der Anwender die Informationen präsentiert bekommt.
3. Controller stellt Steuerelemente für die Bedieneingaben zur Verfügung und
repräsentiert somit zusammen mit dem View die grafische Benutzungsoberfläche.
Weiterhin reagiert der Controller auf Ereignisse des Hauptprogramms, wie z. B. die
Aufforderung, dass ein neuer Datensatz geladen werden soll.
Zur Sicherung der Konsistenz zwischen Daten und Benutzungsoberfläche gibt es einen
Benachrichtigungsmechanismus, welcher Aktionen und Änderungen von Daten zwischen
den einzelnen Klassen übermittelt. Dieser wird auch als change-propagation-mechanism
bezeichnet. Eine detaillierte Einführung in das MVC-Muster ist z. B. in [BMRS00] zu finden.
Da in modernen integrierten Softwareentwicklungsumgebungen grafische Editoren zum
Zusammenstellen der Benutzungsoberflächen Anwendung finden, und diese dem
Anwendungsentwickler sowohl Ereignisse als auch Eingabe- und Steuerelemente zur
Verfügung stellen, bietet sich bei der Verwendung dieser Entwicklungswerkzeuge das DVMuster (Document-View, siehe [BMRS00]) an. Hierbei wird auf die strikte Trennung
zwischen "View" und "Control" verzichtet.
Bei der Anwendung des DV-Musters können zwangsläufig Controls nicht mehr unabhängig
von den Elementen zur Repräsentation der Informationen ausgetauscht werden. Der
Austausch dieser Komponenten spielt aber meist nur bei der Portierung der Applikation von
einem Betriebssystem auf ein anderes eine Rolle. Da bei modernen Betriebssystemen aber
Oberfläche und Ereignissteuerung eng miteinander verknüpft sind und auf diese durch die
Programmierschnittstelle (API, Application Programming Interface) des Betriebssystems
zugegriffen wird, müssen bei einer Portierung sowohl "View" als auch "Control" überarbeitet
werden. Somit bietet hier in der Praxis das DV-Muster keinen Nachteil gegenüber dem
MVC-Muster. In dieser Arbeit wird der DV-Ansatz weiter verfolgt, da zur
Referenzimplementierung
mit
Microsoft
VisualStudio
2005
eine
integrierte
Softwareentwicklungsumgebung mit grafischem Editor zum Zusammenstellen der
Benutzungsoberfläche verwendet wurde.
Das Document dient zum Speichern logisch zusammengehörender Informationen, die unter
einem Namen zusammengefasst werden können. Beispiele hierfür sind "Patient",
"Untersuchung", "Produkt" oder "Krankenhausaufenthalt". Diese können auch in einer
Ableitungshierarchie von einem Basisobjekt ausgehend weiter verfeinert werden. Wie in
174
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Abb. 5.9 dargestellt, kann so z. B. eine Untersuchung (examination) existieren, von der
weitere spezielle Untersuchungen wie Herzkatheter (angiography) oder Ultraschall
(ultrasound), abgeleitet werden. Dabei werden in der Basisklasse alle die Daten abgebildet,
die alle Untersuchungstypen besitzen, wie z. B. durchführender Arzt (physician),
Untersuchungsraum (laboratory) oder Untersuchungsdatum (examination date). In den
Ableitungen werden die Daten hinzugefügt, die es nur in den speziellen Untersuchungen
gibt, wie z. B. arterielle Schleuse (arterial lock), Messwerte (z. B. LVEF in Prozent) oder
verwendeter Schallkopf (transducer).
In jedem "Document" werden insbesondere die Primärschlüssel (PID, ANR und DOKNR)
gespeichert. Zusätzlich verfügt ein Document über Methoden zur Kommunikation mit der
Datenquelle und zum Reagieren auf Ereignisse. Die abstrakte Klasse GSDoc gibt vor,
welche Methoden im Einzelnen durch abgeleitete Dokument-Klassen zu implementieren
sind:
•
CreateDocument: Diese Methode legt ein neues Dokument an und initialisiert
Parameter mit Standard-Werten. Sie sollte vom Konstruktor aufgerufen werden,
wenn ein neues Dokument angelegt wird. Weiterhin können hier Auswahllisten und
Dialoge aufgerufen werden, in denen interaktiv Datensätze ausgewählt werden, die
Einfluss auf den neu angelegten Datensatz haben. Ein Beispiel hierfür ist die
Neuanlage eines Patientendatensatzes. Hier wird der Anwender zunächst
aufgefordert nachzusehen, ob der gesuchte Patient nicht schon in der Datenbank
existiert. Wird dieser in der Liste der bereits erfassten Patienten nicht durch den
Anwender gefunden, werden Name und Geburtsdatum abgefragt und noch einmal
mit den Einträgen in der Datenbank verglichen, um sicher zu stellen, dass kein
Datensatz mit diesen oder sehr ähnlichen Daten existiert. Ist dies der Fall, werden
dem Anwender die gefundenen Patientendatensätze in einer Liste präsentiert und
gefragt, ob der gesuchte Patient in dieser Liste ist. Dieses Vorgehen ist notwendig,
da bei einer großen Klinik pro Jahr über 10.000 neue Patientendatensätze angelegt
werden. Dies kann zu großen Listen führen, in denen Namen mit nicht immer
eindeutiger Schreibweise, z. B. bei ausländischen Patienten, durch den Anwender
leicht übersehen werden können.
•
Store: Diese Methode dient zum Speichern der Daten in der Datenbank. Weiterhin
sorgt diese Methode für die Verwaltung der Primärschlüssel.
•
Reload: Diese Methode dient zum Laden eines Datensatzes aus der Datenquelle
und darf nur aufgerufen werden, wenn der Primärschlüssel für das Dokument gesetzt
ist. Nach dem Laden der Daten wird der zugehörige "View" benachrichtigt, dass
dieser sich aktualisieren muss.
•
ResetValues: Setzt alle Werte inkl. der Primärschlüssel zurück.
175
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Abb. 5.9: Ableitungshierarchie der "Documents" des DV-Musters in UML-Notation. Basis aller
"Documents" ist die abstrakte Klasse GSDoc.
Die von einem "Document" verwalteten Daten werden dem Anwender durch seinen
zugehörigen "View" präsentiert. In der Referenzimplementierung sind die einzelnen Daten in
den Klassen durch sog. Properties realisiert. Diese stellen innerhalb von C# den Zugriff auf
Member-Variablen dar. Soll in objektorientierten Sprachen wie C++ oder Java von außen
der Zugriff auf Variablen erlaubt sein, so werden diese als "public" oder "protected", wenn
der Zugriff nur in der Ableitungshierarchie erlaubt sein soll, definiert. Dies hat aber den
Nachteil, dass die Änderung unkontrolliert erfolgt, da die Manipulation von Variableninhalten
keinen weiteren Programmcode in der Klasse aktivieren kann. Somit kann z. B. keine
Wertebereichsprüfung durchgeführt werden.
Eine gängige Methode ist es daher, Variablen als "private" zu deklarieren und den Zugriff
von außen durch Methoden anderer Klassen mittels Get- und Set-Methoden zu
implementieren. Da dieses Vorgehen aber keinen Standards bzgl. der Benennung der
Methoden unterliegt, kann es zu unübersichtlichem Code führen. Das Konzept der
Properties soll dies beseitigen und stellt einen einheitlichen Mechanismus zum Zugriff auf
Membervariablen von außerhalb der eigenen Klasse zur Verfügung. Hierfür wird der Name
der Property definiert und der Zugriff auf Member-Variablen über Code, der durch die
Schlüsselwörter "get" und "set" eingeleitet wird, realisiert.
176
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Der folgende einfache Programmcode soll das Konzept veranschaulichen. In dem Beispiel
sollen Zugriffe auf eine Variable "MyInt" gezählt werden. Wird "MyInt" ein neuer Wert
zugewiesen, soll der Zähler auf 0 zurückgesetzt werden. Ein zugehöriger Programmcode in
Java mit Get- und Set-Methoden sieht z. B. so aus:
private int MyInt;
private int Accesses = 0;
// Zähler, am Anfang 0
// Gibt den Wert von MyInt zurück und erhöht den Zugriffszähler um 1
public int GetMyInt() {
Accesses++;
// Zugriffszähler um 1 erhöhen
return MyInt; // Wert zurückgeben
}
// Weist MyInt einen neuen Wert zu setzt den Zugriffszähler zurück
public void SetMyInt(int NewValue) {
Accesses = 0;
// Zugriffszähler zurücksetzen
MyInt = NewValue; // Wert zuweisen
}
In C# kann dies mit Properties so gelöst werden:
private int myInt;
private int Accesses = 0;
// Zähler, am Anfang 0
// Öffentlicher Zugriff auf MyInt mit Property MyInt
public int MyInt {
get {
Accesses++;
// Zugriffszähler um 1 erhöhen
return MyInt; // Wert zurückgeben
}
set {
Accesses = 0;
// Zugriffszähler zurücksetzen
MyInt = value; // Wert zuweisen
}
}
Auch beim Zugriff auf die Variablen von außerhalb der eigenen Klasse wird der
Programmcode übersichtlicher. Bei der Zuweisung muss keine Methode (SetMyInt(7);)
aufgerufen, sondern es kann direkt eine Wertzuweisung (MyInt = 7;) vorgenommen
werden. Die genaue Syntax der "C#-Properties" kann in einem der vielen verfügbaren
Bücher zu C# (z. B. [Hani02]) oder im Internet (vgl. [MSDN]) nachgeschlagen werden.
Das Konzept der Properties und die damit einhergehende Vereinheitlichung im Zugriff auf
Member-Variablen hat im Zusammenhang mit der Entwicklungsumgebung VisualStudio
noch weitere Vorteile, welche im folgenden Abschnitt eine vorgestellt werden.
177
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
5.3.3 Property-basierte GUI-Komponenten
Die in Abschnitt 5.3.2 vorgestellten "Properties" sind in die grafische Entwicklungsumgebung
von Microsofts VisualStudio vollständig integriert. Dies gilt auch für Properties, die durch den
Entwickler definiert sind. In Abb. 5.9 ist die konkrete Umsetzung abgebildet. Für jedes
Objekt, das im grafischen Editor markiert wird (1), werden sämtliche Properties in der sog.
"Property-Palette" am rechten Bildschirmrand angezeigt (2). Dort können ihnen direkt Werte
zugewiesen werden. Dies gilt auch für selbst definierte Properties (3). Die Wertzuweisungen
werden in Programmcode umgewandelt und dynamisch in Quellcode umgesetzt. Dieser
kann nachträglich mit einem Editor weiter bearbeitet werden. In dem Beispiel in Abb. 5.10
führt z. B. der Eintrag "K_MED_DATEN" hinter "Table" zu folgender Programmcodezeile:
this.HB.Table = "K_MED_DATEN";
2
1
3
Abb. 5.10: Integration von Properties in das VisualStudio. Für das im Layout-Editor ausgewählte
Objekt (1) können rechts den Properties (2) Werte zugewiesen werden. Dies gilt auch für
selbst definierte Properties (3).
Verfügt der "set"-Teil der Property über ausführbaren Programmcode, so wird dieser durch
das VisualStudio soweit möglich ausgeführt. Resultierten hieraus Auswirkungen auf die
grafische Darstellung, so werden diese sofort im grafischen Editor angezeigt. Ändert der
178
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Entwickler z. B. die Property für die Rahmenfarbe von Rot auf Schwarz, so wird der Rahmen
sofort in der neuen Farbe angezeigt.
Bei dem hier vorgestellten "property-basierten" verwaltet jedes Control sämtliche
Informationen, die zur Darstellung der gewünschten Informationen und zur Reaktion auf alle
Ereignisse notwendig sind, mit Hilfe eigener Properties. Dadurch kann zunächst auf die
Implementierung eines eigenen “Document“ pro “View“ verzichtet und die
Standardkomponenten mit dem grafischen Editor des VisualStudios erstellt werden. Die
daraus resultierenden Vorteile sind:
•
Schnellere Erstellung von Komponenten, da diese komplett mit dem grafischen
Editor ohne Implementierung von zusätzlichem Programmcode erstellt werden
können.
•
Weniger Fehlern entstehen beim Programmieren, da Änderungen am Layout schon
während der Implementierung angezeigt und überprüft werden können und weniger
Programmcode geschrieben werden muss.
•
Einheitliche Implementierung, die eine Pflege des Programmcodes und das
Entwickeln im Team vereinfacht.
Für die konkrete Umsetzung wurde im Projekt GO# zunächst das Containerobjekt GSView
implementiert. Dieses stellt eine rechteckige Fläche mit Rahmen zur Verfügung, die den
Bildschirmhintergrund der Komponente darstellt und im grafischen Editor von VisualStudio
angezeigt werden kann. In dem Beispiel in Abb. 5.9 ist dies die graue Fläche in der Mitte mit
dem Rahmen "Labordaten".
Danach wurde von jedem Control, welches Daten aufnimmt, eine abgeleitete Klasse implementiert (vgl. Tab. 5.1). Bei diesen Controls handelt es sich um Ableitungen der vom .NETFramework zur Verfügung gestellten Controls im Namespace System.Windows.Forms.
Namespaces sind Pakete innerhalb des .NET-Frameworks von Microsoft, welche
zusammengehörige Objekte und Programmierschnittstellen zur Verfügung stellen. Das
Paket System.Windows.Forms stellt die Basis zur Implementierung von grafischen
Benutzungsoberflächen zur Verfügung und enthält auch die Basisklassen für Controls.
Jede der in Tab. 5.1 aufgeführten Klassen implementiert das Interface GSGuiComponent
als einheitliche Schnittstelle zum Zugriff auf Properties und Methoden (vgl. Tab. 5.2) der
Controls.
Daneben besitzen die einzelnen Controls noch weitere, individuelle Properties z. B. für die
Definition der Inhalte von Listen bei Comboboxen oder für die Werte, die von Anhakfeldern
in an- bzw. abgehaktem Zustand angenommen werden.
Diese erweiterten Controls werden vom VisualStudio automatisch erkannt, im grafischen
Editor in der Toolbox (linke Seite in Abb. 5.9) angezeigt und können per drag & drop in das
Containerobjekt im Editor "gezogen" werden. Dort können diese dann ausgewählt und
sämtliche Einstellungen in der Property-Palette durchgeführt werden. Nachdem jedem
179
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Objekt alle notwendigen Informationen wie z. B. Farbschema, Attribut und Tabelle
zugewiesen sind, kann dieses selbständig auf eingehende Ereignisse reagieren, die
gewünschten Daten anzeigen, manipulieren und speichern.
Klasse
Abgeleitet von
Beschreibung
GSTextBox
TextBox
Eingabefeld für Texte und Zahlen
GSComboBox
ComboBox
Comboboxen und Poplisten
GSCheckBox
CheckBox
Anhakfelder
GSRadioButtonGroup
UserControl
Radiobutton, die in
zusammengefasst sind
GSDateTimePicker
DateTimePicker
Datum- und Zeitfelder
GSTable
DataGridView
Tabellen; deren Spalten basieren wiederum auf
eigenen Implementierungen von Tabellenspalten für
Texteingabefelder, Comboboxen, Anhakfeldern und
Datum-/Zeitfeldern
Tab. 5.1:
einer
eigenen
Gruppe
Klassen für Oberflächenelemente zur Datenerfassung als Ableitungen der vom .NETFramework
zur Verfügung gestellten Oberflächenelemente im
Namespace
System.Windows.Forms.
Der Lade- und Speichervorgang von Daten aus der Datenquelle wird im Folgenden näher
erläutert. In Abb. 5.11 ist der Datenaustausch von der Initialisierung der Komponenten bis
zum Abschluss des Ladevorgangs grafisch dargestellt.
Property
Beschreibung
Table
Name der Tabelle in der Datenbank auf der die Daten, die von der Control
angezeigt werden, basieren
Attribute
Name des Attributes in der Tabelle "Table" in der Datenbank auf der die Daten,
die von der Control angezeigt werden, basieren
ValueDBString
Standardisierte Darstellung der Daten. Zahlen werden immer als
Zeichenketten mit Punkt als Dezimaltrenner und Zeiten in der ISO-Notation
YYYYMMDDHHMISS (JahrMonatTagStundeMinuteSekunde) übergeben. Von
den einzelnen Oberflächenelementen werden sie dann dem Anwender
entsprechend der eingestellten Sprache geeignet präsentiert
AlwaysDisabled
Ist diese Property gesetzt, also "true", so ist das Feld immer deaktiviert. Es
handelt sich dann um ein reines Anzeigefeld.
Methode
Beschreibung
LoadData
Methode zum Laden des Feldinhaltes. Der Primärschlüssel wird als Parameter
übergeben.
GSInitialize
Code zum Initialisieren des Controls
ClearValue
Setzt den Wert des Controls zurück
Tab. 5.2:
180
Properties und
implementieren
Methoden
von
Controls,
die
das
Interface
GSGuiComponent
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Beim Start der Applikation werden zunächst alle Komponenten, die vom Typ GSView sein
müssen, instanziiert. Jede Komponente sorgt dafür, dass alle innerhalb der Komponente
definierten Controls instanziiert, leer (kein Inhalt) und inaktiv sind. Die Inaktivität resultiert
daraus, dass direkt nach dem Programmstart noch kein Datensatz geladen ist und somit
nichts dargestellt oder erfasst werden kann.
Wählt der Anwender mit Hilfe einer Steuerkomponente einen Datensatz aus, so werden die
Primärschlüssel durch Versenden des Ereignisses "PK geändert" an alle Komponenten
geschickt. Diese leiten den Primärschlüssel an alle in ihnen enthaltene Controls weiter.
Sämtliche Komponenten und Controls werden dabei nacheinander abgearbeitet. Dadurch
können keine Deadlocks oder nichtdeterministischen Zustände durch konkurrierenden
Zugriff entstehen. Die Abarbeitungsreihenfolge spielt auch keine Rolle, da weder
Komponenten noch Controls voneinander abhängig sind. Es muss einzig darauf geachtet
werden, dass jede Komponente benachrichtigt wird, um sicherzustellen, dass alle von dem
Primärschlüssel abhängigen Daten geladen und dem Anwender zur Betrachtung und
Bearbeitung zur Verfügung stehen.
Folgender Algorithmus, für den später noch eine Verbesserung bzgl. der Anzahl der
Datenbankzugriffe vorgestellt wird, findet beim Laden der Komponenteninhalte Anwendung:
1. Der GSView ermittelt die erste Control, die das Interface GSGuiComponent
implementiert und auf einem Attribut aus der Datenbank basiert. Diese wird die
CurrentControl.
2. Die CurrentControl bestimmt den für sie relevanten Primärschlüssel. Dieser wird dem
Datadictionary der Datenbank entnommen und kann immer bestimmt werden, da
jeder Control, die auf Daten aus der Datenbank basiert, der Name der jeweiligen
Basistabelle bekannt sein muss.
3. Ist der Primärschlüssel nicht für die CurrentControl relevant, wird der Ladestatus
"false" zurückgegeben und zu Schritt 8 gesprungen. Im anderen Fall wird mit der
Aktualisierung des Feldinhaltes und Schritt 4 fortgefahren.
4. Der neue Primärschlüssel wird lokal von der CurrentControl gespeichert, da dieser
für das Speichern von manipulierten Feldinhalten benötigt wird.
5. Dem zugehörigen GSView wird von der CurrentControl eine Ladeanforderung an die
Datenquelle mitgeteilt. Diese Anforderung enthält als Übergabeparameter den
aktuellen Wert des Primärschlüssels, die Tabelle und das angeforderte Attribut.
6. Der GSView reicht die Anfrage an den Kommunikationsbus, der durch den
Initializer gestellt wird, weiter und gibt das Ergebnis an die anfordernde
CurrentControl zurück.
7. Die CurrentControl speichert das Ergebnis intern, stellt es grafisch dar, aktiviert sich
(soweit es sich nicht um ein reines Anzeigefeld handelt) und gibt den Ladestatus
"true" zurück.
181
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
8. Der GSView bestimmt die nächste, noch nicht benachrichtigte Control. Diese wird
die CurrentControl. Wurden alle Controls benachrichtigt, so wird mit Schritt 9
fortgefahren, sonst mit Schritt 2.
9. Der GSView teilt dem Initializer den Ladestatus "true" mit, wenn mindestens
eine ihrer Controls den Ladestatus "true" zurückgeliefert hat, sonst "false".
Anhand des zurück gelieferten Ladestatus entscheidet der Initializer, ob ein Fenster
angezeigt werden soll. Dies ist genau dann der Fall, wenn mindestens eine im Fenster
enthaltene Komponente "true" geliefert hat. Sonst wird das Fenster ausgeblendet, da es nur
Komponenten enthält, die nichts mit dem ausgewählten Datensatz zu tun haben.
Abb. 5.11: Nachrichtenaustausch beim Ladevorgang
182
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Der Speichervorgang wird direkt von den Controls ausgelöst. Sobald der Anwender einen
Feldinhalt verändert hat und die Eingabemarke ein Control verlässt, werden von diesem
Control die geänderten Daten zusammen mit dem Primärschlüssel, welcher zuvor im
Rahmen des Ladevorgangs in der Control abgelegt wurde, an den Kommunikationsbus
versendet. Dieser synchronisiert die Daten mit der Datenbank und versendet eine
Änderungsmeldung per Notify an alle anderen Komponenten, damit diese ggf. auf die
geänderten Daten reagieren können. Dies ist z. B. beim Alter der Fall, wenn das
Untersuchungsdatum in der Komponente der Untersuchungsdaten geändert wird. Da das
Alter vom Geburtsdatum abhängig ist, welches sich in einer anderen Komponente mit den
Patientenstammdaten befindet, und ein direkter Zugriff auf Inhalte anderer Komponenten
nicht erlaubt ist, muss das Geburtsdatum über den Kommunikationsbus angefordert werden.
Analog erfolgt die Kommunikation bei anderen Ereignissen. Derzeit sind in der GO#Architektur folgende Ereignisse implementiert:
•
Letzte Aktion rückgängig machen
•
Benachrichtigung über die Änderung von Feldinhalten
•
Anforderung von Feldinhalten
•
Versenden von Ereignissen mit selbst definierter Bezeichnung, z. B. die
Aufforderungen "Abrechnung generieren" oder "Datensatz ist digital signiert".
Ersteres führt bei allen Komponenten, die Abrechnungsinformationen verwalten,
dazu, dass diese nachsehen, welche ICD-, OPS- und XDT-Ziffern auf Grund der
erfassten medizinischen Informationen relevant sind. Letzteres deaktiviert sämtliche
Controls und schützt somit Datensätze nach dem Abschluss der Dokumentation vor
weiterer Manipulation.
Den bereits genannten Vorteilen der property-basierten GUI-Komponenten stehen zwei
Nachteile gegenüber. Erstens wird jeder Inhalt jeder einzelnen Control mit einer separaten
Anfrage aus der Datenbank ausgelesen. Es können nicht mehrere Attribute mit einer
einzigen Anforderung in einem SELECT-Kommando zusammengefasst und von der
Datenbank übermittelt werden. Dies ist ein Nachteil bei der Abarbeitung von Ladevorgängen
durch die Applikation. Zweitens befinden sich Daten, Kontrolllogik und Visualisierung in einer
Klasse. Dies könnte als nachteilig bei einer Portierung oder bei Änderungen, die aus
Modifikationen des Datenschemas resultieren, angesehen werden.
Der erste Nachteil kann durch eine kleine Veränderung bei den Datenbankzugriffen
behoben werden. Da die gesamte Kommunikation beim Ladevorgang durch den GSView,
der die Controls enthält, abgehandelt wird, kann dieser zunächst alle Anfragen an die
Datenquelle sammeln. Diese Anfragen werden nach Tabellen zusammengefasst und
sämtliche Attribute einer Tabelle in einer Anfrage gelesen. Wenn alle Anfragen an die
Datenbank abgearbeitet wurden, wird das Ergebnis an die einzelnen Controls weitergereicht
und die Daten von diesen an der Benutzungsoberfläche angezeigt. Tests mit dem
183
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
implementierten Prototyp ergaben, dass durch die Zusammenfassung der Anfragen die
Ladezeit um ca. 30 % verkürzt werden konnte.
Der zweite Nachteil kommt bei der Verwendung von C# nur bedingt zum Tragen. In C# gibt
es die Möglichkeit, den Quellcode von Klassen auf mehrere Dateien zu verteilen. Dies wird
bei der Definition der Klassen durch Verwendung der Deklaration als partial class
bewirkt. Die Entwicklungsumgebung VisualStudio legt in einer Datei sämtliche Informationen
zur GUI ab und den vom Softwareentwickler geschriebenen Programmcode in einer
anderen Datei. Dies entspricht gerade dem Aufbau des DV-Musters und ermöglicht die
alleinige Modifikation des Programmcodes für die Benutzungsoberfläche. Dies wird z. B.
auch bei der Internationalisierung von Benutzungsoberflächen angewendet, da hier nur das
Erscheinungsbild der Oberfläche an die gewünschte Sprache angepasst wird und nicht die
interne Datenhaltung oder Programmlogik verändert werden. Die Entwicklungsumgebung
sorgt dafür, dass die einzelnen Teile der Klasse als eine Einheit repräsentiert werden, die
vom Anwendungsentwickler komfortabel erstellt und bearbeitet werden kann.
Es stellt sich zusätzlich die grundsätzliche Frage, ob eine Modifikation des Programmcodes
bei einem Plattformwechsel überhaupt nötig ist. Derzeit existiert neben der Implementierung
von C# und .NET für Windows nur eine weitere Implementierung mit dem Namen Mono (vgl.
[MONO]). Tests mit dem Prototypen zeigten, dass sich der Quellcode ohne Modifikation mit
Mono compilieren lies. Hierfür und für die korrekte Darstellung der Benutzungsoberfläche
mussten lediglich Konfigurationsparameter von Mono angepasst und das zu Grunde
liegende Linux korrekt konfiguriert werden.
Hervorgehoben werden muss jedoch die Tatsache, dass der property-basierte Ansatz die
genannten Vorteile nur unter Verwendung einer integrierten Entwicklungsumgebung wie
dem VisualStudio bieten kann, welche auf die Programmiersprache C# zugeschnitten
wurde. Insbesondere die Unterstützung eines grafischen Editors zur Verwaltung der
Properties und die transparente Darstellung geteilter Klassen (partial class) bieten für
den Anwendungsentwickler eine erhebliche Erleichterung bei der Softwareentwicklung und
Wartung des Programmcodes.
5.3.4 Hintergrundkomponenten
Diese Komponenten stellen Funktionalitäten zur Verfügung, die ohne direkte Interaktion mit
dem Benutzer stattfinden. Dies sind z. B. Schnittstellen zu medizinischen Geräten oder
anderen Informationssystemen oder Komponenten zur automatischen Befundgenerierung.
Zur Datenhaltung verwenden diese Komponenten ein “Document“, welches dem DocumentView-Konzept (vgl. Abschnitt 5.3.2) entspricht. Dieses wird ebenfalls von der Klasse GSDoc
abgeleitet. Dadurch kann die Hintergrundkomponente auf den Initializer und den
zentralen Kommunikationsbus zugreifen.
184
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Die Programmlogik wird in einer eigenen Klasse implementiert und kann beliebigen Code
ausführen. Dies kann auch in einem eigenen Thread, unabhängig vom Hauptprogramm,
geschehen. So kann z. B. eine Komponente zum Importieren von Daten, die über BDTDateien ausgetauscht werden, regelmäßig ein Verzeichnis auf den Eingang von neuen BDTDateien überprüfen. Wird dort eine neue Nachricht abgelegt, so wird diese parallel zur
laufenden Hauptapplikation im Hintergrund verarbeitet. Nach erfolgreicher Verarbeitung des
Dateiinhalts wird eine Nachricht über die eingegangenen Informationen über den
Informationsbus verteilt.
Über den Initializer kann die Hintergrundkomponente Nachrichten an alle anderen
Komponenten versenden. Dies geschieht nach demselben Mechanismus, wie er bereits für
GUI-Komponenten beschrieben wurde. Ob und wie diese darauf reagieren, bleibt der
Implementierung der übrigen Komponenten überlassen.
5.4 Umsetzung des MSF-Konzepts
Für die Umsetzung des in Kapitel 4 erarbeiteten Konzepts des MSF müssen an das Design
der Applikation für die medizinische Dokumentation gewisse Anforderungen gestellt werden.
Grundsätzlich sind dies:
•
Bereitstellung des passenden Dokumentationsdatensatzes und Modifikation des PS
für einen Patienten, sobald dieser einen MSP erreicht,
•
Gewährleistung der Erfassung aller für die durch einen MSP erbringbaren
Leistungen relevanten Daten,
•
Modifikation des PS, sobald dieser den MSP verlässt bzw. bei Abschluss der
Dokumentation.
Dies betrifft folgende Bereiche der Komponenten der Software-Architektur:
•
Funktionsumfang der Startkomponenten, die zur Auswahl von Datensätzen
angewendet werden,
•
Zusammenstellung der Komponenten, die zur Dokumentation innerhalb eines MSP
verwendet werden,
•
Definition spezieller Funktionalitäten, die Komponenten zum Abschluss der
Dokumentation bereitstellen müssen.
Da die Auswahl der Datensätze stets durch eine Startkomponente erfolgt, muss jede
Applikation, die für einen MSP zusammengestellt wird, über mindestens eine
Startkomponente verfügen. Wird in der Liste dieser Komponente eine Zeile gewählt, so
müssen alle GUI-Komponenten, die zur medizinischen Dokumentation verwendet werden
185
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
können, von den Primärschlüsseln, die die Startkomponente verwaltet, abhängig sein. Es
dürfen also z. B. in einer Applikation zur Befundung von Herzkathetern keine Komponenten,
die ausschließlich Daten einer MR-Untersuchung enthalten, erscheinen, da letztere niemals
einen sinnvollen Inhalt im Rahmen der Dokumentation des Herzkatheters enthalten können.
Eine Applikation, die Anwendung innerhalb eines MSPs findet, darf also nur eine Teilmenge
der Daten folgender Datenschemata enthalten:
•
Patientendatenschema (PD)
•
Anamnestisches Datenschema (AD)
•
Datenschemata zur Dokumentation der medizinischen Leistung die durch den MSP
erbracht werden können (LDi mit i = 1 ... n und n ∈ IN).
Es muss also für eine Applikation A, die zur Dokumentation innerhalb eines MSPs
verwendet werden soll, gelten:
AM ⊆ APD ∪ AAD ∪ ALDi
und
AM ⊄ {ALD1 ∪ ALD2 ∪ … ∪ ALDn} \ ALDi
mit AM ist die Menge der durch A dokumentierbaren Attribute, APD ist die Menge aller
Attribute von PD, AAD ist die Menge aller Attribute von AD, ALDi ist die Menge aller
Attribute, die im Rahmen der medizinischen Dokumentation aller durch A erbringbaren
Leistungen relevant sind, ALD1, ALD2, …, ALDn sind die Attribute aller übrigen
Leistungsdatenschemata.
Bezüglich nicht-medizinischer Inhalte kann diese Regel in der Praxis relaxiert werden. Es
wäre z. B. eine Komponente zur Verwaltung von Lagerbeständen in der AnwendungsSoftware für den Arbeitsplatz des Pflegepersonals im HK-Labor denkbar. Dies liegt daran,
dass in dringlichen Fällen spezielle Materialien, die von anderen Abteilungen oder externen
Firmen kurzfristig zur Verfügung gestellt werden, direkt im HK-Labor ohne den Umweg über
das Lager verwendet werden. Diese können dann vom Personal angelegt und abgebucht
werden, ohne eine zusätzliche Applikation starten zu müssen. Darüber hinaus darf jede
Applikation Optionen verwalten, die nicht zu den medizinischen Informationen gehören.
Weiterhin muss die Startkomponente die richtigen Datensätze im Sinne des MSP, in dem
sie eingesetzt wird, anzeigen. Dazu muss die Anweisung, die zur Selektion der Datensätze,
die in den Auswahllisten angezeigt werden, folgende Bedingungen erfüllen:
•
Der Patient muss sich im Krankenhaus aufhalten. Das entspricht gerade all den
Patienten, deren PS existiert und deren aktueller Aufenthaltsort kein EP ist.
•
Der Patient muss für eine Therapie eingeplant sein, die der MSP durchführen kann.
Dies entspricht gerade all den Patienten, deren PS in der Menge G der geplanten
Therapien mindestens eine Therapie enthält, die vom MSP durchgeführt werden
kann.
Nach Auswahl eines Datensatzes muss die Startkomponente den PS insofern modifizieren,
als die Therapie, die zur Behandlung im MSP führte, aus der Menge G der geplanten
186
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Therapien entfernt und K, dem aktuellen Aufenthaltsort und dem Datum des dortigen
Eintreffens, das Tupel (Bezeichnung des MSP, aktuelle Uhrzeit) zugewiesen wird.
Eine Startkomponente, die diesen Anforderungen bzgl. eines MSP gerecht wird, soll im
Folgenden als MSP-konforme Startkomponente bzgl. eines MSP bezeichnet werden.
Die Komponenten zur Dokumentation der medizinischen Inhalte müssen individuell für jede
Abteilung implementiert werden. Bei der Entwicklung muss auf Rahmenbedingungen
geachtet werden, von denen hier einige genannt sind:
•
Sämtliche Inhalte in einer Komponente sollen logisch zusammengehören. Diese
Zusammengehörigkeit soll in der Benutzungsoberfläche durch einen Rahmen, der
zusammengehörige Controls einschließt, visuell hervorgehoben werden.
•
Eine Komponente soll nicht zu viele, aber auch nicht zu wenig Felder beinhalten. Ein
guter Wert aufgrund ergonomischer Erfahrungen, die im Projekt GO-Kard gesammelt
wurden, sind fünf bis fünfzehn Controls.
•
Inhalte, die allgemein für unterschiedliche medizinische Eingriffe zur Dokumentation
verwendet werden können, sollen von Informationen, die untersuchungsspezifisch
sind, getrennt werden. Dies bedeutet, dass Controls, die auf Attributen
unterschiedlicher Teildatenschemata basieren möglichst auch auf unterschiedlichen
Fenstern platziert werden.
•
Eingabefelder sollen so angelegt werden, dass möglichst der gesamte Inhalt
eingesehen werden kann. Prompts und Labels sollen genug Platz an der Oberfläche
haben. Abkürzungen sollen bei Prompts, Labeln und Eingabefeldern vermieden
werden.
•
Felder, Prompts und Labels sollen im Layout untereinander bündig und übersichtlich
ausgerichtet werden.
•
Die rechteckige Grundfläche jeder Komponenten muss einer Rastergröße
entsprechen. Dabei ist die Rastergröße so zu wählen, dass noch Platz zur Aufnahme
von weiteren Controls möglich ist. Dieser sollte eine problemlose Erweiterung um
weitere Controls ermöglichen. Im Projekt GO-Kard zeigte sich, dass hier Platz für die
Aufnahme von weiteren 15 % der ursprünglich angeordneten Controls ein guter Wert
ist.
In Abb. 5.12 ist die Bildschirmmaske mit den Patientenstammdaten des ersten Prototyps der
Assistenz-Software von GO-Kard als Beispiel für die Verteilung von Komponenten
dargestellt. Da die einzelnen Komponenten gewissen Rastergrößen entsprechen und
voneinander unabhängig sind, können sie in beliebiger Zusammenstellung auf dem
Bildschirm angeordnet werden. Es können auch Profile für andere Bildschirmauflösung
erstellt werden, auf denen mehr oder weniger Komponenten angeordnet sind.
187
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Abb. 5.12: Bildschirmmaske mit Patientenstammdaten des ersten Prototyps der Assistenz-Software
von GO# als Beispiel für die Verteilung von Komponenten
Mindestens eine der Komponenten, die möglichst auf der letzten Seite platziert werden
sollte, muss eine Möglichkeit bieten den aufgerufenen Datensatz zu schließen. Dazu bietet
sich eine Schaltfläche an. Nachdem diese vom Anwender aktiviert wurde, werden folgende
Aktionen durch die Komponente initiiert:
•
Über den Kommunikationsbus wird allen Komponenten mitgeteilt, dass der
Datensatz geschlossen wird. Diese führen ggf. notwendig Aktionen durch, z. B. das
Versenden von Nachrichten an angeschlossene Subsysteme, und Löschen den
Inhalt aller Felder. Ein Speichern ist nicht notwendig, da alle Inhalte bereits mit der
Datenbank synchronisiert sind, da das Speichern sofort nach der Änderung eines
Feldinhaltes geschieht (vgl. Abschnitt 5.3).
•
Der PS wird modifiziert. Dies beinhaltet die Erweiterung der Menge G der geplanten
Therapien um die Eingriffe, die nach der Einschätzung des verantwortlichen Arztes
als nächstes durchgeführt werden sollen. Weiterhin wird O, die Menge der Aktionen,
die durchgeführt werden müssen, soweit notwendig aktualisiert. Dies beinhaltet
Anweisungen, wie z. B. "Druckverband nach sechs Stunden entfernen", an die
nachgeschalteten MSPs oder allgemeine Tätigkeiten wie z. B. "Entlassungsbrief
schreiben". Zu beachten ist, dass K, der aktuelle Aufenthaltsort nicht verändert wird.
Dies geschieht erst durch den MSP, zu dem der Patient als nächstes gebracht wird.
188
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Einzige Ausnahme bildet ein Entlassungspunkt. Dieser muss K das Tupel
("Entlassen", aktuelles Datum) zuweisen.
•
Die Rahmenapplikation schließt bis auf die Startseiten alle Fenster, entfernt nicht
länger benötigte Canvases (Reiter) und bringt das erste Startfenster in den
Vordergrund.
Anschließend kann der Anwender erneut einen Datensatze auswählen und der Ablauf
beginnt von vorne.
5.5 Erweiterungsmöglichkeiten
Die in diesem Abschnitt vorgestellten Erweiterungsmöglichkeiten betreffen Aktionen, die bei
einer Umstrukturierung oder Erweiterung der medizinischen Abteilung notwendig sind. Das
Vorgehen zur Erweiterung des zu Grunde liegenden formalen Modells wurde bereits in
Abschnitt 4.9 bei der Erweiterung des endlichen Automaten vorgestellt.
MSP-konforme Software, die in einem MSP im praktischen Einsatz ist, besitzt eine
eindeutige Konfiguration. In der hier vorgestellten Architektur besteht diese Konfiguration
aus einer Anzahl von Startkomponenten, nachgeschalteten GUI-Komponenten und
Hintergrundkomponenten. Modifikationen der gesamten Applikation, also Änderungen in der
Zusammenstellung der Komponenten, sind insbesondere in folgenden Fällen notwendig:
1. Anwendung neuer medizinischer Maßnahmen durch den MSP
2. Änderung der vom MSP behandelbaren Krankheitsbilder, z. B. durch neue
Erkenntnisse aus der medizinischen Forschung oder veränderte Arbeitsabläufe in
der Abteilung
3. Erweiterung der Abteilung um neue MSPs.
Im ersten Fall müssen neue Komponenten oder Erweiterungen existierender Komponenten
implementiert werden. Der hierfür notwendige Programmieraufwand kann nicht vollständig
umgangen werden, da prospektiv und spekulativ keine Implementierung von Funktionalität
durchgeführt werden kann. Die Software-Architektur stellt in den Basisklassen viele
Funktionen, die allgemein genutzt werden können und so den bei der Entwicklung neuer
Komponenten hilfreich sind, zur Verfügung. In der GO#-Architektur werden hierfür unter
anderen Klassen und Methoden für folgende Aufgaben bereitgestellt:
•
Rückgängig-machen und Wiederherstellen von beliebig vielen Anwendereingaben
•
Thread-Management zum Ausführen von Hintergrundaktivitäten
•
Verwaltung von Farbschemata und Schriftsätzen für das Erscheinungsbild von
Controls
189
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
•
Erstellung von Standardkomponenten durch den grafischen Editor (vgl. Abschnitt
5.3)
•
Sperren von Datensätzen, die vom Arzt mit Hilfe eines Passworts nach Abschluss
der Dokumentation gegen Veränderungen geschützt wurden
•
Verwaltung von Optionen
•
Anbindung von Menüs und Objekten in der Toolbar
•
Verwaltung von Regeln zur Überprüfung von Anwendereingaben auf Konsistenz,
insbesondere zum Umsetzen von Regeln der BQS (sowohl für die Einhaltung von
Wertebereichen, als auch komplexerer Sachverhalten, die mit Hilfe boolescher
Ausdrücke definiert werden können).
Hierdurch kann der Aufwand zur Implementierung von Erweiterungen deutlich verringert
werden. Zeitmessungen während der Implementierungsphase ergaben, dass eine
Komponente, bestehend aus ca. zehn Feldern oder einer Tabelle, in weniger als einer
Stunde erstellt und in eine bestehende Konfiguration eingebunden werden kann.
Der zweite Grund für die Anpassung der Software betrifft die Steuerkomponenten. Ändert
sich der Behandlungsstandard, so können sich dadurch auch das Kriterium für die
Patientenauswahl im MSP oder die Vorschläge für die weitere Behandlung ändern. Im Sinne
des endlichen Automaten führt dies zu Änderungen in der Übergangstabelle.
Für die softwareseitige Umsetzung werden entweder die den Auswahllisten zu Grunde
liegenden Auswahlkriterien modifiziert oder die Einträge für die geplante weitere Behandlung
im PS mit anderen Werten belegt. Da die Auswahllisten in den Steuerkomponenten auf
SQL-SELECT-Anweisungen basieren, müssen die Auswahlbedingungen (WHERE-Teil) der
Anweisungen, die den Listen zugeordnet sind, angepasst werden. Dies ist durch den
Softwareentwickler leicht möglich, zurzeit aber nicht vom Anwender durchführbar, da die
SELECT-Anweisungen fest im Programmcode stehen und zur Compilezeit bekannt sein
müssen. Hier ist jedoch eine Erweiterung für die nächste GO#-Version geplant, welche es
erlaubt, den Listen SQL-Kommandos zuzuordnen, die während der Laufzeit dynamisch
geladen werden.
Die Schwierigkeit liegt hier weniger im dynamischen Laden von SQL-SELECTAnweisungen, sondern in der Bereitstellung eines Werkzeuges mit dem auch der
medizinische Anwender in der Lage ist, korrekte SELECT-Anweisungen zu erzeugen.
Dieses Werkzeug sollte insbesondere in der Lage sein, dem Anwender eine medizinische
Sicht auf den PS und die verfügbaren Indikationen zu geben. Join-Bedingungen, boolesche
Operatoren, Abkürzungen, etc. sollten gekapselt werden, um auch Anwendern, die über kein
datenbankspezifisches Know-how verfügen, das Erstellen von Auswahlbedingungen für
Listen zu ermöglichen. Hier muss noch ein schlüssiges Konzept entworfen und umgesetzt
werden. Anregungen für ein solches Werkzeug kann bei bereits existierenden Produkten wie
z. B. dem SELECT-Builder von ORACLE Reports (vgl. [Ora99a]) gefunden werden. Bis zur
190
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Integration eines solchen Werkzeugs bleibt es den Entwicklern vorbehalten, die Wünsche
der Anwender in korrekten Programmcode umzusetzen.
Für Standardinstallationen, bei denen der Kunde über wenig Know-how bzgl. Datenbanken
und der Selektion von Datensätzen verfügt, ist dies nicht von Nachteil. Hier überlässt der
Kunde dem Softwareentwickler die Aufgabe von Wartung und Anpassung. In Kliniken, die
über eine eigene EDV-Abteilung verfügen, entsteht aber häufig der Wunsch, Anpassungen
selbst durchführen zu können, da dies zumeist schneller durchführbar ist und mehr
Spielraum für das Ausprobieren und Optimieren von Konfigurationen lässt. Erfahrungen aus
dem Projekt GO-Kard haben dies insbesondere bei großen Krankenhäusern und
Universitätskliniken gezeigt.
Änderungen bei der geplanten weiteren Behandlung bedürfen im besten Fall gar keiner
Änderung der Software. Da die Software nur Vorschläge unterbreitet und es am Ende immer
die Entscheidung des verantwortlichen Arztes ist, welche medizinische Maßnahme als
nächstes bei einem Patienten angewendet werden sollte, kann es sein, dass der Arzt nur die
Auswahl der zur Verfügung stehenden weiteren Behandlungsvorschlägen ändern muss.
Damit dies ohne Änderung der Software möglich ist, verfügt die GO#-Architektur über eine
dreistufige grafische Präsentation von Auswahlmöglichkeiten (vgl. Abb. 5.13).
Für die Auswahl und Dokumentation von medizinischen Sachverhalten bei denen mehrere
wohl definierte Möglichkeiten zur Auswahl stehen (z. B. bei der Indikation, bei
intraprozeduralen Komplikationen, der Therapieempfehlung oder dem Procedere), werden
die vom Anwender am häufigsten genutzten Möglichkeiten werden in Form von
Anhakfeldern dargestellt. Das Anhaken einer Control mit einem einzigen Mausklick stellt aus
Anwendersicht eine sehr schnelle und einfache Art zur Erfassung eines Sachverhalts dar.
Erfahrungen aus dem Projekt GO-Kard haben gezeigt, dass ca. zehn Anhakfelder zur
Verfügung gestellt werden und weitere, häufig vorkommende Auswahlmöglichkeiten in
Feldern mit Pop-Listen angeboten werden sollten. Die Inhalte der Listen können vom
Anwender jederzeit zur Laufzeit modifiziert und erweitert werden. Die Modifikation der
Listeninhalte wird durch ein Passwort vor unbefugtem Zugriff geschützt. Schließlich kann in
einem Freitextfeld beliebiger Text eingegeben werden. Dieser Freitext stellt die
größtmögliche Flexibilität dar, benötigt aber auch bei der Dokumentation die meiste Zeit.
Abb. 5.13: Dreistufiges Verfahren zur Auswahl der Komplikationen in GO-Kard mit Anhakfeldern,
Auswahllisten und Freitext
191
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Änderungen am Programmcode sind somit nur dann notwendig, wenn die Anhakfelder
angepasst werden müssen, da die Inhalte der Listen nicht fest im Programmcode hinterlegt
sind.
Wird die Abteilung um einen komplett neuen MSP erweitert, so müssen Erfassungsmasken
zur Dokumentation innerhalb dieses MSP neu zu entworfen werden. Durch den modularen
Aufbau können jedoch bereits existierende Komponenten wiederverwendet werden. Dies
betrifft insbesondere allgemeingültige GUI-Komponenten zur Erfassung von Patientenstammdaten, Anamnese, Risikofaktoren, Untersuchungsbasisdaten oder medizinischen
Basisdaten.
Die Integration der neuen Abteilung in den MSF kann dann ohne Implementierungsaufwand
erfolgen:
•
Der Liste der Namen der verfügbaren MSPs wird der Name des neuen MSP
hinzugefügt. (Dies entspricht dem Hinzufügen des neuen Zustand Zneu aus Abschnitt
4.7).
•
Den Auswahllisten für das weitere Vorgehen werden alle Behandlungsmethoden des
neuen MSPs hinzugefügt. Dadurch können die neuen Behandlungsmethoden dem
PS als weiteres geplantes Vorgehen durch Auswahl einer dieser neuen Methoden
mitgeteilt werden. (Dies entspricht dem Hinzufügen der Übergänge aus Abschnitt
4.7)
In der Praxis kann jedoch ein gewisser Implementierungsaufwand stattfinden um andere
Eingabemechanismen, wie z. B. Radiobuttons oder Anhakfelder, statt der Auswahllisten, zu
ermöglichen oder um dem Anwender eine der neuen Behandlungsmethoden, basierend auf
den Daten, die bereits erfasst wurden, automatisch am Ende der Dokumentation
vorzuschlagen.
Zusammenfassend bleibt festzuhalten, dass die Architektur nicht nur dem Anwender die
Möglichkeit einer weit reichenden Anpassbarkeit an seine individuellen Ansprüche gibt,
sondern auch auf möglichst geringen Programmieraufwand bei der Erweiterung ausgerichtet
ist.
192
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
5.6 GO# - Eine Implementierung des MSF-Modells
Im letzten Abschnitt dieses Kapitels wird auf die Implementierung von GO# und Erfahrungen
mit dem bereits entwickelten Prototypen eingegangen. Dies geschieht sowohl aus Sicht der
beteiligten Softwareentwickler als auch aus Sicht der Anwender in der Klinik.
5.6.1 Betrachtung von GO# aus Sicht der Entwickler
Aktiv an der Entwicklung GO# sind, neben dem Autor, vier Mitarbeiter des Instituts OFFIS
beteiligt. Diese verfügen zusammen über einen breiten Hintergrund an Erfahrungen mit
anderen Programmiersprachen, wie Java, C++ und PL/SQL, und Entwicklungsumgebungen,
unter anderen Borlands J-Builder, ORACLE Forms, VisualStudio 6 und CodeWarrior.
Vor der Implementierung der GO#-Architektur verfügte keiner der beteiligten Entwickler über
Erfahrung mit .NET oder C#, welche seit dem Jahr 2003 verfügbar sind. Die Entscheidung
für VisualStudio 2005 wurde aus mehreren Gründen gefällt, wobei die wichtigsten waren:
•
Bei C# handelt es sich um eine "moderne" Programmiersprache, die für einen
breiten Einsatz entworfen wurde. Das strikte objektorientierte Design, welches in
einigen Bereichen, z. B. bei der Behandlung von Basisdatentypen wie int oder
char als Objekte, konsequenter als beim Entwurf von Java umgesetzt wurde, konnte
hier ebenso wie die Umsetzung bereits etablierter und bewährter Techniken (z. B.
Garbage-Collector oder Reflection) überzeugen.
•
Mit .NET liegt eine sehr umfangreiche Klassenbibliothek vor, die in Windows gut
integriert ist. Dies ist insofern verständlich, da beide Produkte demselben Hersteller
stammen.
•
Bei VisualStudio 2005 als Nachfolger der Version 2003 konnte davon ausgegangen
werden, dass Probleme und Fehler der ersten Version beseitigt und Verbesserungen
auf Grund des breiten, weltweiten Einsatzes des Produktes eingeflossen waren.
Beim Entwurf und der Implementierung von GO# stand neben der Umsetzung des MSFKonzeptes eine leistungsstarke Architektur, welche die schnelle Entwicklung von
standardisierten, wieder verwendbaren Oberflächen erlauben soll, im Vordergrund.
Komplexe Funktionalitäten sollten möglichst durch Klassen mit einfach gehaltenen
Schnittstellen gekapselt werden, um die Einarbeitungszeit zu verkürzen. Weiterhin sollte auf
Redundanz bei der Implementierung von Klassen und Methoden verzichtet werden, was
nicht zuletzt durch eine umfangreiche aber übersichtliche Dokumentation von Quellcode und
Programmierschnittstellen erreicht wurde.
Die Beurteilung durch die Entwickler ist natürlich nicht vollständig objektiv, da jeder auch
selbst an der Implementierung mitgewirkt hat und damit häufig eigene Leistungen besser
bewertet werden. Trotz dieses Vorbehalts besteht unter den Entwicklern die auch von
193
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
"Externen" (Führungspersonal in OFFIS oberhalb der Entwicklerteams) geteilte Meinung,
dass die Wahl der Entwicklungsplattform gut getroffen wurde und die Ergebnisse
überzeugend sind. Die wichtigsten, nachvollziehbaren Gründe hierfür sind:
•
Das komponentenorientierte Design ermöglicht eine gute Entwicklung im Team, bei
der Kollisionen durch Änderungen ein- und derselben Quellcodedatei durch mehrere
Entwickler selten vorkommen. Dies liegt an der strikten Trennung von Komponenten,
die alle unabhängig von einander sind.
•
Der strukturierte Aufbau des MSF-Konzeptes, der teilweise mit Hilfe eines endlichen
Automaten (vgl. Kapitel 4) formalisiert werden kann, stellt eine einheitliche Basis zur
Verfügung. Oberflächen und Funktionalitäten müssen nicht nachträglich angepasst
werden, um ein einheitliches “Look and Feel“ der gesamten Applikation zu
gewährleisten.
•
Die Verwendung von property-basierten Komponenten ermöglicht die schnelle
Implementierung von Oberflächenkomponenten. Die vorliegende Architektur kann
hier mit 4GL-Werzeugen wie Forms, 4th-Dimension oder Access konkurrieren.
Es bleibt abzuwarten, wie hoch der Aufwand sein wird um zukünftige technische
Änderungen von .NET, C# und Windows und Änderungen der Anforderungen durch den
Anwender, die Krankenkassen oder den Gesetzgeber umzusetzen. Ebenso muss geklärt
werden, wie zuverlässig die Applikation und die Laufzeitumgebung sind. Hier hat
insbesondere der automatische Garbage-Collector den Nachteil, dass Speicherlecks schwer
nachzuweisen, zu lokalisieren und letztlich zu beseitigen sind.
Weiterhin muss die Wartezeit beim Programmstart noch verringert werden. Hier wurde die
Applikation zu Gunsten des Laufzeitverhaltens optimiert, was beim Programmstart
insbesondere durch das spekulative Laden von Optionen und Informationen aus dem
Datadictionary der Datenbank zu Wartezeiten von bis zu 20 Sekunden führen kann. Da dies
aber nur einmalig beim Programmstart zu Wartezeiten führt, wurde das Antwortverhalten
durch die Anwender durchgehend positiv beurteilt.
5.6.2 Betrachtung von GO# aus Sicht der Anwender
Im August 2005 wurde am Arbeitsplatz des Pflegepersonals in den beiden
Herzkatheterlaboren der Kardiologie der Klinikum Oldenburg gGmbH der erste Prototyp von
GO# in einer klinischen Produktionsumgebung installiert. Hier werden täglich
durchschnittlich 25 Herzkatheteruntersuchungen dokumentiert. Die Dokumentation erfolgt
während des medizinischen Eingriffs durch das Pflegepersonal, welches bereits über
mehrjährige Erfahrung im Umgang mit Computern im HK-Labor verfügt. Um die Ergonomie
der Software zu testen, wurde keine vorherige Schulung des Personals durchgeführt. Es
sollte geprüft werden, ob die Software weitgehend selbsterklärend und den Arbeitsabläufen
im Herzkatheterlabor angepasst ist. Um einen reibungslosen Ablauf zu gewährleisten und
194
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
die Behandlung der Patienten nicht zu behindern, waren in den ersten Wochen stets zwei
Softwareentwickler in der Klinik vor Ort. Diese führten auch die im Folgenden in Tab. 5.3
aufgeführten Zeitmessungen durch.
Diese Messungen wurden an zufällig ausgewählten Tagen durchgeführt, bei denen den
Entwicklern nicht bekannt war, welche Eingriffe geplant waren. Damit sollte sichergestellt
werden, dass keine Behandlungsmethoden bei den Messungen gezielt bevorzugt wurden.
An diesen Tagen wurden insgesamt 28 (15 und 13) Untersuchungen durchgeführt. Dies
entspricht in etwa der durchschnittlichen Anzahl täglich durchgeführter Untersuchungen in
den beiden HK-Laboren der Oldenburger Kardiologie, welche bei 13,96 Untersuchen pro
Tag liegt. Ebenso repräsentierte die Verteilung der durchgeführten diagnostischen,
therapeutischen und kombinierten Herzkatheter die normale Verteilung in den betrachteten
HK-Laboren. Diese unauffällige Verteilung von Eingriffen war bei der hohen Anzahl
medizinischer Eingriffe, die täglich in den beiden HK-Laboren der Oldenburger Kardiologie
durchgeführt werden, zu erwarten, weshalb auch eine zufällige Auswahl der Tage für die
Zeitmessung vorgenommen wurde.
Im HK-Labor konnte erstmals das MSF-Konzept bei der Dokumentation medizinischer
Behandlungen im Produktionsbetrieb in einer klinischen Umgebung getestet werden. Für
eine Bewertung der neuen Software und den Vergleich mit dem Vorgänger wurden
Bearbeitungszeiten für ausgewählte Aktionen (vgl. Tab. 5.3) gemessen und ein Fragebogen
(vgl. Anhang F), der Mitarbeitern des Pflegepersonals des HK-Labors vorgelegt wurde,
erstellt und ausgewertet.
Bei den Zeitmessungen aus Tab. 5.3 fällt auf, dass die neue Software schneller zu bedienen
ist, jedoch ein etwas schlechteres Antwortverhalten, also insgesamt höhere Wartezeiten
vorweist. Die bessere Bedienbarkeit, insbesondere bei der manuellen Auswahl von
Datensätzen, lässt sich auf die Listen, welche gerade die Patienten, die für den MSP zu
einem speziellen Zeitpunkt von Interesse sind, zurückführen. Hier wurde nur in einem der 28
betrachteten Fälle kein direkter Treffer erzielt und die Verwendung der Schaltfläche zur
Suche im Archiv benötigt.
Der Zeitgewinn von durchschnittlich 21 Sekunden pro Untersuchung kann in der Praxis
vernachlässigt werden und hat auch keinen entscheidenden Einfluss auf die Länge der
Untersuchung. Die Auswertung der Fragebögen zeigt jedoch, dass der Anwender subjektiv
eine Verkürzung der Bearbeitungs- und Dokumentationszeit wahrnimmt, die auf die
übersichtlichere Struktur und bessere Benutzerführung der neuen Software zurückzuführen
ist.
Zur Auswertung der Fragebögen wurden die Antworten mit den Werten -2 für "starke
Verschlechterung" bis +2 "erhebliche Verbesserung" bewertet und der Mittelwert über diese
Bewertungen zu den einzelnen Fragen gebildet. Diese Mittelwerte sind im Diagramm in Abb.
5.14 zu sehen.
195
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Durchgeführte Aktion
Alt
Neu
Ø
Abw.
Ø
2108
1273
2041
734
Auswahl des Datensatzes: Normalfall unter Verwendung der KISNummer in s
1
0
1
0
Auswahl des Datensatzes: Manuelle Auswahl über Terminliste in s
18
12
4
2
Auswahl eines alten Datensatzes in s
11
9
4
2
Gesamtzeit zum Anlegen eines Datensatzes in s
42
21
40
25
Wartezeit bei der Neuanlage eines Datensatzes in s
12
2
18
2
4
1
6
1
182
73
161
63
Gesamtdauer Beginn / Ende in s
Wartezeit beim Laden eines Datensatzes in s
Bedienzeit durch den Anwender in s
Tab. 5.3:
Abw.
Vergleich der Bearbeitungszeit ausgewählter Aktionen (vgl. Fragebogen in Anhang F) in
der alten und der neuen Software. Insgesamt wurden jeweils 20 HK-Untersuchungen
vermessen. In der Spalte "Ø" ist die durchschnittliche Bearbeitungszeit, in der Spalte
"Abw." die Standardabweichung jeweils in Sekunden angegeben.
2
1,5
1
0,5
0
-0,5
hb
n
at
io
ur
lN
ac
Ko
nf
ig
ea
r
be
itu
ng
st
he
it
ob
u
R
or
tv
An
tw
äs
en
ta
tio
er
h
n
n
ep
r
R
ok
u
D
al
te
n
Au
sw
ah
be
r
Ü
m
en
ta
tio
ef
üh
rt
ur
ch
g
si
ch
td
si
c
be
r
Ü
Au
sw
ah
lN
eu
ht
g
ep
l
an
la
ge
an
t
-1
Abb. 5.14: Auswertung der Fragebögen aus Anhang F zum Vergleich der alten mit der neuen
Software. Ein positiver Wert steht für eine Verbesserung in der neuen Software.
196
Software-Architektur zur Implementierung kardiologischer Abteilungsinformationssysteme
Mit Ausnahme des Antwortverhaltens wurde keine Funktion der neuen Software als direkte
Verschlechterung gegenüber der Vorgängerversion empfunden und insgesamt als
Verbesserung empfunden. Insbesondere folgende Funktionen wurden von den Anwendern
bei deren Befragung hervorgehoben:
•
Verbesserte Übersichtlichkeit durch Auswahl- und Übersichtslisten (dies entspricht
gerade den Steuerkomponenten, welche die Auswahlkriterien für die als nächstes
geplanten Behandlungen im Sinne des MSF-Konzeptes repräsentieren)
•
Automatische "Hintergrund"-Verarbeitung von Daten, die über Schnittstellen von
anderen Systemen geliefert werden,
•
Funktionen für Rückgängig-machen und Wiederherstellen
•
Vermeidung von Blockaden von Datensätzen durch sofortige Synchronisation mit der
Datenbank.
Aus einer Befragung der Pilotanwender ging hervor, dass Stabilität und eine problemlose
und zügige Erledigung der täglichen Routineaufgaben die wichtigsten Anforderungen an die
Software sind. Konfigurationsmöglichkeiten, Optionen, technische Hintergründe und
komplizierte Konzepte werden hier eher als störend empfunden.
Abschließend sei hier noch bemerkt, dass neben der Software für das Pflegepersonal im
HK-Labor ein Programm zur Lagerhaltung im HK-Labor, welches ebenfalls auf der GO#Architektur basiert, in der Kardiologie der Klinikum Oldenburg gGmbH eingeführt wurde. Hier
zeigte sich, dass das MSF-Konzept in Teilen auch auf nicht-medizinische Anwendungsfelder
übertragen werden kann.
197
Zusammenfassung und Ausblick
6 Zusammenfassung und Ausblick
Ziel der vorliegenden Arbeit war es, durch innovative Methoden der Informatik zunächst ein
formales Modell zur Abbildung klinischer Arbeitsabläufe und hierauf aufbauend eine
Software-Architektur vorzustellen, die einen Beitrag zur Entlastung des medizinischen
Personals bei der Ausübung täglicher Routinearbeiten leistet. In Kapitel 6 wird zunächst das
Erreichte zusammengefasst und dann betrachtet, in wie weit dieses Ziel erreicht wurde.
Abschließend wird im Ausblick kritisch diskutiert, wo die Grenzen des vorgestellten Ansatzes
des MSF liegen und welche Verbesserungen und Erweiterungen wünschenswert sind.
6.1 Zusammenfassung
In der vorliegenden Arbeit ist ein neuartiges serviceflow-basiertes Verfahren zur
Modellierung klinischer Arbeitsabläufe entwickelt worden, welches die Basis für die
anschließend vorgestellte Software-Architektur zur Implementierung klinischer IuK-Systeme
bildet. Im Gegensatz zu workflow-basierten Ansätzen ist der hier verwendete serviceflowbasierte Ansatz flexibler hinsichtlich Ereignissen, die aufgrund unvorhersehbarer Situationen
in klinischen Umgebungen - z. B. bei medizinischen Notfällen oder unerwarteten
Krankheitsverläufen - häufiger auftreten.
Konkret wurde in dieser Arbeit der MSF (Medizinische Serviceflow) als tragfähiges
Basiskonzept der Modellierung definiert. Im Rahmen dieser Definition wurden mit
•
dem MSP (Medizinischer Servicepoint), der leistungserbringende medizinische
Abteilungen repräsentiert,
•
der SK (Strukturierte Krankenakte), in der die Dokumentation der erbrachten
Leistungen gespeichert werden kann,
•
dem PS (Patientenstatus), der Informationen über den Krankenhausaufenthalt eines
Patienten abbildet, und
•
Aktivatoren, die Hintergrundprozesse anstoßen können,
geeignete formale Beschreibungen klinischer Strukturen und Objekte geliefert.
Im Mittelpunkt der Modellierung steht der Patient, welcher im Rahmen der Behandlung
unterschiedliche MSPs aufsucht. Die Entscheidung, wie die weitere Behandlung erfolgen
199
Zusammenfassung und Ausblick
soll, also welcher MSP als nächstes für den Patienten zuständig ist, wird einzig durch den
Krankheitsverlauf und die Bedürfnisse des Patienten - im Modell repräsentiert durch die
aktuell gestellte Diagnose und daraus resultierende Indikation - bestimmt. Somit kann der
verantwortliche Arzt jederzeit die Behandlungsstrategie anpassen und dem Patienten die
bestmögliche Versorgung zukommen lassen, ohne durch Regeln oder Vorgaben in seiner
Entscheidungsfreiheit beschränkt zu sein. Weiterhin wurde gezeigt, dass ein bereits
existierendes Modell für eine klinische Abteilung leicht modifiziert werden kann, um
Änderungen in der klinischen Struktur oder neuen Erkenntnissen aus der medizinischen
Forschung gerecht zu werden.
Durch die Darstellung der ärztlichen Verordnungen und der daraus resultierenden
Behandlungen durch einen Mealey-Automaten wurde die Grundlage für die praktische
Implementierung einer Software-Architektur geschaffen. Der grundsätzliche Aufbau dieser
Architektur anschließend beschrieben und die praktische Realisierbarkeit durch die
Implementierung erster Prototypen im Rahmen des Projektes GO# nachgewiesen worden.
Neben den bereits beschriebenen Vorteilen, die das MSF-Konzept bietet, sind die
wichtigsten Aspekte dieser Software-Architektur:
•
Die Verwendung unabhängiger Komponenten, die über einen zentralen
Kommunikationsbus verbunden sind, ermöglicht die individuelle Konfiguration der
Programme für den Anwender.
•
Kompatibilität zu Systemen, die auf älteren Technologien basieren, kann mit Hilfe
moderner komponenten-basierter Architekturen erreicht werden. So kann eine sanfte
Migration hin zu aktuellen Technologien ermöglicht werden.
•
Die Verwendung einer modernen objekorientierten Sprache in Kombination mit einer
zu der Sprache passenden Entwicklungsumgebung ermöglicht mit dem Konzept der
property-basierten Komponenten eine einfache, schnelle und komfortable
Möglichkeit zur Implementierung der Benutzungsoberfläche.
•
Kommunikationsschnittstellen zu anderen Systemen und Datenquellen können
jederzeit ausgetauscht und der Infrastruktur der Institution, in der das System konkret
zum Einsatz kommen soll, angepasst werden.
Dass dies eine tatsächliche Arbeitserleichterung und Entlastung für das medizinische
Personal bringen kann, wurde durch den Einsatz von GO# in einer klinischen
Produktionsumgebung im HK-Labor und die Auswertung der während der Testphase
gesammelten Informationen gezeigt.
Diese positive Resonanz der Anwender ist nicht zuletzt auf die sorgfältige Analyse der
Anwendungsdomäne "Kardiologie" zurückzuführen. Detailliertes Wissen über die
Anforderungen und Tätigkeiten der Anwender sind notwendige Voraussetzungen für die
Implementierung einer Software, die Routineaufgaben zuverlässig und wunschgemäß
200
Zusammenfassung und Ausblick
ausführen soll. Dies gilt insbesondere für das komplexe Umfeld der medizinischen
Anwendungsdomäne.
6.2 Ausblick
Die in der Einleitung angesprochenen und in Kapitel 2 (insb. Abschnitt 2..6) dargestellten
Probleme bei der Kommunikation zwischen klinischen Informationssystemen und
medizinischen Großgeräten wurde nur indirekt behandelt. Mit Hilfe der Aktivatoren des MSFModells, welche in der Software-Architektur GO# durch Hintergrundkomponenten realisiert
werden können, besteht zwar grundsätzlich die Möglichkeit Kommunikationsschnittstellen zu
realisieren. Jedoch wäre ein formales Modell zur Definition der Synchronisation der
Kommunikation zwischen unterschiedlichen Systemen wünschenswert. Dieses Modell sollte
bestehende Standards, wie sie z. B. die IHE definiert, weitgehend unterstützen.
Eine weitere sinnvolle Erweiterung ist die Integration eines Regelwerkes, das
Überwachungsfunktionen bereitstellt, die die strikte Einhaltung von Regeln erzwingen. Hier
zeigt sich ein Nachteil des in dieser Arbeit vorgestellten Ansatzes gegenüber adaptiven
WfMSen. Die Betrachtung klinischer Strukturen und Abläufe aus Sicht des Patienten und der
Dienstleistung führt zwar zu einer hohen Flexibilität des MSF. So kann zu jeder Zeit jede
weitere Behandlung abhängig von der Einschätzung des verantwortlichen Arztes veranlasst
werden. Es gibt jedoch kein Regelwerk, welches Vorgaben für den konkreten Arbeitsablauf
innerhalb der MSPs gibt.
Es wurden zwar bei der Entwicklung von GO# Mechanismen implementiert, die eine
Regelprüfung der Eingaben, insbesondere zur Einhaltung der von der BQS
vorgeschriebenen Plausibilitätsregeln (vgl. [BQS]), ermöglichen. Auf diese Mechanismen
wurde in dieser Arbeit jedoch nicht weiter eingegangen, da sie nur nachträglich an Hand des
BQS-Regelwerks Prüfungen durchführen und den Anwender auf Regelverletzungen
hinweisen, die dann durch den Anwender korrigiert werden müssen. Hier besteht also noch
Erweiterungsbedarf für ein schlüssiges und formal abgesichertes Modell, welches auch die
Möglichkeit zur Umsetzung von Direktiven der ärztlichen Leitung, wie z. B. "Vor jedem
Herzkatheter muss ein EKG erstellt worden sein", erlaubt. Da sich, wie in Abschnitt 2.5
bereits angesprochen, das MSF-Konzept als "Alternative, die einen anderen Ansatz bei der
Betrachtung klinischer Strukturen aufzeigt" sieht und nicht etwa etablierte, erprobte und
tragfähige Konzepte wie das WfM ablösen möchte, ist hier die stärkere Integration von
Forschungsergebnissen aus Projekten wie ADEPT gut vorstellbar. Denkbar wäre z. B. die
Integration beider Ansätze, indem der MSP erweitert wird. Diese Erweiterung könnte in
Form von adaptiven Workflow-Modellen erfolgen, mit deren Hilfe eine formale Beschreibung
der Arbeitsabläufe in den MSPs erfolgt.
201
Zusammenfassung und Ausblick
Neben der Erweiterung um Komponenten für weitere medizinische Fachabteilungen stellt
sich angesichts der Erfahrung bei der Nutzung der Software-Architektur für die
Implementierung einer Lagerhaltung die Frage, in wie weit die in dieser Arbeit hergeleiteten
Konzepte auch für andere Anwendungsfelder, insbesondere aus der Dienstleistungsbranche, nutzbar sind. Diese Frage stellt sich insbesondere auch deshalb, da das Konzept
des Serviceflows ursprünglich für die Modellierung von Geschäftsprozessen aus der
Dienstleistungsbranche entworfen wurde (vgl. [KW00] oder [Anz02]).
Somit darf zum Abschluss festgehalten werden, dass diese Arbeit kein vollständiges
Konzept zur Implementierung von IuK-Systemen im Gesundheitswesen liefert. Aber sie
bietet einen zentralen Baustein zur Entwicklung patientenorientierter klinischer
Informationssysteme, der zeigt, dass das Modell des Serviceflows, das den Kunden, also
den Patienten, in den Mittelpunkt stellt, ein viel versprechendes Instrument zur Entwicklung
von Software für die Entlastung des medizinischen Personals und somit zur Verbesserung
der Versorgung von Patienten ist. Angesichts der positiven Resonanz durch die Anwender in
der Pilotphase ermutigen die Ergebnisse dieser Arbeit im Bereich der IuK-Systeme für das
Gesundheitswesen und insbesondere im OFFIS-Projekt GO# zu einer Weiterentwicklung
der serviceflow-basierten Modellierung klinischer Abteilungsinformationssysteme und des
bereits implementierten Prototyps.
202
Literaturnachweis
Anhang A: Literaturnachweis
[ABH00]
Al Suwaidi, J., Berger, P. B., Holmes, D. R. Jr. et al: Coronary artery stents, JAMA 284,
S. 1828-1836, 2000
[ADEPT]
ADEPT - Next Generation Workflow-Management-System: http://www.informatik.uniulm.de/dbis/f&l/forschung/workflow/ftext-adept_e.html
[AEE01]
Ammenwerth, E., F. Ehlers, R. Eichstädter, et al.: Vorgehensplan zum
Forschungsprojekt: Unterstützung der Organisation des Behandlungsprozesses in der
Kinder- und Jugendpsychiatrie. Abteilung Medizinische Informatik des Institutes für
medizinische Biometrie und Informatik der Universität Heidelberg. Bericht 1/2000,
Heidelberg, 2000
[AFGW01]
Appelrath, H.-J., Friebe, J., Grawunder, M., Wellmann, I.: The Need for Open
Geographical Information Systems in Medicine, Methods of Information in Medicine
Vol. 40, No. 2, Schattauer, Stuttgart, 2001
[AES03]
Ammenwerth, E., Eichstädter, R., Schrader, U. et al.: EDV in der Pflegedokumentation,
Hannover, 2003
[AGFA]
Pressemitteilung von Agfa-Gevaert: AGFA to acquire GWI, an outstanding European
company in healthcare IT, Mortsel (Belgium), Bonn (Germany), November, 2004,
http://www.agfa.com/healthcare/news/20041123gwi/
[AGKIS]
Homepage
der
Arbeitsgruppe
KIS
der
marburg.de/stpg/ukm/lt/medinformatik/kis-ag.html
[Anz02]
Anzelak, M.: Serviceflow Beyond Workflow?, Seminararbeit am Institut für Institut für
Informatik-Systeme (ISYS) der Universität Klagenfurt, Klagenfurt, 2002,
http://www.isys.uniklu.ac.at/ISYS/Courses/02WS/Seminar_aus_Praktischer_Informatik/anzelak.pdf
[ABCW02]
Appelrath, H.-J., Boles, D., Claus, V., Wegener, I.: Starthilfe Informatik, 2. durchges.
Auflage 2002, Teubner Verlag, Stuttgart, 2002
[AS03]
Appelrath, H.-J., Schlattmann, M.: Gentechnik per Mausklick, In: Einblicke Nr. 37,
Forschungsmagazin der Carl von Ossietzky Universität Oldenburg, Oldenburg, 2003
[AT04]
Appelrath, H.-J., Thoben, W.: Beiträge der Informatik für eine Gesundheitsversorgung
der Zukunft. Informatik, Biometrie und Epidemiologie in Medizin und Biologie,
35(3):179-187, Elsevier Verlag, Jena, 2004.
[AZM92]
Appelrath, H.-J., Zimmerling, R., Matschull, T.: INKA - Überarbeitung
Relationenstruktur (Konzept), interner Bericht von OFFIS, Oldenburg, 1992
GMDS
http://www.med.uni-
der
203
Literaturnachweis
[Aum04]
Aumiller, J.: Geriatrisierung der Medizin, In: CARDIOVASC 2004; 4(9), S. 3-5, Urban &
Vogel Medien und Medizin Verlagsgesellschaft
[BÄK]
(Muster-) Berufsordnung der Bundesärztekammer: MBO-Ä 1997 - in der Fassung der
Beschlüsse des 100. Deutschen Ärztetages 1997 geändert durch die Beschlüsse des
106. Deutschen Ärztetages 2003 in Köln (§§ 7 Abs. 4, 18, 26, 30 ff.)
http://www.bundesaerztekammer.de/30/Berufsordnung/10Mbo/
[Bau02]
Bauknecht, K.: Kernvorlesung Informationsmanagement / Informationsmanagement III
am Institut für Informatik der Universität Zürich http://www.ifi.unizh.ch/ikm/
Vorlesungen/IM3/WS0102/IM3_files/9_3-WorkgrpComp_slides.pdf
[BH95]
Buchholz, W., Haux, R. (Hrsg.): Informationsverarbeitung in den Universitätsklinika
Baden-Württembergs. Symposium, Heidelberg, 1995
[BHJ91]
Barth, A., Hewett, A., Jensch, P.: "Kooperatives Arbeiten im Kontext wechselnder
Anwendungen"; Interner Bericht des Fachbereichs Informatik der Carl von Ossietzky
Universität Oldenburg; 1991
[BKMJ04]
Beyer, M., Kuhn, K., Meiler, C., Jablonski, S., Lenz, R.: IT-basierte Integration in
medizinischen Versorgungsnetzen. In Hasselbring, W., Reichert, M (Hrsg.): Enterprise
Application Integration 2004, Proceedings of the GI-/GMDS Workshop on Enterprise
Application Integration (EAI-04), Oldenburg, 2004, CEUR Workshop Proceedings 93
2004
[BMC99]
Bemmel, J. H. van., McCray, A. T.: The Promise of Medical Informatics. In Yearbook of
Medical Informatics 99, 1999
[BMGS03]
BMGS Pressestelle: "Rückläufige Einnahmen gefährden GKV-Konsolidierung Finanzentwicklung der Krankenkassen im 1. Quartal 2003", Pressestelle des
Bundesministeriums für Gesundheit und Soziales (BMGS), Berlin, 03.06.2003
http://www.bmgs.bund.de/deu/gra/aktuelles/pm/bmgs03/bmgs2_3336.cfm
[BMRS00]
Buschmann, F., Meunier, R., Rohert, H., Sommerlad, P., Stal., M.: Patternorientierte
Software-Architektur. Addison-Wesley (Deutschland) GmbH, Bonn, 2000.
[BPMI]
BPMI.org, The Business Process Management Initiative: http://www.bpmi.org/
[BQS]
Homepage der Bundesgeschäftsstelle Qualitätssicherung: http://www.bqs-online.de
[BQS04]
BQS Bundesgeschäftsstelle Qualitätssicherung gGmbH (Herausgeber Mohr, V., Bauer,
J., Döbler, K., Fischer, B., Woldenga, C.): "Qualität sichtbar machen. BQSQualitätsreport 2002", Düsseldorf, 2004
[Bru04]
Bruckenberger,
E.:
Herzbericht
2003,
16.
Krankenhauswesen der Arbeitsgemeinschaft der
behörden der Länder, Hannover, 2004
[CAKR00]
Claus, M., Appelrath H.-J., Kronberg, K., Reil, G.H.: Integration digitalisierter Filme und
Bilder in die elektronische Patientenakte am Beispiel der Echokardiographie. In Steyer,
G, Engelhorn, M. et al (Hrsg.): TELEMED 2000, Tagungsband zur 5.
Fortbildungsveranstaltung und Arbeitstagung, Berlin, 2000
204
Bericht
der
Arbeitsgruppe
obersten Landesgesundheits-
Literaturnachweis
[CEN95]
Europäisches Komitee für Normung CEN TC251: Medical Informatics – Medical
Imaging Communication (MEDICOM), ENV 12052:1995.
[Che76]
Chen, P. P.: The Entity-Relationship-Model - Towards a Unified View of Data, ACM
Transactions on Database Systems 1, 1976
[CKRJ99]
Claus, M., Kronberg, K., Reil, G.-H., Jensch, P.: Computer Aided Quality Control,
Documentation, Report Generation and Education in Echocardiography. In XXIst
Congress of the European Society of Cardiology, Supplement Vol. 20, Barcelona,
August 99
[CK03]
Claus, M., Kronberg, K.: Therapieverschlüsselung in der Echokardiographie und in der
Magnetresonanztomographie mit dem neuen erweiterten OPS Version 2.1, 27.
Herbsttagung der deutschen Gesellschaft für Kardiologie, Münster, 2003
[CKRE01]
Claus, M., Kronberg, K., Riesmeier, J., Eichelberg, M.: Methods for comparison of
different compressors for angiographic films European Heart Journal Vol. 22, Abstr.
Supplement September 2001
[Cla00]
Claus, M.: GO_Heart: Dokumentations-, Lagerhaltungs- und Analyse-Programm für die
Herzchirurgie. In Roeder, N. et al. (Hrsg.): "Dokumentationsverfahren in der
Herzchirurgie", Vol. VI, Münster, 2000
[Cla01]
Clade, H.: Anhaltender Kampf gegen den Überstundenstress, Deutsches Ärzteblatt 98,
Ausgabe 46 vom 16.11.2001, S. A-2997, Köln, 2001.
[CTKR99]
Claus, M., Tröster, J., Kronberg, K., Reil, G.-H., Jensch, P.: Software for
Documentation, Automated Report Generation, Medical and Economical Statistics, and
Quality Control in the Cardiac Catheterisation Laboratory. In XXIst Congress of the
European Society of Cardiology, Supplement Vol. 20, Barcelona, August 99
[Cod70]
Codd, E. F.: A relational model of data for large shared data banks. Communications of
the ACM, 13(6):377-387, 1970[Col70]
Collen, M. F.: General requirements for a
medical information system. Comp. Biomed Res. 3, S. 393-406, 1970.
[Die93]
Dierks, C.: Schweigepflicht und Datenschutz in Gesundheitswesen und medizinischer
Forschung. VVF, München, 1993
[DGK]
Deutsche Gesellschaft für Kardiologie: http://www.dgk.org/[DGK04]
DGK
Deutsche Gesellschaft für Kardiologie – Herz- und Kreislaufforschung e.V.: Gewinn an
Lebensjahren und Lebensqualität, Pressemitteilung, Pressetext DGK 10/2004
[DKRB95]
Dadam, P.; Kuhn, K.; Reichert, M.; Beuter, Th.; Nathe, M.: ADEPT: Ein integrierender
Ansatz zur Entwicklung flexibler, zuverlässiger kooperierender Assistenzsysteme in
klinischen Anwendungsumgebungen. Proc. GI/SI Jahrestagung, Zürich, September
1995
[DRK97]
Dadam, P., Reichert, M., Kuhn, K.: Clinical Workflow - The Killer Application for
Process-oriented Information Systems?, Ulmer Informatik-Berichte 97-16, Fachbereich
Informatik der Universität Ulm, 1997
[EEK97]
Erbel, R, Engel, H. J., Knübler, W. et al.: Richtlinien der Interventionellen
Koronartherapie, Zeitschrift für Kardiologie, Band 86. Z Kardiol 86, S. 1040-1063, 1997,
http://www.dgk.org/leitlinien/InterventionelleKoronartherapie.html
205
Literaturnachweis
[Eic02]
Eichelberg, M.: Ein Verfahren zur Bewertung der Interoperabilität medizinischer
Bildkommunikationssysteme. Universitätsverlag Aschenbeck & Isensee, Oldenburg,
2002
[Eic03]
Eichelberg, M., Poiseau, E., Wein, B. B., Riesmeier, J.: IHE Europe: extending the IHE
initiative to the European healthcare market, In Huang, H. K., Ratib, O. M. (Hrsg.):
Medical Imaging 2003: PACS and Integrated Medical Information Systems: Design and
Evaluation, 2003
[EN02]
Elmasri, R., Navathe, S. B.: Grundlagen von Datenbanksystemen 3., überarbeitet
Auflage, Addison-Wesley, Pearson Studium, München, 2002
[ERGJ98]
Eichelberg M., Riesmeier J., Gehlen S., Jensch P.: Visualization of DICOM Images Handling the Standard's Complexity. In Proceedings EuroPACS '98, S. 189-192
[Fei88]
Feigenbaum, H.: Digital recording, display, and storage of echocardiograms. J Am Soc
Echocardiogr; S. 378 – 383; 1988
[Fei97]
Feigenbaum, H.: History of Digital Echocardiography. Cardiac Imaging in the 21
Century: A Primer; S. 124 – 127, Maryland, 1997
[Fli01]
Flintrop, J.: Bereitschaftsdienst: Das große Schweigen, Deutsches Ärzteblatt 98,
Ausgabe 27 vom 06.07.2001, S. A-1795, Köln, 2001
[Fra94]
Frank, U.: Multiperspektivische Unternehmensmodellierung. Theoretischer Hintergrund
und
Entwurf
einer
objektorientierten
Entwicklungsumgebung.
(zugleich
Habilitationsschrift, Universität Marburg), München, Oldenbourg, 1994
[GDRG]
Offizielle Website der Selbstverwaltung für German Refined - Diagnosis Related
Groups: http://www.g-drg.de/
[GMDS]
Homepage der GMDS: http://www.gmds.de
[GOKARD]
Homepage des Projektes GO-Kard: http://www.gokard.de
[IHE]
IHE: The IHE Initiative's Mission, http://www.rsna.org/IHE/mission.shtml
[HAB01]
Haux, R., Ammenwerth E., Buchauer, A., et al.: Anforderungskatalog für die
Informationsverarbeitung im Krankenhaus - Version 1.0 (2001), Technical Report 1,
Heidelberg, Abteilung Med. Informatik des Universitätsklinikums Heidelberg, 2001
[HAB04]
Hamm C. W., Arntz, H. R., Bode, C. et al: Leitlinien Akutes Koronarsyndrom Teil 1:
Akutes Koronarsyndrom ohne ST-Hebung. Z Kardiol 93, S. 72–90, Steinkopff Verlag,
Darmstadt, 2004
[HAHK04]
Haux, R., Ammenwerth, E., Herzog, W., Knaup, P.: Gesundheitsversorgung in der
Informationsgesellschaft - eine Prognose für das Jahr 2013 verbunden mit einer
Erinnerung an Karl Jaspers. Informatik, Biometrie und Epidemiologie in Medizin und
Biologie, 35(3):138-163, Elsevier Verlag, Jena, 2004.
[Hani02]
Hanisch, A.: GoTo C#; Addison-Wesley, München, 2002
[Hau95]
Haux, R.: Stand und weitere Entwicklung von Krankenhausinformationssystemen: die
Empfehlungen der Deutschen Forschungsgemeinschaft. In [BH95]
206
st
Literaturnachweis
[HBL04]
Hoffmann, R., Buck, T., Lambertz, H. et al.: Positionspapier zu Qualitätsstandards in
der Echokardiographie. Herausgegeben vom Vorstand der Deutschen Gesellschaft für
Kardiologie - Herz- und Kreislaufforschung e.V., 2004, http://www.dgk.org/leitlinien/
PositionspapierEchokardiographie.pdf
[Hen03]
Hennersdorf,
G.:
"Was
bedeutet
der
Begriff
http://www.hzvk.de/Patienten/was%20ist%20Kardiologie.htm
[Her97]
Herold, G. et al.: Innere Medizin, Köln, 1997
[HG92]
Hoare, C. A. R., Gordon, M. J. C. (Hrsg.): Mechanized reasoning and hardware design,
Hempstead, Prentice Hall International Ltd., 1992
[HGBE97]
Hewett A. J., Grevemeyer H, Barth A, Eichelberg M, Jensch P: Techniques and
Experiences in Validating DICOM Images. In Proceedings EuroPACS '97, S. 195-198.
[HL7]
Homepage von Health Level Seven: http://www.hl7.org
[HUM02]
Hopcroft, J E, Ullman, J D, Motwani, R: Einführung in die Automatentheorie, Formale
Sprachen und Komplexitätstheorie. Pearson Studium, 2002
[HSW96]
Haux, R., Schmücker, P., Winter, A.: Gesamtkonzept der Informationsverarbeitung im
Krankenhaus. In: Kuhn K et al. (Hrsg.). Praxis der Informationsverarbeitung im
Krankenhaus. Landsberg: ecomed., 1996
[Hub00]
Huber, T.: Datenbanken im klinischen Einsatz, Seminar am Institut für Prozeßtechnik,
Automation und Robotik der Universität Karlsruhe, Sommersemester 2000, Karlsruhe,
2000, http://wwwipr.ira.uka.de/~megi/SEMINAR/SS_00/Datenbanken.pdf
[HWAB04]
Haux, R., Winter, A., Ammenwerth, E., Brigl, B.: An Instruction to Hospital Information
Systems. New York, Springer. 2004
[IEK03]
Institut für das Entgeltsystem im Krankenhaus (InEK gGmbH): DEUTSCHE
KODIERRICHTLINIEN - Allgemeine und Spezielle Kodierrichtlinien für die
Verschlüsselung von Krankheiten und Prozeduren - Version 2004, Siegburg, 2003
[IDS]
IDS Scheer AG: http://www.ids-scheer.de/
[JHCM94]
Jensch P., Hewett A. J., Cordonnier E., Mattheus R.: DICOM V3.0 - The CEN trial
implementation. In SPIE Medical Imaging 1994, PACS: Design and Evaluation,
Newport Beach, Vol. 2165, S. 368-377, 1994
[Jon98]
Jonitz, G.: "Arzt im Krankenhaus", Referat zum 101. Deutschen Ärztetag , Köln, 19. bis
23.
Mai
1998,
http://www.aerztekammer-berlin.de/10_Aktuelles/20_standpkt/
999_Jon101dat.html
[JPEG]
JPEG Homepage: http://www.jpeg.org/
[Kim99]
Kim, H. M.: "Representation and Reasoning About Quality using Enterprise Models",
PhD Dissertation, Enterprise Integration Laboratory, Department of Mechanical and
Industrial Engineering, University of Toronto, 1999
[Kor02]
Korzilius, H.: Arbeitszeitgesetz: Letzte Chance zum Dialog, Deutsches Ärzteblatt 99,
Ausgabe 4 vom 25.01.2002, S. A-157, Köln, 2002
Kardiologie?"
207
Literaturnachweis
[Kun89]
Kung, C. H.: Conceptual Modelling in the Context of Software Development, IEEE
Trans Software Eng, SE 15, S. 1176–1187, 1989
[Kut01]
Kutscha, U.: Kooperatives Arbeiten im Krankenhaus - Konsequenzen für die
Gestaltung von Krankenhausinformationssystemen, Inauguraldissertation zur
Erlangung des Doctor scientiarum humanarum (Dr.sc.hum.) der Medizinischen Fakultät
Heidelberg der Ruprecht-Karls-Universität, Heidelberg, 2001
[KW00]
Klischewski, R., Wetzel, I.: Serviceflow-Management, Informatik Spektrum, Band 23,
Heft 1, Februar 2000
[KW02]
Klischewski, R., Wetzel, I.: Serviceflow-Management: Caring for the Citizen’s Concern
in Designing E-Government Transaction Process. In: Proceedings of the 35th Hawaii
International Conference on System Sciences, Hawaii, 2002
[KCHM01]
Kronberg, K., Claus, M., Hofmann, W., Müller-Eichelberg, A., Tröster, J., Riesmeier, J.,
Reil, G.-H.: A clinical evaluation of different standards for angiographic data
compression using digital imaging and communications in medicine (DICOM) and
motion picture experts group (MPEG) version 4, European Heart Journal Vol. 22, Abstr.
Supplement September 2001
[KVCM01]
Kronberg, K., Vocke, W., Claus, M., Riesmeier, J., Reil, G.-H.: Data compression of
echocardiographic film sequences: a comparison of Digital Imaging and
Communications in Medicine (DICOM) standards with Motion Picture Experts Group
(MPEG) version 4, European Journal of Echocardiography, Euroecho 5 Abstracts,
Volume 2, Suppl. A, 2001
[LEJ99]
Loxen N., Eichelberg M., Jensch P.: Digital signatures in DICOM services - early
experiences, Proceedings EMBEC '99, Vol. 37, Suppl. 2, S. 1548-1549, 1999
[LMB02]
Lehmann, M., Meyer zu Bexten, E.: Handbuch der Medizinischen Informatik. Carl
Hanser Verlag München Wien, 2002
[MARB]
Internetpräsenz des Marburger Bund: http://www.marburger-bund.de/
[MB91]
McCarthy J. C., Bluestein W. M.: Workflow's Progress. In The Computing Strategy
Report, Forrester Research Inc., Cambridge 1991
[MBGH04]
Mudra H., Bode, C., Grube, E., de Haan, F., Levenson, B., Schuler, G., Silber, S.:
Positionspapier zum Einsatz von Medikamente freisetzenden Stents bei Patienten mit
koronarer Herzerkrankung, Z Kardiol 93, S. 416–422, Steinkopff Verlag, Darmstadt,
2004
[Mic05]
Microsoft Corporation: Visual Basic- und Visual C#-Konzepte Programmieren mit
Komponenten,
Microsoft
Press,
2005,
http://msdn.microsoft.com/library/deu/
default.asp?url=/library/deu/vbcon/html/vbconComponentCreation.asp
[MLMJ04]
Müller, S., Lay, R., Meiler, C., Jablonski S.: Integration in der medizinischen
Anwendung: Prozessbasierte Datenlogistik. In Hasselbring, W., Reichert, M (Hrsg.):
Enterprise Application Integration 2004, Proceedings of the GI-/GMDS Workshop on
Enterprise Application Integration (EAI-04), Oldenburg, 2004, CEUR Workshop
Proceedings 93 2004
[MNET]
Microsoft .NET Framework: http://www.msdn.microsoft.com/netframework/
208
Literaturnachweis
[MONO]
Homepage des Mono-Projekts: http://www.mono-project.com/Main_Page
[MPEG]
MPEG Homepage: http://www.mpeg.org/
[MSDN]
MSDN Library: Visual Basic and Visual C# Concepts, Property Implementation in
Components;
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/
html/vbconImplementingPropertiesInComponents.asp
[Mue97]
Muelges, K.: Die multimediale Patientenakte, Deutsches Ärzteblatt 94, Ausgabe 46
vom 14.11.1997, S. A-3115, Köln, 2002
[NEMA99]
NEMA Standards Publication PS 3.x, Digital Imaging and Communications in Medicine
(DICOM), National Electrical Manufacturers Association, Washington, 1992-99.
[Neu05]
Neubacher, A.: Vampire in der Blutbank. In Der Spiegel 32 / 2005, Springer Verlag,
Hamburg 2005
[OERJ00]
Olges N. H., Eichelberg M., Riesmeier J., Jensch P.: Integrating JPEG compression
with DICOM -xperiences and Technical Issues. In G. James Blaine, Eliot L.Siegel
(Hrsg.): PACS Design and Evaluation: Enineering and ClinicalIssues, Proceedings of
SPIE Vol. 3980, S. 46-56, 2000.
[Oos97]
Oosterwijk, H.: DICOM: Your Guarantee to Interoperability? In Horii, S. C., Blaine, G. J.
(Hrsg.): Medical Imaging 1997: PACS Design and Evaluation: Engineering and Clinical
Issues, Band 3035, S. 165 – 169. SPIE, 1997.
[Ora99]
Oracle Corporation: Oracle Forms Developer: Form Builder Reference, Release 6i, Part
No: A73074-01, Oracle Corporation, Redwood City, 1999
[Ora99a]
Oracle Corporation: Oracle Reports Reference Release 6i, Part No: A73174-01, Oracle
Corporation, Redwood City, 1999
[Pro01]
Prokosch, H. U.: KAS, KIS, EKA, EPA, EGA, E-Health: Ein Plädoyer gegen die
babylonische Begriffsverwirrung in der Medizinischen Informatik. Informatik, Biometrie
und Epidemiologie in Medizin und Biologie 32/4, S. 371-382, Elsevier Verlag, Jena,
2001
[Rei90]
Reimann, U.: Integration heterogener Datenbestände am Beispiel einer klinischen
Umgebung, Diplomarbeit an der Universität Erlangen-Nürnberg, angefertigt im
Fachbereich Informatik der Carl von Ossietzky Universität Oldenburg, 1990
[Rut05]
Rutsch, W.: Neuer Stent am Start - Neues Medikamente freisetzendes Stentsystem
befindet sich in der Erprobungsphase. In Krankenhaus, Technik + Management 5/2005,
S. 26 - 28, Finningen, 2005
[RH88]
Roscoe, A. W., Hoare, C. A. R.: The laws of Occam programming. Theor. Comp. Sci.
60, S. 177-229, 1988
[RöV87]
Röntgenverordnung: Amtliche Hinweise des Normgebers
Verkündungsfundstelle: BGBl I 1987, 114, Bonn, 1987
[RR02]
Reichert, M., Rinderle, S.: Änderungsrechte in Adaptiven Workflow-ManagementSystemen, in Horster, P. (Hrsgb.): Sichere Geschäftsprozesse, St. Leon-Rot, 2002
auf
EG-Recht;
209
Literaturnachweis
[RRD03]
Reichert, M., Rinderle, S., Dadam, M.: ADEPT Workflow-Management-System: Flexible
Support for Enterprise-Wide Business Processes, in van der Aalst et al. (Hrsgb.): BPM
2003, LNCS 2678, Springer Verlag, Heidelberg, 2003
[RS95]
Riede, U.-N., Schaefer, H.-E. (Hrsgb.): Allgemeine und spezielle Pathologie, 4. Auflage,
Thieme Verlag, Stuttgart, 1995
[RZ01]
Roetmann, B., Zumtobel, V.: Klinische Informationssysteme: Strategien zur Einführung,
Deutsches Ärzteblatt 98, Ausgabe 14 vom 06.04.2001, S. A-892 / B-757 / C-715, Köln,
2001
[SBD04]
Statistisches Bundesamt: "Anzahl der Gestorbenen nach Kapiteln der ICD-10
Insgesamt", Statistisches Bundesamt Deutschland, Wiesbaden, 2004
http://www.destatis.de/basis/d/gesu/gesutab19.php
[SBD04a]
Statistisches Bundesamt: "Kosten 2002 nach Krankheitsklassen und Alter in EUR je
Einwohner der jeweiligen Altersgruppe", Statistisches Bundesamt Deutschland,
Wiesbaden, 2004 http://www.destatis.de/basis/d/gesu/gesutab23.php
[SBD04b]
Statistisches Bundesamt: "Bevölkerung nach Altersgruppen, Familienstand und
Religionszugehörigkeit", Statistisches Bundesamt Deutschland, Wiesbaden, 2004
http://www.destatis.de/basis/d/bevoe/bevoetab5.php
[SBD05]
Statistisches
Bundesamt:
"Einrichtungen,
Betten
und
Patientenbewegung
Krankenhäuser 1991 - 2003", Statistisches Bundesamt Deutschland, Wiesbaden, 2005
http://www.destatis.de/basis/d/gesu/gesutab29.php
[Sch96]
Schmücker, P.: Rechnergestützte Dokumentenmanagement- und Optische
Archivierungssysteme: Marktlage und Checkliste. In: Haas, Köhler et al. (Hrsg.): Praxis
der Informationsverarbeitung im Krankenhaus. ecomed, Landsberg 1996
[Sch01]
Scherp, A.: Vorgehensmodell und Entwicklungsmethodik für virtuelle Labore: der
VirtLab-Prozess. Diplomarbeit im Fachbereich Informatik der Carl von Ossietzy
Universität Oldenburg, Oldenburg, 2001
[Sch01a]
Schlichter,
J.:
Computergestützte
Gruppenarbeit,
muenchen.de/lehre/lectures/ws200203/cscw/extension/html/whiteboard/cscw_course.html
[SGBV]
Sozialgesetzbuch - Fünftes Buch (V) - Gesetzliche Krankenversicherung (Artikel 1 des
Gesetzes v. 20. Dezember 1988, BGBl. I S. 2477); Sachgebiet FNA 860-5; BGBl I
1988, 2477, 2482; Bonn; Dezember 1988
[SGS95]
SGS-Thomson: occam 2.1 Reference Manual, First published 1988 by Prentice Hall
International (UK) Ltd as the "occam 2 Reference Manual”, SGS-Thomson
Microelectronics, 1995, http://www.wotug.org/occam/documentation/oc21refman.pdf.
[SOAR]
Homepage Soarian: http://www.med.siemens.com/soarian/de/index_flash.html
[SOBB98]
Schmücker, P., Ohr, Ch., Beß, A., Bludau, H. B., Haux, R., Reinhard, O.: Die
elektronische Krankenakte. Informatik, Biometrie und Epidemiologie in Medizin und
Biologie 29 (3-4/1998), S. 221 – 241 Elsevier Verlag, Jena, 1998
210
http://www11.informatik.tu-
Literaturnachweis
[Spi04]
Spiegel: "Arafat-Tod: Keine Anzeichen für Giftanschlag", Spiegel online, 2004,
http://www.spiegel.de/politik/ausland/0,1518,329107,00.html
[VC#H]
Visual C# Home: http://www.msdn.microsoft.com/vcsharp/
[VKF04]
Voelker, W., Koch, D., Flachskampf, F. et al.: Strukturierter Datensatz zur
Befunddokumentation in der Echokardiographie - Version 2004. Herausgegeben vom
Vorstand der Deutschen Gesellschaft für Kardiologie - Herz- und Kreislaufforschung
e.V., 2004, www.dgk.org/leitlinien/StrukurierterDatensatzZurBefundDokumentation.pdf
[VIRT]
Internetpräsenz des Projektes VIRTLab: http://www.offis.de/virtlab/
[Voc02]
Vocke, W.: Anwendung von Videokompressionsalgorithmen zur Datenreduktion
koronarangiographischer Untersuchungen, MD Thesis, Medizinische Hochschule
Hannover (2002)
[WABH02]
Winter, A., Ammenwerth, E., Brigl, B., Haux, R.: Krankenhausinformationssysteme. In
[LMB02] S. 474 ff.
[WBW03]
Winter, A., Brigl, B., Wendt, T.: Modelling Hospital Information Systems (Part 1): The
Revised Three Layer Graph-Based Meta model 3LGM2. Methods Inf Med 2003, 42 (5):
S. 544 - 551
[Wee68]
Weed, L. L.: Medical records that guide and teach, N Engl J Med. 1968; 278:652-7.
[WER04]
Wilkens, T., Eichelberg, M., Riesmeier, J.: IHE 2004 - aktueller Stand und neue
Integrationsprofile, 11. interdisziplinärer Workshop KIS/RIS/PACS, Rauischholzhausen,
2004
[WFMC]
Workflow-Management-Coalition, http://www.wfmc.org
[Wil04]
Wilkens, A.: Microsoft-Betriebssysteme dominieren weiter, heise-online, Hannover,
2004, http://www.heise.de/newsticker/meldung/40917
[WR97]
Wondrow, M., Roehm, S..: The Digital Cardiac Catheterization Laboratory (Basic
st
Principles). Cardiac Imaging in the 21 Century: A Primer; S. 124 – 127, Maryland,
1997.
[WV02]
Wiesmann, D., Voelker, W.: Interventionelle Kardiologie / EDV im Herzkatheterlabor in
Deutschland - eine aktuelle Bestandsaufnahme, CardioNews 12/02
[XDT]
Schnittstellenbeschreibung
für
Datenträgeraustausch
der
http://www.kbv.de/it/schnittstellen.htm und http://www.kbv.de/it/xdtinfo.htm
KBV
211
Abkürzungen und Glossar
Anhang B: Abkürzungen und Glossar
ADT
Abrechnungsdatentransfer, auch als Abrechnungsdatenträger bezeichnet. Hier ist die
Nomenklatur seitens der (→ KBV) nicht einheitlich. Der ADT dient zum
standardisierten Datenaustausch zwischen Arztpraxen und der (→ KBV).
Arterie
Vom Herzen wegführendes Blutgefäß.
AIS
Abteilungsinformationssystem.
Akinesie
Bewegungsarmut. Bezogen auf die Herzwand bezeichnet dies die fehlende
Einwärtsbewegung von Regionen der Herzwand während der Systole. Dadurch wird
weniger Blut aus der Herzkammer gepumpt.
Aneurysma
Permanente Erweiterung des Arterienquerschnittes in Folge erworbener oder
angeborener Schädigung der inneren Arterienwand. Durch diese dringt Blut zwischen
die Gefäßwände und bildet dort sack- oder spindelförmige Erweiterungen, die in der
Regel thrombosieren. Aneurysmen sind insofern gefährlich, dass sie einen hohen
Druck auf die Gefäßwand ausüben, welche rupturieren, also einreißen, kann. Dann
ergießt sich Blut und thrombotisches Material, was zu inneren Blutungen und
Gefäßverschlüssen führen kann.
Angioplastie
Aufdehnung von Arterien mit Hilfe koaxialer Katheter. Angioplastien an den
Koronargefäßen werden als (→ Koronarangioplastien) bezeichnet.
API
Application Programming Interface, Schnittstelle um auf Funktionen, die das
Betriebssystem zur Programmierung von Applikationen bereitstellt, zuzugreifen.
ASD
Atriumseptumdefekt (→ Vorhofseptumdefekt), Atrium lat. für Vorhof.
Ätiologie
Lehre der Ursachen, im medizinischen Kontext Grund für eine Erkrankung.
Atherosklerose siehe (→ Arteriosklerose).
Arteriosklerose Arterienverkalkung durch Ablagerung an den Gefäßwänden.
BDT
Behandlungsdatentransfer, auch als Behandlungsdatenträger bezeichnet. Hier ist die
Nomenklatur seitens der (→ KBV) nicht einheitlich. Der BDT dient zum
standardisierten Datenaustausch zwischen Praxeninformationssystemen.
BQS
Bundesgeschäftsstelle Qualitätssicherung.
Bradykardie
Zu geringe Herzfrequenz von weniger als 40 Schlägen/Min.
Control
Allgemeine Bezeichnung für ein Steuerelement der Benutzungsoberfläche in .NET.
Beispiele für Controls sind Texteingabefelder, Anhakfelder, Tabellen, Auswahllisten,
Schaltflächen oder Schieberegler.
CSCW
Computer Supported Cooperative Work. Allgemeiner Oberbegriff, welcher Systeme
zur Unterstützung von Arbeitsgruppen in vernetzten Umgebungen zusammenfasst.
DBMS
Database Management System.
DEA
Deterministischer endlicher Automat, Endlicher Automat der unter Eingabe eines
Zeichens einen eindeutigen Folgezustand annimmt. DEAs können partiell definiert
werden. In diesem Fall ist in der Übergangstabelle nicht jede Kombination aus
213
Abkürzungen und Glossar
Zustand und Eingabe vermerkt. Es wird dann angenommen, dass ungültige
Kombinationen einen zu einem Zustandswechsel in einen Fehlerzustand führen. Der
in dieser Arbeit in Abschnitt 4.9 definierte DEA ist partiell definiert, da Übergänge auf
Grund vorher festgelegter Regeln, die medizinische Rahmenbedingungen bei der
Behandlung widerspiegeln, nicht auftreten können.
DGK
Deutsche Gesellschaft für Kardiologie.
Diastole
Erschlaffen des Herzmuskels, also Ausdehnen der Herzkammern und damit
Ansaugen von Blut in das Herz.
DICOM
Digital Imaging and Communications in Medicine.
Dilatation
Hohlorganaufdehnung, in der Kardiologie Aufdehnung von Arterien.
DMM
Dreiphasige Medizinische Maßnahme; Medizinische Maßnahme, die in Vorbereitung,
Durchführung und Nachbereitung eingeteilt werden kann.
EF
Ejektionsfraktion, Die EF wird in % gemessen und gibt das Verhältnis zwischen dem
Blutvolumen welches bei einem Herzzyklus in eine Herzkammer strömt und wieder
durch sie weggepumpt wird an. Eine EF von 100 % würde bedeuten, dass alles Blut
aus der Kammer gepresst würde, ein Wert von 0 %, dass kein Blut die Kammer
verlässt. Mit EF wird in der Regel die EF des linken Ventrikels bezeichnet, da der
linke Ventrikel die wichtigste Herzkammer des Menschen ist. Ebenso kann auch die
EF des rechten Ventrikels (RVEF) bestimmt werden. Bei einem gesunden Menschen
soll die EF über 60% liegen. Bei Werten darunter ist der linke Ventrikel erkrankt. Je
niedriger die EF ist desto geringer ist die Pumpleistung des Herzens.
EGA
Elektronische Gesundheitsakte.
EKA
Elektronische Krankenakte.
ER
Entity Relationship, wird meist im Zusammenhang mit Datenbanken als ER-Modell
verwendet und wurde 1976 erstmals in [Chen76] vorgestellt. Das ER-Modell ist die
konzeptionelle Darstellung, die den modellierten Weltausschnitt als Entitäten und
Beziehungen zwischen diesen darstellt. Die Basis bildet dazu eine grafische
Repräsentationsform. Es gibt Methoden um aus dem ER-Modell direkt Kommandos
zum Erstellen der Struktur innerhalb von (→ DBMSen) zu generieren.
ERP-Systeme Enterprise-Resource-Planning-Systeme, Software, die in großen Unternehmen
unterstützend zur möglichst effizienten Planung betrieblicher Abläufe und
Ressourcennutzung verwendet wird.
Elektiv
In der Klinik wird die Dringlichkeit einer Untersuchung in verschiedene Kategorien
eingeteilt. Diese sind zumeist "Elektiv", "Dringlich" und "Notfall". Notfälle müssen
unverzüglich und "Dringliche" Fälle möglichst schnell, also sobald Ressourcen zur
Verfügung stehen, versorgt werden. Elektive Fälle bezeichnen den Rest, der zwar
zeitnah behandelt werden soll, es aber auf einen Tag früher oder später nicht
ankommt.
EPA
Elektronische Patientenakte.
ESC
European Society of Cardiology, Europäischer Kardiologenverband.
Eventhandler
Spezielle Methode in einer Klasse, welche auf Ereignisse reagiert. In C# werden den
Eventhandlern Ereignisse zugeordnet. Tritt dieses Ereignis ein, so wird der Code im
zugehörigen Eventhandler ausgeführt. Ein Beispiel hierfür sind z. B. die Eventhandler
vom Typ RowSelected. Deren Code wird ausgeführt, sobald eine Zeile in einer
Auswahlliste per Doppelklick ausgewählt wurde.
GDT
Gerätedatentransfer, auch als Gerätedatenträger bezeichnet. Hier ist die
Nomenklatur seitens der (→ KBV) nicht einheitlich. Der GDT dient zum
214
Abkürzungen und Glossar
standardisierten Datenaustausch
medizinischen Geräten
zwischen
Praxeninformationssystemen
und
G-DRG
German Refined - Diagnosis Related Group, In Deutschland seit dem 1.1.2004
anzuwendendes Abrechnungssystem. Für die Einführung dieses pauschalierenden
Entgeltsystems sind nach § 17 b des Krankenhausgesetzes (KHG) die Deutsche
Krankenhausgesellschaft (DKG), die Spitzenverbände der Krankenkassen (GKV)
und der Verband der privaten Krankenversicherung (PKV) gemeinsam zuständig.
GO#
Bezeichnung der Software-Architektur, die in OFFIS im Rahmen des Projektes GOKard implementiert wurde und die praktische Umsetzung der in Kapitel vorgestellten
Software-Architektur ist.
GS-View
Basisklasse auf der alle Komponenten der (→ GO#)-Architektur basieren.
GUI
Graphical User Interface, Methode zur Interaktion des Anwenders mit dem Computer
durch eine grafische Benutzungsoberfläche. GUIs unterliegen meist einem gewissen
Design (Look & Feel). Diese orientieren sich meist an den Vorgaben des zu Grunde
liegenden Betriebssystems wie z. B. Windows oder Mac OS.
HK
Herzkatheter, bezeichnet im Sprachgebrauch auch die Herzkatheteruntersuchung;
Bei dieser wird ein Katheter durch einen kleinen Schnitt in der Leiste und dann durch
die Aorta bis zum Herzen vorgeführt. Mit diesem können diagnostische und
therapeutische Verfahren, insbesondere an den Herzkranzgefäßen, durchgeführt
werden.
HK-Labor
Herzkatheterlabor; Spezieller medizinischer Untersuchungsraum in dem ein
medizinisches Großgerät zur Durchführung der (→ HK) fest installiert ist. Diese
Geräte besitzen ein bis zwei rotierbare, boden- oder deckenmontierte Röntgenröhren
und einen eigenen Untersuchungstisch. Dazu verfügen sie über diverses
zusätzliches medizinisches Gerät zur Durchführung der (→ HK) und für
Notfallmaßnahmen.
HL7
Health Level 7, Standard
Informationssystemen.
Hypokinesie
Störung der Beweglichkeit der Herzwand, meistens Bewegungslosigkeit sowohl
während (→ Systole) als auch (→ Diastole), wodurch dieser Bereich des Herzens
nicht mehr zum Pumpen genutzt wird.
ICD
International Classification of Diagnosis; Dieses Codierungsschema für Diagnosen
muss in Deutschland zur Übermittlung der bei einem Patienten gestellten Diagnosen
an die Krankenkassen verwendet werden. Derzeit ist Version 10 des ICD gültig. Die
mit diesem Code gestellten Diagnosen stellen keine detaillierten medizinischen
Informationen zu einem Krankheitsbild zur Verfügung und finden deswegen bei der
medizinischen Dokumentation in der Praxis nur zum Erstellen einer groben Übersicht
über das Krankheitsbild, zur Abrechnung und für statistische Auswertungen
Anwendung.
Initializer
Zentrale Komponente der (→ GO#)-Architektur, über welche die Kommunikation
zwischen den einzelnen Komponenten eines Programms und die Initialisierung der
Applikation gesteuert wird.
IuK-System
Informations- und Kommunikationssystem.
KBV
Kassenärztliche Bundesvereinigung, Bundesdachverband der einzelnen Landes- (→
KVen).
KHK
Koronare Herzerkrankung, Erkrankung der Herzkranzgefäße, meistens auf Grund
von (→ Atherosklerose).
zum
Datenaustausch
zwischen
medizinischen
215
Abkürzungen und Glossar
KIS
Klinikinformationssystem.
KV
Kassenärztliche Vereinigung, Zusammenschluss der niedergelassenen Ärzte,
welcher direkter Verhandlungspartner der Krankenkassen ist. In jedem Bundesland
gibt es eine eigenständige KV, welche eigene, bundeslandbezogene Verhandlungen
mit den Krankenkassen führen kann. Diese werden lose durch die (→ KBV) als
nationales Gremium, welches aber gegenüber den Bundesmitgliedern nur
Vorschläge einbringen kann, zusammengehalten. Die KVen garantieren in
Deutschland die medizinische Versorgung der Bevölkerung. Im Gegenzug
garantieren die Krankenkassen mit Unterstützung des Gesundheitsministeriums die
Finanzierung der KVen.
Konsil
Ärztliche Leistung die von einer anderen Fachabteilung angefordert und durch eine
Arzt dieser anderen Fachrichtung durchgeführt wird.
LDT
Labordatentransfer, auch als Labordatenträger bezeichnet. Hier ist die Nomenklatur
seitens der (→ KBV) nicht einheitlich. Der LDT dient zum standardisierten
Datenaustausch zwischen Praxeninformationssystemen und Laboren.
MSF
Medizinischer Serviceflow, Spezialisierter (→ SF), welcher Anforderungen
bestimmter Definition, die in dieser Arbeit vorgestellten werden, gerecht wird.
MSP
Medizinischer Servicepoint, Spezialisierter (→ SP), welcher Anforderungen
bestimmter Definition, die in dieser Arbeit vorgestellten werden, gerecht wird.
Morphologie
Formenlehre; von Göthe geprägter Begriff für die Lehre von Form und Struktur
lebender Organismen.
Monozyten
Spezielle Form der Leukozyten (weiße Blutkörperchen).
MVC
Entwurfsmuster
zur
Implementierung
interaktiver
Model-View-Controller,
Anwendungen bei dem Datenhaltung, Oberflächenelemente und Steuerungslogik in
drei unterschiedlichen Komponenten implementiert werden.
NDEA
Nichtdeterministischer endlicher Automat. Im Gegensatz zum (→ DEA) kann es bei
einem NDEA für den Zustandsübergang mehrere Möglichkeiten geben. NDEA, (→
DEA) und Chomsky-3-Grammatiken bilden dieselbe Sprachklasse ab. Somit könnte
der Automaten aus Abschnitt 4.9 auch als NDEA realisiert werden, was aber aus den
dort genannten Gründen nicht gemacht wurde.
OPS301
nach
§
301
des
Sozialgesetzbuchs.
Dieses
Operationenschlüssel
Codierungsschema für medizinische Verfahren muss in Deutschland zur
Übermittlung der bei einem Patienten angewandten Behandlungen an die
Krankenkassen verwendet werden. Derzeit ist Version 2005 des OPS301 gültig,
welcher einer deutschen Modifikation des international anerkannten Codierstandards
ICPM (International Classification of Procedures in Medicine) entspricht. Die mit
diesem Code verschlüsselten Verfahren stellen keine detaillierten medizinischen
Informationen zur Verfügung und finden deswegen bei der medizinischen
Dokumentation in der Praxis nur zum Erstellen einer groben Übersicht über die
durchgeführten medizinischen Leistungen, zur Abrechnung und für statistische
Auswertungen Anwendung.
Ostium
Gefäßabgang, Anfang eines Gefäßes kurz nach der Verzweigung aus einem andern
Gefäß, meist im Zusammenhang mit den drei großen Herzkranzgefäßen oder großen
Arterien des Körpers verwendet.
Pathologisch
Abweichend von der Norm; im medizinischen Kontext als Befundung von
Krankheitszeichen, die technisch nachgewiesen werden können, verwendet;
abgeleitet von der pathologischen Anatomie, der Lehre der mikro- und
216
Abkürzungen und Glossar
makroskopisch fassbaren, krankhaften Veränderung von Organen und deren
Ursache (frei nach http://www.hessenweb-kreation.de/medwort/1835.htm).
Pathophysiologisch krankhaft gestörter (→ physiologischer) Vorgang; (→ pathologisch) bedingte
Veränderung von Organfunktionen.
Physiologisch
Für die Lebensvorgänge eines Menschen normal bzw. richtig; auch im Sinne von
gesund.
Plaque
Französisch für "Platte"; im medizinischen Kontext im Zusammenhang mit
Gefäßerkrankung bezeichnet der Plaque eine Ablagerung an der Gefäßinnenwand.
Procedere
Vorschlag für die kurzfristige weitere Behandlung des Patienten, in der Regel in der
Klinik. Dies kann sowohl Hinweise für die stationäre Betreuung, z. B. hinsichtlich der
Medikamentengabe, als auch Empfehlungen für die nächste durchzuführende
medizinische Maßnahme, z. B. Empfehlung zur Bypass-Operation nach einem
diagnostischen Herzkatheter, sein.
PS
Patientenstatus, in dieser Arbeit definiertes Quintupel, welches aktuelle
Informationen über einen Patienten im Rahmen seines Krankenhausaufenthaltes
enthält.
PTA
perkutaneous transluminal angioplasty, Abkürzung für die minimalinvasiv
durchgeführte (→ Angioplastie), wie sie in modernen Herzkatheterlaboren erfolgt; im
Gegensatz zur PTCA wird hiermit die Angioplastie einer Arterien, die nicht zu den
Herzkranzgefäßen gehört, bezeichnet.
PTCA
perkutaneous transluminal coronary angioplasty, Abkürzung für die minimalinvasiv
durchgeführte Koronarangioplastie, wie sie in modernen (→ HK-Laboren) erfolgt.
RDBMS
Relational Database Management System.
Septum
Trennwand zwischen der rechten und der linken Seite des Herzens.
SF
Serviceflow.
SFM
Serviceflow-Management.
SK
Strukturierte Krankenakte, in dieser Arbeit definiertes Tupel zur Speicherung von
Informationen zum Krankheitsverlauf.
SP
Servicepoint; Punkt an dem Dienstleistungen innerhalb des (→ SF) erbracht werden
Stenose
Verengung oder Verschluss eines Gefäßes, im medizinischen Sinn einer Arterie;
Abgeleitet vom griechischen "steno": Enge.
Stent
Gefäßstütze, welche zur Fixierung von Kalkablagerungen dient und ein
Zusammenfallen des Gefäßes oder erneutes Ausbilden von stenotischem Material
verhindern soll. Der Stent besteht aus einem dünnen Gitternetz aus Edelstahl,
welches bei modernen Stents mit athrombotischem Material oder einem
Medikamente freisetzenden Träger beschichtet werden kann.
Systole
Zusammenziehen des Herzmuskels wodurch das Blut aus dem Herzen gepumpt
wird.
Tachykardie
Zu hohe Herzfrequenz von mehr als 180 Schlägen/Min.
Thrombus
Blutgerinnsel.
V. a.
Abkürzung für "Verdacht auf". Wird häufig in Kombination mit einem Krankheitsbild,
z. B. "V. a. KHK" oder "V. a. Herzklappenerkrankung", als Indikation für diagnostische
Verfahren verwendet.
Vene
Zum Herzen führendes Blutgefäß.
217
Abkürzungen und Glossar
Ventrikel
Hauptkammern des Herzens; Das menschliche Herz besitzt einen rechten und einen
linken Ventrikel. Der rechte Ventrikel pumpt das Blut durch den rechten Vorhof und
die Pulmonalarterie in die Lunge wo es mit Sauerstoff angereichert wird. Von dort
gelangt es durch die Pulmonalvene in den linken Ventrikel, der sehr viel kräftiger ist
und das Blut durch den Körper pumpt. Durch die Venen gelangt es wieder in den
rechten Ventrikel von wo aus der Zyklus von vorne beginnt.
Ventrikelseptum Trennwand zwischen dem linken und dem rechten Ventrikel.
Vorhofseptum
Trennwand zwischen dem linken und dem rechten Vorhof.
VSD
siehe (→ Ventrikelseptumdefekt).
WfMS
Workflow-Management-System.
218
Definitionen zum MSF-Beispiel aus Kapitel 4
Anhang C: Definitionen zum MSF-Beispiel aus Kapitel 4
Im Folgenden werden Definitionen und Erläuterungen zum Datenmodell des in Kapitel 4
vorgestellten Beispiels angeführt. Diese bestehen zunächst aus der Aufzählung der
Relationen innerhalb der einzelnen Subdatenschemata. Danach werden die Tabellen,
Attribute, ihre Merkmale und eine kurze Beschreibung aufgeführt.
Es wird ein Beispiel für eine SK zur Dokumentation eines Standardaufenthalts, der prima
vista Dilatation, in einer Kardiologie modelliert. Bei diesem Aufenthalt wird der Patient
stationär aufgenommen, am nächsten Tag im HK-Labor behandelt und am folgenden Tag
bei
komplikationslosem
Verlauf
entlassen.
Zur
Dokumentation
müssen
Patientenstammdaten, Aufenthaltsinformationen, Daten über den stationären Verlauf und
den Eingriff im HK-Labor dokumentiert werden. Zusätzlich werden noch Codelisten benötigt.
Definition der SK mit SK = (P, A, L1, L2, C)
P = {Stammdaten}
Stammdaten = (Stammdaten.pid, Stammdaten.Name, Stammdaten.Vorname,
Stammdaten.Geboren, Stammdaten.Strasse, Stammdaten.PLZ,
Stammdaten.Ort, Stammdaten.Telefon, Stammdaten.Krankenkasse)
A = {Aufenthalt}
Aufenthalt = (Aufenthalt.pid, Aufenthalt.anr, Aufenthalt.Von, Aufenthalt.Bis,
Aufenthalt.Eingriff, Aufenthalt.Ort, Aufenthalt.KISNR)
L1 = {Station, StaProtokoll, StaMaterial, StaICD, StaOPS}
Station = (Station.anr, Station.doknr, Station.Start, Station.Stop, Station.Station,
Station.Arzt, Station.Indikation, Station.Komplikation, Station.Befund,
Station.Diagnose, Station.Procedere, Station.Therapieempfehlung)
StaProtokoll = (StaProtokoll.doknr, StaProtokoll.Zeit, StaProtokoll.Text)
StaMaterial = (StaMaterial.doknr, StaMaterial.Material)
StaICD = (StaICD.doknr, StaICD.ICDNR)
StaOPS = (StaOPS.doknr, StaOPS.OPSNR)
L2 = {HK, HKProtokoll, HKMaterial, HKStenose, HKDilatation, HKICD, HKOPS}
HK = (HK.anr, HK.doknr, HK.Start, HK.Stopp, HK.Labor, HK.Untersucher, HK.EF,
HK.PAoAscSys, HK.PAoAscDia, HK.PAoAscMed, HK.Indikation, HK.Komplikation,
HK.Befund, HK.Diagnose, HK.Procedere, HK.Therapieempfehlung)
HKProtokoll = (HKProtokoll.doknr, HKProtokoll.Zeit, HKProtokoll.Text)
219
Definitionen zum MSF-Beispiel aus Kapitel 4
HKMaterial = (HKMaterial.doknr, HKMaterial.Material),
HKStenose = (HKStenose.doknr, HKStenose.Gefäß, HKStenose.Stenosegrad)
HKDilatation = (HKDilatation.doknr, HKDilatation.Gefäß, HKDilatation.StenosePrä,
HKDilatation.StenosePost, HKDilatation.Verfahren)
HKICD = (HKICD.doknr, HKICD.ICDNR)
HKOPS = (HKOPS.doknr, HKOPS.OPSNR)
C = {ArztCode, IndikationCode, GefaessCode, ICDCode, OPSCode}
ArztCode = (ArztCode.Code)
IndikationCode = (IndikationCode.Code, ICD)
ICDCode = (ICDCode.ICDNR, ICDCode.ICDText, ICDCode.Version)
OPSCode = (OPSCode.OPSNR, OPSCode.OPSText, OPSCode.Version)
220
Definitionen zum MSF-Beispiel aus Kapitel 4
Merkmale der einzelnen Tabellen und Attribute:
Relation: Stammdaten
Aufgabe: Beinhaltet Patientenstammdaten
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
Stammdaten.pid
Eindeutige ID-Nummer des Patienten
ID-Feld
20
--
--
--
--
Stammdaten.Name
Nachname des Patienten
Freitext
50
--
--
--
--
Stammdaten.Vorname
Vorname des Patienten
Freitext
40
--
--
--
--
Stammdaten.Geboren
Geburtsdatum des Patienten
Zeitfeld
10
--
--
--
--
Stammdaten.Strasse
Strasse und Hausnummer
Freitext
50
--
--
--
--
Stammdaten.PLZ
Postleitzahl, ggf. mit Landeskennung
Freitext
10
--
--
--
--
Stammdaten.Ort
Wohnort
Freitext
50
--
--
--
--
Stammdaten.Telefon
Telefonnummer
Freitext
20
--
--
--
--
Stammdaten.Krankenkasse
Krankenkasse
Freitext
50
--
--
--
--
221
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: Aufenthalt
Aufgabe: Beinhaltet die Daten zu einem anamnestischen Ereignis, welches auch ein Aufenthalt in einer medizinischen Institution sein kann.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
Aufenthalt.pid
Referenz auf die ID des Patienten Stammdaten.pid
ID-Feld
20
--
--
--
--
Aufenthalt.anr
Eindeutige Nummer des anamnestischen Ereignis
ID-Feld
20
--
--
--
--
Aufenthalt.Von
Datum an dem das anamnestische Ereignis beginnt
Zeitfeld
10
--
--
--
--
Aufenthalt.Bis
Datum an dem das anamnestische Ereignis endet
Zeitfeld
10
--
--
--
--
Aufenthalt.Eingriff
Beschreibung des anamnestischen Ereignis
Freitext
2000
--
--
--
--
Aufenthalt.Ort
Ort an dem das Ereignis stattfand
Freitext
50
--
--
--
--
Aufenthalt.KISNR
Aufenthaltsnummer im Fremdsystem, meist KIS.
Dieses Feld wird nur für Aufenthalte in Institutionen
gefüllt, die über ein KIS verfügen und eine
Aufnahmenummer führen.
Freitext
20
--
--
--
--
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
Relation: StaMaterial
Aufgabe: Beinhaltet den Materialverbrauch zu einem stationären Aufenthalt.
Name
Bedeutung
Datent
yp
StaMaterial.doknr
Referenz auf die ID des Stationsaufenthalts Station.doknr
ID-Feld
20
--
--
--
--
StaMaterial.Material
Verbrauchtes Material
Freitext
500
--
--
--
--
222
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: Station
Aufgabe: Beinhaltet die Daten zu einem stationären Aufenthalt.
Name
Bedeutung
Datentyp
des
Einheit
Codetabelle
Min/
Max
Normbereich
ID-Feld
20
--
--
--
--
ID-Feld
20
--
--
--
--
Station.anr
Referenz
auf
die
anamnestischen Eintrags
Station.doknr
Eindeutige Nummer des Stationsaufenthalts
Station.Start
Datum
und
Uhrzeit
Stationsaufenthalt beginnt
an
dem
der
Zeitfeld
18
--
--
--
--
Station.Stop
Datum
und
Uhrzeit
Stationsaufenthalt endet
an
dem
der
Zeitfeld
18
--
--
--
--
Station.Station
Name der Station
Freitext
50
--
--
--
--
Station.Arzt
Arzt, der für die Stationsaufnahme zuständig ist
Freitext
40
--
ArztCode
--
--
Station.Indikation
Indikation für die Stationsaufnahme
Freitext
50
--
--
--
--
Station.Komplikation
Komplikationen
Freitext
200
--
--
--
--
Station.Befund
Stationärer Befund
Freitext
2000
--
--
--
--
Station.Diagnose
Diagnose
Freitext
2000
--
--
--
--
Station.Procedere
Geplantes Procedere
Freitext
2000
--
--
--
--
Station.Therapieempfehlung
Therapieempfehlung
Freitext
2000
--
--
--
--
223
ID-Nummer
Dimension
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: StaProtokoll
Aufgabe: Beinhaltet das Verlaufsprotokoll zu einem stationären Aufenthalt.
Name
Bedeutung
StaProtokoll.doknr
Referenz auf die ID des Stationsaufenthalts Station.doknr
StaProtokoll.Zeit
StaProtokoll.Text
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
ID-Feld
20
--
--
--
--
Datum und Uhrzeit des Eintrags
Zeitfeld
20
--
--
--
--
Eintrag im Verlaufsprotokoll
Freitext
500
--
--
--
--
Relation: StaICD
Aufgabe: Beinhaltet die Diagnosen als ICD-Codes zu einem stationären Aufenthalt.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
StaICD.doknr
Referenz auf die ID des Stationsaufenthalts Station.doknr
ID-Feld
20
--
--
--
--
StaICD.ICDNR
Diagnosenummer nach ICD-Code verschlüsselt
Freitext
10
--
ICDCode
--
--
Relation: StaOPS
Aufgabe: Beinhaltet die Therapien als OPS-Codes zu einem stationären Aufenthalt.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
StaOPS.doknr
Referenz auf die ID des Stationsaufenthalts Station.doknr
ID-Feld
20
--
--
--
--
StaOPS.OPSNR
Therapienummer nach OPS-Code verschlüsselt
Freitext
10
--
OPSCode
--
--
224
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: HK
Aufgabe: Beinhaltet die Daten zu einer Herzkatheteruntersuchung (HK).
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
HK.anr
Referenz auf ID-Nummer des anamnestischen
Eintrags
ID-Feld
20
--
--
--
--
HK.doknr
Eindeutige Nummer des Stationsaufenthalts
ID-Feld
20
--
--
--
--
HK.Start
Datum und Uhrzeit an dem die HK beginnt
Zeitfeld
18
--
--
--
--
HK.Stopp
Datum und Uhrzeit an dem die HK endet
Zeitfeld
18
--
--
--
--
HK.Labor
Name des Labors in dem die Untersuchung
stattfindet
Freitext
50
--
--
--
--
HK.Untersucher
Arzt, der für die HK zuständig ist
Freitext
40
--
ArztCode
--
--
HK.EF
Ejektionsfraktion des linken Ventrikels in %
Freitext
2
%
--
15/89
60 - 80
HK.PAoAscSys
Systolischer Druck in der Aorta ascendens in
mmHg
Freitext
3
mmHg
--
70/350
110-130
HK.PAoAscDia
Diastolischer Druck in der Aorta ascendens in
mmHg
Freitext
3
mmHg
--
40/199
70 - 90
HK.Indikation
Indikation für die HK
Freitext
50
--
--
--
--
HK.Komplikation
Komplikationen
Freitext
200
--
--
--
--
HK.Befund
Befund
Freitext
2000
--
--
--
--
HK.Diagnose
Diagnose
Freitext
2000
--
--
--
--
HK.Procedere
Geplantes Procedere
Freitext
2000
--
--
--
--
HK.Therapieempfehlung
Therapieempfehlung
Freitext
2000
--
--
--
--
225
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: HKProtokoll
Aufgabe: Beinhaltet das Verlaufsprotokoll zu einer HK.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
HKProtokoll.doknr
Referenz auf die ID des Stationsaufenthalts HK.doknr
ID-Feld
20
--
--
--
--
HKProtokoll.Zeit
Datum und Uhrzeit des Eintrags
Zeitfeld
20
--
--
--
--
HKProtokoll.Text
Eintrag im Verlaufsprotokoll
Freitext
500
--
--
--
--
Dimension
Einheit
Codetabelle
Relation: HKMaterial
Aufgabe: Beinhaltet den Materialverbrauch zu einer HK.
Name
Bedeutung
Datentyp
Min/
Max
Normbereich
HKMaterial.doknr
Referenz auf die ID des Stationsaufenthalts HK.doknr
ID-Feld
20
--
--
--
--
HKMaterial.Material
Verbrauchtes Material
Freitext
500
--
--
--
--
Relation: HKStenose
Aufgabe: Beinhaltet die Dokumentation von Stenosen
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/ Max
Normbereich
HKStenose.doknr
Referenz auf die ID des Stationsaufenthalts
HK.doknr
ID-Feld
20
--
--
--
--
HKStenose.Gefäß
Gefäß in dem die Stenose diagnostiziert wurde
Freitext
100
--
--
--
--
HKStenose.Stenosegrad
Stenosegrad in %
Messwert
3
%
--
0 / 100
0 - 10
226
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: HKDilatation
Aufgabe: Beinhaltet die Daten einer Dilatation, die im Rahmen dieser HK durchgeführt wurde. Wurde keine Dilatation durchgeführt, sind zu der
HK hier keine Daten enthalten.
Name
Bedeutung
ID-Nummer
Datentyp
des
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
ID-Feld
20
--
--
--
--
100
--
GefaessCode
--
--
HKDilatation.doknr
Referenz
auf
die
Stationsaufenthalts HK.doknr
HKDilatation.Gefäß
Gefäß, das behandelt wurde
Freitext
HKDilatation.StenosePrä
Stenosegrad vor der Dilatation
Messwert
3
%
--
0/
100
70-100
HKDilatation.StenosePost
Stenosegrad nach der Dilatation
Messwert
3
%
--
0/
100
0-30
HKDilatation.Verfahren
Angewendetes Verfahren
Freitext
30
--
--
--
--
Datentyp
Dimension
Einheit
Codetabelle
Relation: HKICD
Aufgabe: Beinhaltet die Diagnosen als ICD-Codes zu einer HK.
Name
Bedeutung
Min/
Max
Normbereich
HKICD.doknr
Referenz auf die ID-Nummer des Stationsaufenthalts
HK.doknr
ID-Feld
20
--
--
--
--
HKICD.ICDNR
Diagnosenummer nach ICD-Code verschlüsselt
Freitext
10
--
ICDCode
--
--
227
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: HKOPS
Aufgabe: Beinhaltet die Therapien als OPS-Codes zu einer HK.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
HKOPS.doknr
Referenz auf die ID-Nummer des Stationsaufenthalts
HK.doknr
ID-Feld
20
--
--
--
--
HKOPS.OPSNR
Therapienummer nach OPS-Code verschlüsselt
Freitext
10
--
OPSCode
--
--
Dimension
Einheit
Codetabelle
40
--
--
Dimension
Einheit
Codetabelle
Relation: ArztCode
Aufgabe: Beinhaltet die Codeliste der Ärzte.
Name
ArztCode.Code
Bedeutung
Name des Arztes
Datentyp
Freitext
Min/
Max
--
Normbereich
--
Relation: IndikationCode
Aufgabe: Beinhaltet die Indikationstexte und ICD-Codes, die den Indikationen entsprechen.
Name
Bedeutung
Datentyp
Min/
Max
Normbereich
IndikationCode.Code
Indikation
ID-Feld
20
--
--
--
--
IndikationCode.ICD
ICD-Codes, der der Indikation entspricht
Freitext
10
--
ICDCode
--
--
228
Definitionen zum MSF-Beispiel aus Kapitel 4
Relation: ICDCode
Aufgabe: Beinhaltet die ICD-Codes zur Diagnoseverschlüsselung mit den zugehörigen Texten.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
ICDCode.ICDNR
ICD-Nummer
Freitext
10
--
--
--
--
ICDCode.ICDText
Amtlicher Text, der die Diagnose beschreibt
Freitext
250
--
--
--
--
ICDCode.Version
Name der Version des ICD-Katalogs
Freitext
10
--
--
--
--
Dimension
Einheit
Codetabelle
Relation: OPSCode
Aufgabe: Beinhaltet die OPS-Codes zur Therapieverschlüsselung mit den zugehörigen Texten.
Name
Bedeutung
Datentyp
Min/
Max
Normbereich
OPSCode.OPSNR
ICD-Nummer
Freitext
10
--
--
--
--
OPSCode.OPSText
Amtlicher Text, der die Therapie beschreibt
Freitext
250
--
--
--
--
OPSCode.Version
Name der Version des OPS-Katalogs
Freitext
10
--
--
--
--
229
Definitionen zum PS aus Kapitel 5
Anhang D: Definitionen zum PS aus Kapitel 5
Im Folgenden werden Definitionen und Erläuterung zum Datenmodell des in Kapitel 5 vorgestellten PS angeführt. Es werden die
Tabellen, Attribute, ihre Merkmale und ein kurze Beschreibung aufgeführt.
Merkmale der einzelnen Tabellen und Attribute:
Relation: P_Stammdaten
Aufgabe: Beinhaltet Patientenstammdaten
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
P_Stammdaten.pid
Eindeutige ID-Nummer des Patienten
ID-Feld
20
--
--
--
--
P_Stammdaten.Name
Nachname des Patienten
Freitext
50
--
--
--
--
P_Stammdaten.Vorname
Vorname des Patienten
Freitext
40
--
--
--
--
P_Stammdaten.Geboren
Geburtsdatum des Patienten
Zeitfeld
10
--
--
--
--
P_Stammdaten.Strasse
Strasse und Hausnummer
Freitext
50
--
--
--
--
P_Stammdaten.PLZ
Postleitzahl, ggf. mit Landeskennung
Freitext
10
--
--
--
--
P_Stammdaten.Ort
Wohnort
Freitext
50
--
--
--
--
230
Definitionen zum PS aus Kapitel 5
Relation: P_Aufenthalt
Aufgabe: Beinhaltet die Daten zu einem anamnestischen Ereignis, welches auch ein Aufenthalt in einer medizinischen Institution sein kann.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
P_Aufenthalt.pid
Referenz auf die ID des Patienten P_Stammdaten.pid
ID-Feld
20
--
--
--
--
P_Aufenthalt.anr
Eindeutige Nummer des anamnestischen Ereignis
ID-Feld
20
--
--
--
--
P_Aufenthalt.Von
Datum an dem das anamnestische Ereignis beginnt
Zeitfeld
10
--
--
--
--
P_Aufenthalt.Bis
Datum an dem das anamnestische Ereignis endet
Zeitfeld
10
--
--
--
--
P_Aufenthalt.Eingriff
Beschreibung des anamnestischen Ereignis
Freitext
2000
--
--
--
--
P_Aufenthalt.Ort
Ort an dem das Ereignis stattfand
Freitext
50
--
--
--
--
P_Aufenthalt.KISNR
Aufenthaltsnummer im Fremdsystem (KIS). Wird nur in
Institutionen gefüllt, die über ein KIS verfügen und eine
Aufnahmenummer führen
Freitext
20
--
--
--
--
Relation: PS_Status
Aufgabe: Beinhaltet den Status des Patienten und einen Verweis auf den aktuellen Eingriff mit Aufenthaltsort.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
PS_Status.pid
Referenz auf die ID des Patienten P_Stammdaten.pid
ID-Feld
20
--
--
--
--
PS_Status.doknr
Verweis auf den aktuellen Eingriff mit Aufenthaltsort
ID-Feld
20
--
--
--
--
PS_Status.Status
Status des Patienten. Hier muss durch die Client-Software am
MSP ein eindeutiger Eintrag gesetzt werden, sobald der MSP
vom Patienten erreicht wird, z. B. "Herzkatheteruntersuchung"
oder "stationärer Aufenthalt auf Station 112"
Freitext
1000
--
--
--
--
231
Definitionen zum PS aus Kapitel 5
Relation: P_Abteilungen
Aufgabe: Beinhaltet die Daten zu einem Aufenthalt in einer medizinischen leistungserbringenden Abteilung.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
P_Abteilungen.pid
Referenz auf die ID des Aufenthalts P_Aufenthalt.anr
ID-Feld
20
--
--
--
--
P_Abteilungen.doknr
Eindeutige Nummer des Aufenthalts in der Abteilung
ID-Feld
20
--
--
--
--
P_Abteilungen.Startn
Datum mit Uhrzeit an dem der Aufenthalt in der
Abteilung beginnt
Zeitfeld
10
--
--
--
--
P_Abteilungen.Stopp
Datum mit Uhrzeit an dem der Aufenthalt in der
Abteilung endet
Zeitfeld
10
--
--
--
--
P_Abteilungen.Eingriff
Beschreibung der erbrachten Leistung im Sinne
einer Kurzanamnese
Freitext
2000
--
--
--
--
P_Abteilungen.Typ
Typ des Eintrags: "geplanter Termin", "offene
Leistung" oder Bezeichnung der Leistung, wie z. B.
"Herzkatheter" oder "Ultraschall"
Freitext
50
--
--
--
--
232
Definitionen zum PS aus Kapitel 5
Relation: PS_Termin
Aufgabe: Beinhaltet die bei einem Patienten geplanten Termine.
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
PS_Termin.anr
Referenz auf die ID des Aufenthaltseintrags P_Aufenthalt.anr
ID-Feld
20
--
--
--
--
PS_Termin.lfdnr
Fortlaufende Nummer zur eindeutigen Identifikation des
Termins
ID-Feld
20
--
--
--
--
PS_Termin.Datum
Datum mit Uhrzeit an dem der Eingriff geplant ist
Zeitfeld
10
--
--
--
--
PS_Termin.Gepl_E
ingriff
Beschreibung der geplanten Leistung
Freitext
2000
--
--
--
--
PS_Termin.Pflicht
"J" bedeutet, dass diese Leistung durchgeführt werden muss,
wie z. B. "Schreiben des Entlassungsbriefs". Termine für
geplante Leistungen sollten bei Neuanlage den Wert "N"
haben.
Freitext
1
--
J/N
--
--
233
Definitionen zu OSCD aus Kapitel 5
Anhang E: Definitionen zu OSCD aus Kapitel 5
Im Folgenden werden Definitionen und Erläuterung zum in Kapitel 5 vorgestellten Datenschema für Optionen, Systemeinstellungen
und Codetabellen (OSCD) angeführt. Es werden die Tabellen, Attribute, ihre Merkmale und ein kurze Beschreibung aufgeführt.
Merkmale der einzelnen Tabellen und Attribute:
Relation: CFG_Option
Aufgabe: Beinhaltet Optionen
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
CFG_Option.Option_Name
Name der Option
Freitext
50
--
--
--
--
CFG_Option.Profile_Name
Name eines Profils, wenn die Option nur für ein
spezielles Anwendungsprofil gelten soll, "default"
sonst
Freitext
50
--
--
--
--
CFG_Option.Workstation
Name eines Arbeitsplatzes, wenn die Option nur für
einen speziellen Arbeitsplatze gelten soll, "default"
sonst
Freitext
50
--
--
--
--
CFG_Option.Username
Name eines Anwenders, wenn die Option nur für
einen speziellen Anwender gelten soll, "default"
sonst
Freitext
25
--
--
--
--
CFG_Option.Value
Aktuelle Ausprägung der Option
Freitext
500
--
--
--
--
234
Definitionen zu OSCD aus Kapitel 5
Relation: CFG_Profile
Aufgabe: Beinhaltet Informationen zu einem Anwendungsprofil
Dimension
Einheit
Codetabelle
Min/
Max
Normbereic
h
Freitext
50
--
--
--
--
Bevorzugte Sprache für dieses Anwendungsprofil in
Microsofts Abkürzung für Sprachen, z. B. "de-DE" oder
"en-US"
Freitext
5
--
--
--
--
CFG_Profile.Win_Title
Text im Fenstertitel
Freitext
50
--
--
--
--
CFG_Profile.Win_X
X-Koordinate
der
oberen
linken
Ecke
Rahmenfensters, -1 für "Horizontal zentriert"
des
Messwert
4
Pixel
--
-1 / --
--
CFG_Profile.Win_Y
Y-Koordinate
der
oberen
linken
Ecke
Rahmenfensters, -1 für "Vertikal zentriert"
des
Messwert
4
Pixel
--
-1 / --
--
CFG_Profile.Win_Width
Breite des Rahmenfensters
Messwert
4
Pixel
--
--
--
CFG_Profile.Win_Height
Höhe des Rahmenfensters
Messwert
4
Pixel
--
--
--
CFG_Profile.Start_Canvas
Name des Canvas, der als erstes angezeigt werden
soll
Freitext
50
--
--
--
--
Name
Bedeutung
CFG_Profile.Profile_Name
Eindeutiger Name des Profils, welcher beim Start der
Rahmenapplikation als Kommandozeilenparameter
übergeben wird. Hierüber liest die Rahmenapplikation
die Konfigurationsdaten des Anwendungsprofils aus
und baut die zugehörigen Fenster der Applikation auf.
CFG_Profile.Language
235
Datentyp
Definitionen zu OSCD aus Kapitel 5
Relation: CFG_Canvas
Aufgabe: Beinhaltet Informationen zu einem Canvas
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
CFG_Canvas.Canvas_Name
Eindeutiger Name des Canvas
Freitext
50
--
--
--
--
CFG_Canvas.Tab_Text
Text der in der Registerkarte erscheint
Freitext
50
--
--
--
--
CFG_Canvas.Canvas_Type
Typ des Canvas: "S" = Startfenster für
Steuerkomponenten, "D" = Datencanvas für GUIKomponenten
Freitext
1
--
D, S
--
--
CFG_Canvas.Tooltip
Tooltip, der für die Registerkarte angezeigt wird
Freitext
500
--
--
--
--
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
Relation: CFG_Profile_Canvas_Def
Aufgabe: Beinhaltet die Zuordnung von Canvases zu einem Anwendungsprofil
Name
Bedeutung
Datentyp
CFG_Profile_Canvas_Def.Profile_Name
Verweis auf das Anwendungsprofil
Freitext
50
--
--
--
--
CFG_Profile_Canvas_Def.Nr
Position (fortlaufende Nummer) des
Canvas innerhalb der Applikation
ID-Feld
3
--
--
--
--
CFG_Profile_Canvas_Def.Canvas_Name
Verweis auf den Canvas
Freitext
50
--
D, S
--
--
236
Definitionen zu OSCD aus Kapitel 5
Relation: CFG_Canvas_Component
Aufgabe: Legt die Komponenten fest, die in einem Canvas angezeigt werden sollen
Name
Bedeutung
Datentyp
Dimension
Einheit
Codetabelle
Min/
Max
Normbereich
CFG_Canvas_Component.Canvas_Name
Verweis auf den Canvas in den die
Komponenten gehören
Freitext
50
--
--
--
--
CFG_Canvas_Component.Component_Name
Name
der
einzubindenden
Komponente. Über diesen Namen
wird die Komponente durch die
Applikation
identifiziert
und
instanziiert.
Freitext
50
--
--
--
--
CFG_Canvas_Component.XPos
X-Koordinate der oberen linke Ecke
der Komponente im Canvas
Messwert
5
Pixel
--
0 / --
--
CFG_Canvas_Component.YPos
Y-Koordinate der oberen linke Ecke
der Komponente im Canvas
Messwert
5
Pixel
--
0 / --
--
CFG_Canvas_Component.Width
Breite der Komponente, darf leer
sein, dann nimmt die Komponente
ihre Standardbreite
Messwert
5
Pixel
--
--
--
CFG_Canvas_Component.Height
Höhe der Komponente, darf leer
sein, dann nimmt die Komponente
ihre Standardhöhe
Messwert
5
Pixel
--
--
--
237
Anhang F: Fragebogen zur Bewertung von GO#
Anhang F: Fragebogen zur Bewertung von GO#
Vergleich mit der Vorgängersoftware: Bewerten Sie bitte für die Aktionen, ob diese besser
oder schlechter mit der neuen Software durchgeführt werden können. Dabei bedeutet "++"
eine erhebliche Verbesserung, "+" eine Verbesserung, "o" keine Änderung, "-" eine
Verschlechterung und "--" eine erhebliche Verschlechterung gegenüber dem Vorgänger.
Durchgeführte Aktion
++
+
o
-
--
Auswahl eines Patienten zur Neuanlage einer Untersuchung
Übersicht über geplante Untersuchungen
Übersicht über bereits durchgeführte Untersuchungen
Bearbeitung des Datensatzes/Dokumentation der Untersuchung
Repräsentation der Datensätze zur Auswahl für die Bearbeitung
Geschwindigkeit/Antwortzeitverhalten
Robustheit/Fehleranfälligkeit
Auswahl von Datensätzen zur Nachbearbeitung
Konfiguration/individuelle Anpassbarkeit
Welches sind Ihrer Meinung nach die auffälligsten Verbesserungen?
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
Welches sind Ihrer Meinung nach die auffälligsten Verschlechterungen?
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
239
Abbildungsverzeichnis
Anhang G: Abbildungsverzeichnis
Abb. 2.1:
Abb. 2.2:
Abb. 2.3:
Abb. 2.4:
Abb. 2.5:
Abb. 2.6:
Abb. 2.7:
Abb. 2.8:
Austausch von Informationen über ein Modell ................................................... 17
Einordnung unterschiedlicher Systemklassen innerhalb des CSCW.................. 19
Beispiel für ein einfaches Organigramm ............................................................ 21
Behandlung von Patienten in einer Klinik........................................................... 22
Serviceflow-Muster (Standardablauf mit Alternativen) ....................................... 26
Serviceflow-Beispiel mit Supportprozessen und individuellem Arbeitsablauf ..... 28
SP mit Aktivitäten, Vor- und Nachbedingungen ................................................. 28
Kommunikation im Herzkatheterlabor unter Nutzung von DICOM-Diensten. ..... 33
Abb. 3.1:
Abb. 3.2:
Abb. 3.3:
Abb. 3.4:
Abb. 3.5:
Abb. 3.6:
Abb. 3.7:
Abb. 3.8:
Abb. 3.9:
Abb. 3.10:
Abb. 3.11:
Abb. 3.12:
Abb. 3.13:
Abb. 3.14:
Abb. 3.15:
Abb. 3.16:
Abb. 3.17:
Abb. 3.18:
Abb. 3.19:
Abb. 3.20:
Abb. 3.21:
Abläufe im Behandlungsprozess kardiologischer Patienten............................... 52
Stenotische Atherosklerose und Mechanismus des Infarktes ............................ 57
Schematische Darstellung des Herzens (Herzklappen und -kammern). ............ 58
Aneurysma der Bauchaorta. .............................................................................. 60
Die wichtigsten medizinischen Geräte in der Kardiologie................................... 66
Normaler Untersuchungsablauf eines EKGs und Stress-EKGs ......................... 68
Mehrkanal-EKG und Veränderungen des EKG beim Herzinfarkt ....................... 69
Prinzip der Ultraschalluntersuchung .................................................................. 70
Ablauf einer Ultraschalluntersuchung und eines Stress-Echos .......................... 72
Multimediale Daten einer Ultraschalluntersuchung. ........................................... 73
MR-Bilder .......................................................................................................... 75
3D-Rekonstruktion im MR.................................................................................. 76
Normaler Ablauf einer MR-Untersuchung .......................................................... 77
Technik der Herzkatheteruntersuchung ............................................................. 78
Ausgewählte Bilder aus einem Herzkatheterfilm................................................ 79
Ablauf der Herzkatheteruntersuchung ............................................................... 80
Kardiologische Behandlungskette...................................................................... 82
Schematische Darstellung der Dilatation der Herzkranzgefäße (PTCA) ............ 83
Originalbilder einer PTCA. ................................................................................. 84
Ausgewählte zusätzliche Maßnahmen bei Interventionen ................................. 86
Entwicklung kardiologischer und herzchirurgischer Leistungen ......................... 91
Abb. 4.1:
Abb. 4.2:
Abb. 4.3:
Abb. 4.4:
Abb. 4.5:
Abb. 4.6:
Abb. 4.7
Abb. 4.8:
Abb. 4.9:
Abb. 4.10:
Abb. 4.11:
Beispiel für einen Medizinischen Serviceflow..................................................... 99
Der MSP als Spezialisierung von ENLO und NLO........................................... 101
Zusammenhang von MSF, MSP, SK und PS................................................... 102
Allgemeiner Aufbau medizinischer Verfahren .................................................. 103
Phasen des Behandlungsprozesses in der Kinder- und Jugendpsychiatrie ..... 104
Stunden bzgl. Verteilung des Startzeitpunktes von Eingriffen im HK-Labor ..... 111
Prozentualer Anteil von Notfall-Operationen als Folge von Komplikationen..... 113
Die drei Ebenen "Patient", "Anamnese" und "Leistungsdokumentation" .......... 119
Die NLO als "black box"................................................................................... 122
Unterabteilungen innerhalb der kardiologischen Abteilung .............................. 123
Entscheidung für die nächste Maßnahme durch den Chef-/Oberarzt............... 124
241
Abbildungsverzeichnis
Abb. 4.12: Verallgemeinerter Ablauf der Behandlung in einer Klinik.................................. 125
Abb. 4.13: Aufbau des Medizinischen Service Points........................................................ 129
Abb. 4.14: Typischer Verlauf eines Patientenaufenthaltes modelliert als Aufenthalte
innerhalb unterschiedlicher MSPs.................................................................... 134
Abb. 4.15: Reihenfolge der besuchten MSPs bei einem typischen Behandlungsverlauf ... 140
Abb. 4.16: Grafische Darstellung des Beispiel-Automaten ................................................ 146
Abb. 4.17: Vorgeschalteter Startzustand zur Bestimmung des in der Klinik in Frage
kommenden AP. .............................................................................................. 147
Abb. 4.18: Entwicklung der invasiven kardiologischen Eingriffe im Herzkatheterlabor....... 149
Abb. 4.19: ER-Diagramm zur SK des angeführten Beispiels............................................. 151
Abb. 5.1:
Abb. 5.2:
Abb. 5.3:
Abb. 5.4:
Abb. 5.5:
Abb. 5.6:
Abb. 5.7:
Abb. 5.8:
Abb. 5.9:
Abb. 5.10:
Abb. 5.11:
Abb. 5.12:
Abb. 5.13:
Abb. 5.14:
242
Architektur zur Verwendung unterschiedlicher, dedizierter Server ................... 160
Übersicht über die Komponentenarchitektur der Client-Software. .................... 162
Datenschema zur Speicherung des PS (PSD) als ER-Diagramm .................... 164
Ausschnitt aus dem Datenschema OSCD als ER-Diagramm........................... 164
Oberfläche einer Beispielapplikation zur Lagerverwaltung ............................... 166
Beispiel der Speicherung von Informationen zu Dilatationen............................ 167
Vorgehen beim Speichern von Daten in der Datenbank................................... 170
Beispiel des Klassendiagramms der Steuerkomponenten ............................... 173
Ableitungshierarchie der "Documents" des DV-Musters in UML-Notation ........ 176
Integration von Properties in das VisualStudio ................................................. 178
Nachrichtenaustausch beim Ladevorgang ....................................................... 182
Bildschirmmaske mit Patientenstammdaten des ersten Prototyps ................... 188
Dreistufiges Verfahren zur Auswahl der Komplikationen in GO-Kard ............... 191
Auswertung der Fragebögen aus Anhang F..................................................... 196
Tabellenverzeichnis
Anhang H: Tabellenverzeichnis
Tab. 1.1: Entwicklung der Pflegetage und Stationären Fälle in Deutschland 1998 - 2000... 2
Tab. 2.1: Hauptkritikpunkte der Anwender an dem in ihrem Labor etablierten System ..... 43
Tab. 3.1:
Tab. 3.2:
Tab. 3.3:
Tab. 3.4:
Tab. 3.5:
Tab. 3.6:
Tab. 3.7:
Tab. 3.8:
Tab. 3.9:
Tab. 3.10:
Tab. 3.11:
Geschichte der modernen Kardiologie............................................................... 47
Unterschiedliche DRGs und damit verbundene Erlöse. ..................................... 50
Primärdiagnosen bei Entlassung aus stationärem kardiologischem Aufenthalt.. 55
Verteilung der Diagnosen nach Herzkatheter, Ultraschall und MR..................... 55
Charakteristika der wichtigsten medizinischen Großgeräte der Kardiologie....... 65
Ungefähre Kosten für Verbrauchsmaterialien bei kardiologischen Eingriffen ..... 67
Verteilung unterschiedlicher Interventionsverfahren in der Kardiologie.............. 87
Untersuchungszeiten der wichtigsten kardiologischen Maßnahmen. ................. 89
Häufigkeiten von Komplikationen und Wechsel der Therapien .......................... 90
Kostenverteilung für die wichtigsten Maßnahmen bei Herzpatienten 2003 ........ 92
Eckdaten der wichtigsten kardiologischen Behandlungsmethoden .................... 94
Tab. 4.1:
Tab. 4.2:
Tab. 4.3:
Tab. 4.4:
Tab. 4.5:
Tab. 4.6:
Tab. 4.7:
Tab. 4.8:
Tab. 4.9:
Tab. 4.10:
DMM-Verteilung auf leistungserbringende Unterabteilungen der Kardiologie .. 108
Art, Komplexität und Häufigkeit von Komplikationen........................................ 112
Dokumentarische und administrative Leistungen in den Phasen einer DMM ... 115
Merkmale von Datenfeldern............................................................................. 118
Überführungsfunktion δ.................................................................................... 145
Ausgabefunktion λ ........................................................................................... 146
Belegung der Felder nach der Patientenaufnahme.......................................... 153
Belegung der Felder nach der Aufnahmeuntersuchung................................... 153
Belegung der Felder nach dem HK.................................................................. 155
Belegung der Felder, deren Inhalte bis zur Entlassung verändert wurden. ...... 156
Tab. 5.1: Klassen für Oberflächenelemente zur Datenerfassung.................................... 180
Tab. 5.2: Properties und Methoden von Controls............................................................ 180
Tab. 5.3: Vergleich der Bearbeitungszeit ausgewählter Aktionen ................................... 196
243
Lebenslauf
19.06.1970
geboren in Saarbrücken
Schulbesuch
09.76 - 06.79
Grundschule Nordkirchen
08.79 - 06.86
Gymnasium Canisianum Lüdinghausen
08.86 - 05.88
Gymnasium Eversten Oldenburg
Abschluss: Allgemeine Hochschulreife
Wehrdienst
07.88 - 09.89
Wehrdienst als KFZ- und Panzerschlosser in Oldenburg
Studium
10.89 - 05.95
Informatikstudium an der Carl von Ossietzky Universität Oldenburg
Abschluss: Diplom-Informatiker
Beruflicher Werdegang:
07.92 - 12.94
Wissenschaftliche Hilfskraft am Informatikinstitut OFFIS
04.95 - 05.95
Softwareentwicklung für das GRZ in Oldenburg
07.95 - 10.95
Informatiker für die Herzchirurgie der Klinikum Oldenburg gGmbH
11.95 - 03.00
Informatiker im Herzzentrum der Klinikum Oldenburg gGmbH
03.00 -
Wissenschaftlicher Mitarbeiter am Informatikinstitut OFFIS im Bereich
Informationssysteme im Gesundheitswesen (IG)