Primary and
hospital care
«Doing the right thing» und «doing the things right»

Elektronische Dokumentation in der Arztpraxis – state of the art

Lernen
Heinz Bhend
Ausgabe
2016/17
DOI:
https://doi.org/10.4414/phc-d.2016.01343
Prim Hosp Care (de). 2016;16(17):323-326
Affiliations
Fachlicher Leiter Institut für Praxisinformatik, Zürich

Publiziert am 14.09.2016

Eine wichtige Voraussetzung, dass man «richtig elektronisch dokumentieren» kann, sind Softwaresysteme, die dies erleichtern oder zumindest zulassen. Was aber heisst hier «richtig»? Wer bestimmt hier, was richtig oder falsch ist? Wie so oft lautet die Antwort: Kommt drauf an!
Langsam scheint eine Trendwende einzusetzen: Immer mehr niedergelassene Ärzte dokumentieren schon elektronisch oder beabsichtigen in absehbarer Zeit umzustellen [1]. Der Trend ist erfreulich, auch wenn das Tempo nicht gerade atemberaubend ist.
Die Gründe der etwas zögerlichen Adoption der computerbasierten klinischen Dokumentation sind zum einen die «üblichen» systemimmanenten Probleme der Informatik (Datenschutz, Datensicherheit, Abhängigkeit, Kosten usw.) [2]. Auf der anderen Seite bremsen die praktisch jährlich steigende Komplexität und die parallel angemeldeten Datenaustauschwünsche das Ganze enorm aus [3]. Hinzu kommt, dass Kolleginnen und Kollegen, bei denen die Pensionierung ansteht, wohl eher dazu tendieren, abzuwarten, als ein System einzuführen, das für einen potenziellen Nachfolger möglicherweise nicht akzeptabel ist.
Das Richtige tun (= Umstellen) auf elektronische Dokumentation ist die eine Seite der Medaille. Das Ganze aber richtig zu tun ist die «Kehrseite der Medaille».
Den ersten Schritt muss jeder selber gehen, kann dies schneller oder gemächlicher tun, Hilfe in ­Anspruch nehmen von Kollegen die schon etwas länger «auf dem Weg» sind (z.B. «Going paperless»-Kurse des Instituts für Praxisinformatik IPI [4]), sich einer Firma oder einem Consultant anvertrauen – oder einfach loslegen und selber schauen wie weit man kommt.
Auch hier gilt: Das Gute ist der Feind des Besseren! Es lohnt sich, einmal bei einem Kollegen oder einer Kollegin reinzuschauen und dann ganz «biblisch» ranzu­gehen: «Alles prüfen und das Gute behalten»!
Die Gefahr dabei ist, dass man dann irgendwo stehen bleibt, sich an ein suboptimales System gewöhnt und dies als «Ende der Fahnenstange» betrachtet. Deshalb ist es nicht erstaunlich, wenn Umfragen nur einen ­bescheidenen Benefit attestieren. Zum Beispiel wird Effizienzsteigerung durch Zeitgewinn oft als avisiertes Ziel ­formuliert. Die publizierten Zahlen sind aber eher ­ernüchternd, wie Scott Hensley in seiner Publikation «Electronic Medical Records, Built For Efficiency, Often Backfire» [5], feststellt (Abb. 1).
Abbildung 1: Freizeit infolge Computerunterstützung.

«Doing the things right»

Der Fokus dieses Artikels liegt nicht in der Umstellung an sich, sondern auf dem zweiten Teil des einleitenden Bonmots: «Doing the things right».
Es kommt drauf an, was man mit der elektronischen Dokumentation erreichen will. Das National Learning Consortium NLC der USA (HealthIT.gov) listet nahezu 50 Ziele auf, gruppiert nach Optik der involvierten Instanz (System, Anbieter, Anwender, Kosten, Datenaustausch, Patient usw.) [6]. Für die praktische ärztliche ­Tätigkeit sind die Ziele, die mit der elektronischen ­Dokumentation avisiert werden, doch etwas weniger umfangreich:
– Lesbarkeit (MPA kann lesen);
– Redundanz (KG ist von überall in der Praxis einsehbar);
– Effizienzsteigerung (z.B. Dauerrezepte per Mausklick);
– Übersichtlichkeit / Ordnung / Platzersparnis;
– Wiederverwendbarkeit der Daten oder Extrakte ­daraus:
• praxisintern;
• ausserhalb der Praxis (z.B. Überweisungen, Patien­tendossier);
– Vorbereitet sein für CDS (Clinical Decision Support). Dazu hier einige Beispiele:
• AGLA-Score [7], Arriba-Rechner [8] oder Frax-Score [9] benötigen viele Daten, die schon im System sind, heute aber meist nochmals eingetippt werden;
• Graphische Darstellung von Relationen [10]: Laborwert <–> Medikament (Bsp. Cholesterin in Relation zur Statin-Verordnung), Blutdruckwert <–> Medikament;
• Mitberücksichtigung des Kalium-, Kreatinin- oder Transaminasenwertes bei Neuverordnung entsprechend kritischer Medikamente;
• Vorschlag für periodische Laborkontrollen bei entsprechender Vorschrift zum Monitoring;
– Datenexport zu Forschungszwecken wie z.B. FIRE-Projekt [11].
Diese Aufzählung ist nicht abschliessend. Grundsätzlich ist man sich wohl einig, dass die Systeme so «gebaut» werden sollten, dass bei Bedarf alle Optionen möglich sind. Niemand muss sich heute mit CDS oder Forschung herumschlagen, wenn er nicht will. Falls aber später doch ein Bedarf dafür da ist, wäre es sehr schade, wenn infolge falscher Datenerfassung gewisse Optionen verbaut sind.
Deshalb werden in der Folge ein paar Hinweise geliefert, wie grundsätzlich dokumentiert werden sollte. Diese Vorschläge sind Diskussionspunkte; seitens des IPI sind wir offen für Anregungen, zumal wir im Hintergrund intensiv am «Big Picture», der elektronischen Krankengeschichte (eKG), arbeiten. Die Softwarefirmen haben uns wiederholt kommuniziert, dass sie lieber konkrete Anregungen nach Konsens-Findung umsetzen als Einzelwünsche. Alles werden wir nie unter ein Dach bringen können. Deshalb wird es neben der Rubrik «must» immer auch eine Sparte «nice to have» geben.

Die wichtigsten Punkte einer 
elektronischen Krankengeschichte

Konsultation

Bei einer Konsultation entstehen natürlich auch administrative Daten, die ebenfalls miterfasst werden müssen. In der Folge wird jedoch der Teil der klinischen ­Dokumentation behandelt.

RFE: Reason for Encounter (Beratungsanlass)

Irgendwo sollte es ein separates Feld für den Beratungsanlass geben, als Freitext und/oder idealerweise ICPC-codierbar [12]. Der Beratungsanlass ist strikte zu trennen von den subjektiven Beschwerden, kann aber völlig identisch sein, zum Beispiel Druck des Ehepartners, Arbeitsunfähigkeitsbestätigung usw.

SOAP(E)-Schema

Obwohl das SOAP(E)-Schema aus der papierbasierten Zeit stammt, lebt es in vielen eKG-Lösungen weiter, ist trotz namhafter Kritik [13] WONCA-Standard [14] und wird in Lehrbüchern der Allgemeinmedizin immer noch als bewährt angesehen [15].
S = Subjektiv: Subjektive Angaben des Patienten möglichst in seiner Wortwahl «es het mi plötzlich zwickt» (Freitextfeld).
O = Objektiv: klinischer Befund in Freitext oder mit Eingabemaske und Textgeneration im Hintergrund (elektronisches Statusblatt). Die Vitalparameter (Blutdruck, Puls, Gewicht, Body Mass Index, Temperatur usw.) sind ebenfalls ­objektive Befunde, aber zwingend separat zu erfassen in entsprechend bezeichneten Datenfeldern. Wer den Blutdruck einfach im Text unter objektiv erfasst, verbaut sich die Möglichkeit der späteren Analyse (z.B. Verlaufsdiagramme).
In diesem Punkt unterscheiden sich die Systeme zum Teil schon erheblich: Wenn das Datenfeld zur Erfassung des Blutdruckwertes mehrere Klicks entfernt ist, wird dies schlechter oder gar nicht genutzt.
A = Assessment (Beurteilung): Was ist meine «Arbeitshypothese»? Freitextfeld zur kurzen stichwortartigen Zusammenfassung.
P = Procedere: Was ist als nächstes zu tun? Freitextfeld zur Festhaltung der nächsten Schritte (weitere Abklärungen, Überweisung, Therapie).
E = Etikett oder Problem dieser Konsultation: Idealerweise in codierter Form, wobei sich ICPC für die Hausärzte als am Bewährtesten gezeigt hat, zum Beispiel Husten, Rückenschmerz, Hautauschlag usw. In der Hausarztpraxis sind die Ein-Problem-Konsultationen eher eine Seltenheit. Meist werden zwei, drei oder sogar fünf Probleme in einer Konsultation abgehandelt. Bezüglich Implementierung und Führen einer Problemliste unterscheiden sich die Systeme. Es gibt grundsätzlich zwei Arten der Etikettierung.
Erste Variante: Jedes Problem hat ein (eigenes) SOAP-Schema. Dies bedeutet Problem 1 (Husten) hat die Felder «Subjektiv», «Objektiv» «Assessment» und «Procedere».
Zweite Variante: Pro Konsultation wird nur ein SOAP-Eintrag gemacht, dieser erhält aber mehrere Etiketten.
Ich persönlich konnte mich für die erste Variante nie erwärmen, da die Patienten sehr selten ein Problem abschliessen und dann wohlgeordnet zum nächsten gehen. Damit müssen mehrere Fenster parallel bedient werden. Konsequenterweise müssten auch die Medikamente und Laborwerte dem jeweiligen Problem zugeordnet werden, um eine saubere Ordnung zu haben. Es gibt aber diverse Kollegen, die mit dieser Art der ­Dokumentation arbeiten und anscheinend ganz gut zu Recht kommen.

Medikation

Medikamente sollten nur aus Datenbanken übernommen werden. Einträge von Hand sind wohl lesbar, aber zum Beispiel für die Interaktionskontrolle oder Unverträglichkeitsprüfung unbrauchbar.
Die übersichtliche Darstellung, Warnung bei hinter­legter Unverträglichkeit, Ausdruck von Medikationsplänen für die Patienten, sowie «Ein-Klick-Rezeptdruck» sollten selbstverständlich sein.

Dauerdiagnosen

Idealerweise werden Dauerdiagnosen strukturiert nach ICD-10 erfasst. Der Patient hat ein Problem (z.B. Intertrigo) als Etikett der aktuellen Konsultation. Im «Hintergrund» ist wichtig dass die Dauerdiagnose ­«Diabetes» mitgeführt wird. – Klar kenne ich meine ­Diabetiker; oder meine es jedenfalls! – Aber gerade im Vertretungsfall in einer Gruppenpraxis ist es sehr hilfreich, wenn diese Dauerdiagnosen im Blickfeld sind. Hier macht die Erfassung zum Beispiel nach ICD-10 Sinn. Die Begründung liegt beim strukturierten Datenaustausch. Wenn dereinst ein Austrittsbericht automatisch «eingelesen» wird, müssen die Diagnosen abgeglichen werden können. Wenn die Diagnose «Diabetes» schon erfasst ist, erfolgt keine Veränderung, falls nicht, wird diese Dauerdiagnose hinzugefügt. Dies ist Zukunftsmusik, soll aber illustrieren, dass die Art der Erfassung solche Optionen möglichst offen lassen sollte.

Risikofaktoren

Die meisten Risikofaktoren sind schon erfasst und könnten mehr oder weniger automatisch beispielsweise in Arriba (my favorite!) übernommen werden. Beim Raucherstatus gibt es einen «Wildwuchs», wie dieser erfasst, gewichtet und vor allem aktualisiert wird. Hier muss die Diskussion noch geführt werden, ob man zum Beispiel SNOMED CT (Systematized Nomenclature of Human and Veterinary Medicine - Clinical Terms) übernehmen sollte. Da der Raucherstatus eine Risikoberechnung doch stark beeinflusst, ist es sehr erstaunlich, dass es hier noch keinen «State oft he Art» gibt.

Weitere Informationen

Bezüglich Familien- und persönlicher Anamnese, ­Operationsdaten und Systemanamnese divergieren die Systeme stark. Hier geht es vor allem um Übersicht und grösstmögliche Vollständigkeit. Die Darstellung, das heisst die Präsentation ist sehr individuell. Die ­automatische Übernahme in Überweisungsschreiben sollte bei Bedarf möglich sein.

Do:

– Jede Konsultation nach SOAPE dokumentieren, das heisst: Abschluss erst wenn «etikettiert».
– Codierte und damit austauschfähige Problemliste (ICPC) nutzen.
– Vitaldaten in separaten Feldern erfassen.
– Medikamente nur aus Datenbank übernehmen.
– Dauerdiagnosen strukturiert erfassen (möglichst nach ICD-10).
– RFE (Beratungsanlass) separat erfassen, möglichst auch nach ICPC.

Don’t:

– Zahlenwerte in Freitextfelder eingeben.
– Individuelle und/oder uncodierte Problemliste führen.
– Medikamente «von Hand» erfassen, das heisst nicht von ­einer Datenbank übernehmen.

Ausblick

Die verschiedenen Softwarelösungen haben unterschiedliche Entwicklungen durchgemacht und einen entsprechend unterschiedlichen Entwicklungsstand. Leider gibt es immer noch grosse Anbieter, die sich von einzelnen Kollegen beraten lassen, ohne dass diese ­ihrerseits in die Konsensusfindung eingebunden sind.
Wie schon oft kommuniziert wurde respektive zumindest versucht wurde, zu kommunizieren: Wir brauchen einen breit abgestützten Konsens und müssen diesen einbringen. Genau dies ist die Idee des Instituts für Praxisinformatik IPI. Wie erwähnt arbeiten wir am «Big Picture» der eKG. Bei diesem Projekt werden möglichst alle Subprozesse der elektronischen Dokumentation in der Arztpraxis aufgelistet, beschrieben und mit Prioritäten versehen. In den nächsten Monaten wird die erste Vernehmlassung anlaufen. Geplant ist dann baldmöglichst einen «Runden Tisch» mit den Industriepartnern (VSFM [16]) einzuberufen, um hoffentlich bald die stufenweise Realisierung unserer gebündelten Wünsche zu sehen. Damit ist auch klar, dass die «IPI-Truppe» vorläufig noch nicht arbeitslos wird.
Dr. med. Heinz Bhend
Facharzt Allgemeine Innere Medizin Informatiker
(Exec. Master of ICT)
Fachlicher Leiter Insitut
für Praxisinformatik
CH-4663 Aarburg
h.bhend[at]
praxisinformatik.ch
 1 eHEalth-Barometer 2016 à http://www.infosocietydays.ch/images/content/dokumente/barometer/163101_Prsentation_Swiss_eHealth_Barometer_ehealth_Forum_2016.pdf
 2 Djalili S. Wer eHealth sucht..; SAEZ 2015;96(43):1575–8.
 3 Factsheet GDK, Ziele und Stand eHealth Juli 2015
 4 www.praxisinformatik.ch à projekte à going paperless
 5 Electronic Medical Records, Built For Efficiency, Often Backfire; online unter http://www.npr.org/sections/health-shots/2014/11/
07/361148976/electronic-medical-records-built-for-efficiency-
often-backfire
 6 The National Learning Consortium (NLC) Guidelines Goals and Objectives for Electronic Health Record (EHR) Implementation; online unter: https://www.healthit.gov/providers-professionals/implementation-resources/goals-and-objectives-electronic-health-record-ehr
 7 http://www.agla.ch/risikoberechnung/agla-risikorechner
 8 http://www.arriba-hausarzt.de/
 9 https://www.shef.ac.uk/FRAX/tool.aspx?country=15
10 Bhend H. Elektronische Dokumentation, SAEZ. 2015;96(43):
1579–81.
11 http://www.hausarztmedizin.uzh.ch/de/fire2.html
12 ICPC = International Classification in Primary Care à www.icpc.ch
13 http://www.medicalpracticeinsider.com/news/does-soap-note-still-fit-age-ehrs
14 WICC-Wonca International Classification Committee à www…..org
15 Kochen, Allgemeinmedizin, Thieme Verlag, Ausgabe 2012 S. 28
16 http://vsfm.ch/

Veröffentlicht unter der Copyright-Lizenz.

"Attribution - Non-Commercial - NoDerivatives 4.0"

Keine kommerzielle Weiterverwendung ohne Genehmigung.

See: emh.ch/en/emh/rights-and-licences/

 

 

Zum Seitenanfang