hl7 cda in arztpraxissoftware
TRANSCRIPT
medshare GmbH
Tempelstrasse 8b
3608 Thun-Allmendingen
Switzerland
http://medshare.net
HL7 CDA in Arztpraxissoftware
Konzept zur Integration
Im Auftrag von Franz Marty, Medizinisches Zentrum gleis d, Chur
25. August 2012 | Version 1.1
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 2 von 54 | 25.08.2012 | Version 1.1
Impressum
Auftraggeberin Medizinisches Zentrum gleis d AG
Dr. med. Franz Marty, [email protected]
Gürtelstrasse 46, 7000 Chur
http://www.mez-chur.ch/
Redaktion Tony Schaller, medshare GmbH, [email protected]
Stand 25. August 2012
Genehmigt am 18. Juli 2012
Version, Status Version 1.1
Disclaimer Dieses Werk ist öffentlich zugänglich unter der Creative Commons Lizenz
vom Typ „Namensnennung – Weitergabe unter gleichen Bedingungen“
Lizenztext: http://creativecommons.org/licenses/by-sa/3.0/ch/
Die verwendeten Logos und Produktbezeichnungen sind eingetragene Warenzeichen der
Auftraggeberin, der medshare GmbH, der Open Source Initiative oder von Dritten.
Es ist ferner zu beachten, dass Teile dieses Dokuments auf dem HL7 Standard beruhen,
für den ein Copyright von HL7 Inc. USA besteht. Sämtliche Mitglieder der HL7 Benutzer-
gruppe Schweiz erhalten über den Mitgliederbereich von http://hl7.ch Zugang zu allen
Dokumenten im Mitgliederbereich von http://hl7.org.
Obwohl diese Publikation mit grösster Sorgfalt erstellt wurde, kann weder die Auftragge-
berin, noch die medshare GmbH irgendwelche Haftung für direkte oder indirekte Schäden
übernehmen, die durch den Inhalt dieses Konzepts entstehen könnten.
Aktuelle Revision 72
Revisionen V1.0 21.07.2012 Erste Publikation der genehmigten Dokumentenversion
V1.1 25.08.2012 Einzelne Textkorrekturen ohne Anpassung am Inhalt
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 3 von 54 | 25.08.2012 | Version 1.1
Inhalt
Impressum ................................................................. 2
Inhalt ......................................................................... 3
1 Management Summary ...................................... 4
2 Ausgangslage ..................................................... 5
2.1 Handling von Dokumenten ............................................ 5
2.1.1 Gestern .......................................................................... 5
2.1.2 Heute ............................................................................. 5
2.1.3 Morgen .......................................................................... 6
3 Zielsetzung ......................................................... 7
3.1 eHealth Strategie Schweiz.............................................. 7
3.2 eHealth Architektur Schweiz .......................................... 8
3.3 Elektronisches Patientendossier Gesetz (EPDG) ............ 9
3.4 IHE Initiative ................................................................. 10
3.4.1 IHE Integrationsprofile ................................................. 10
3.4.2 IHE Content Profiles ..................................................... 11
3.4.3 IHE Connectathon (CAT) .............................................. 12
3.5 HL7 CDA ....................................................................... 13
3.5.1 Eigenschaften eines CDA Dokuments .......................... 14
3.5.2 CDA Body Level 1 ......................................................... 15
3.5.3 CDA Body Level 2 ......................................................... 15
3.5.4 CDA Body Level 3 ......................................................... 16
3.5.5 Transport der Dokumente ........................................... 16
3.5.6 Validierung von CDA Dokumenten .............................. 17
3.5.7 CDATools ...................................................................... 18
3.6 Elexis ............................................................................ 19
3.7 FIRE .............................................................................. 20
3.7.1 Ausgangslage ............................................................... 20
3.7.2 Ablauf und Inhalt ......................................................... 20
3.7.3 Datenqualität ............................................................... 22
3.7.4 Perspektiven ................................................................ 22
3.7.5 Wissenschaftliche Leitung ............................................ 22
3.8 eImpfdossier ................................................................ 22
3.9 EPha.ch ........................................................................ 23
3.9.1 Interaktionen ............................................................... 23
3.9.2 Rezept Service .............................................................. 24
4 Relevante Grundlagen ...................................... 25
4.1 eHealth Suisse .............................................................. 25
4.2 IHE Implementierungsleitfäden ................................... 25
4.3 CDA-CH Spezifikationen ............................................... 27
4.4 OID Konzept ................................................................. 27
5 Organisatorisches Konzept ............................... 28
5.1 Betriebsübergreifende Zusammenarbeit ..................... 28
5.2 Nutzung medizinischer Daten in einer Gemeinschaft .. 28
5.3 Schützenswerte Information ........................................ 30
6 Technisches Konzept ........................................ 32
6.1 Konformität zur eHealth Architektur Schweiz .............. 32
6.2 Allgemeines zur CDA Unterstützung in einer APS ........ 34
6.2.1 Medikament-Interaktionscheck ................................... 36
6.2.2 Elektronischer Impfausweis ......................................... 37
6.2.3 Upload FIRE-Daten ....................................................... 37
6.3 Auswirkungen auf Applikationslogik einer APS ............ 37
6.4 Auswirkungen auf Datenhaltung einer APS ................. 38
6.4.1 Erstellen von CDA Dokumenten (Versand) .................. 38
6.4.2 Verarbeiten von CDA Dokumenten (Empfang) ............ 39
6.5 Auswirkungen auf Benutzerinterface einer APS .......... 40
6.5.1 Erstellen von CDA Dokumenten (Versand) .................. 40
6.5.2 Verarbeiten von CDA Dokumenten (Empfang) ............ 42
6.6 Validieren von CDA Dokumenten................................. 43
6.7 Bestehende IHE/CDA Plug-Ins für Elexis....................... 43
7 Anwendungsfälle .............................................. 44
7.1 Interaktionscheck und Rezeptservice .......................... 44
7.1.1 Datentransfer zwischen Sender und Empfänger .......... 45
7.2 Elektronischer Impfausweis ......................................... 46
7.2.1 Datentransfer zwischen Sender und Empfänger .......... 47
7.3 Upload FIRE-Daten ....................................................... 48
7.3.1 Datentransfer zwischen Sender und Empfänger .......... 48
7.3.2 Dateninhalt .................................................................. 48
8 Anhang ............................................................. 49
8.1 Referenzierte Dokumente ............................................ 49
8.2 Abkürzungen und Glossar ............................................ 52
8.3 Abbildungsverzeichnis.................................................. 54
8.4 Tabellenverzeichnis ...................................................... 54
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 4 von 54 | 25.08.2012 | Version 1.1
1 Management Summary
Ausgangslage und Zielsetzung
Früher schrieben Ärzte ihre Berichte auf der Schreibmaschine. Heute sind Computer im Einsatz, aber der ärztliche
Alltag ist belastet durch Unzulänglichkeiten von Organisation und Technik. Das vorliegende Dokument soll die Bedeu-
tung des harmonisierten, elektronischen Datenaustausches zwischen verschiedenen beteiligten Personen und Institu-
tionen im Gesundheitswesen aufzeigen und darstellen, wie eine Integration in einer Arztpraxissoftware (APS) realisiert
werden soll, um eine möglichst hohe Interoperabilität und Konformität zur eHealth Architektur Schweiz zu erreichen.
Einführung in wichtige Rahmenbedingungen und relevante Grundlagen
Das elektronische Patientendossier (EPD) ist Teil der Strategie eHealth Schweiz und soll zu einer besseren Qualität der
Behandlungsprozesse, einer höheren Patientensicherheit sowie zu mehr Effizienz im Gesundheitssystem führen. Der
Bundesrat hat das EDI damit beauftragt, bis Ende 2012 Botschaft und Gesetzesentwurf zum EPD auszuarbeiten. Die
Umsetzung des EPD soll in der Schweiz basierend auf einer dezentralen Datenhaltung erfolgen. Mehrere Empfehlun-
gen zu Standards und Architektur sind von eHealth-Suisse erschienen. Diese nennen eine Standardisierung, die pro-
zessorientiert mit Anwendungsfällen, basierend auf der IHE Initiative erfolgen soll. Die weltweit verankerte IHE Initia-
tive entstand aus dem Bedürfnis heraus die immer wiederkehrenden Integrationsprobleme beim Vernetzen von Com-
putersystemen zu vermindern. IHE erstellt dazu Integrationsprofile, welche auf bestehende, weltweit etablierte Stan-
dards referenzieren. Mit der HL7 Clinical Document Architecture (CDA) liegt ein solcher Standard vor, der menschliche
Lesbarkeit und elektronische Weiterverarbeitbarkeit vereinigt. CDA wird deshalb aus IHE Inhaltsprofilen referenziert
und trägt einen wichtigen Teil zur Verbesserung der Interoperabilität im Gesundheitswesen bei. Dieses Konzept zeigt
auf, wie HL7 CDA in APS integriert werden soll um einleitend genannte Ziele erreichen zu können.
Organisatorisches Konzept
Im Zuge der immer mobiler werdenden Gesellschaft, kann der Behandlungspfad nicht geografisch eingegrenzt wer-
den. Behandlungsprozesse spielen sich über Grenzen hinweg ab. Egal ob Behandelnde innerhalb einer Gemeinschaft,
betriebs-, gemeinschafts- oder länderübergreifend gemeinsame Daten nutzen oder austauschen wollen: Es kann nur
funktionieren, wenn diese ohne gesonderte Absprache zwischen Sender und Empfänger erstellt, gelesen und verstan-
den werden können. Dazu müssen Daten technisch und semantisch interoperabel ausgetauscht werden. Eine interna-
tionale Harmonisierung von elektronischen Daten im Gesundheitswesen ist deshalb unabdingbar.
Technisches Konzept
APS müssen in der Lage sein, Patienten-IDs von Gemeinschaften zu verwalten, Dokumente in die Dokumentenablage
der Gemeinschaft einzustellen und von anderen Systemen eingestellte Dokumente abzufragen. Dazu können Leitfä-
den der IHE implementiert werden. Als Standard für die Strukturierung von Dokumenteninhalten wird HL7 CDA einge-
setzt. Eine APS muss in der Lage sein, beliebige Inhalte in ein HL7 CDA Dokument zusammenzustellen oder aus einem
HL7 CDA Dokument zu verarbeiten. Die Erstellung von CDA Dokumenten soll nicht direkt im Kern der APS, sondern in
einem „eHealth Connector“ implementiert werden.
Anwendungsfälle
Drei unterschiedliche Anwendungsfälle zeigen auf, wie die technische und semantische Interoperabilität konkret um-
gesetzt werden soll. Medikamenten-Interaktionscheck und Rezept Service sollen so in eine APS integriert werden,
dass ein Prozessablauf mit technischer und semantischer Interoperabilität gewährleistet ist und wiederverwendbare
Schnittstellen zwischen Softwaresystemen zur Anwendung kommen. Weil Impfungen an verschiedensten Orten
durchgeführt werden, zählt der elektronische Impfausweis zu den Dokumenten, welche unabhängig von Zeit und Ort
einsehbar und aktualisierbar sein sollen. Ärzte müssen also unabhängig von der Wahl ihres APS in der Lage sein, sol-
che Dokumente einzusehen und zu aktualisieren. Wenn Forschungsinstitute anonymisierte Daten aus verschiedenen
APS zu Forschungszwecken auswerten wollen, sind diese dringend auf eine Vergleichbarkeit der Daten angewiesen.
Diese Anwendungsfälle zeigen grosse Nutzenpotenziale auf, welche erst voll ausgeschöpft werden können, wenn die
Teilnehmer im Gesundheitswesen Schweiz sowohl technisch wie inhaltlich harmonisierte Schnittstellen einsetzen.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 5 von 54 | 25.08.2012 | Version 1.1
2 Ausgangslage
Der Alltag des Arztes ist heute immer noch zu oft belastet durch Unzulänglichkeiten von Organisation und Informa-
tions- und Kommunikationstechnologien. Oft hat er den Wunsch, auf alle seine Informationen, die sich in seiner Do-
kumentation über die Krankengeschichte seiner Patienten niedergeschlagen haben, rasch und effizient zugreifen zu
können, und eben diese Informationen für weitere Verwendungszwecke verfügbar zu haben. Auch möchte er Berich-
te, die er von aussenstehenden Institutionen erhält, rasch und automatisch am richtigen Ort ablegen können. Dazu
kommt, dass der Umfang an administrativen Aufgaben fortlaufend zunimmt:
„Anscheinend müssen immer mehr Arztbriefe, Untersuchungsberichte, Verordnungen, Patientenakten, Leistungserfas-
sungen, Beurteilungen und andere «administrative» Arbeiten erledigt werden. «Administration» hält von der eigentli-
chen Arbeit ab, wird abends, in der Freizeit oder zwischendurch erledigt. Aber kaum jemand wählte den medizinischen
Beruf wegen der Administration.“1
Es erscheint als wesentliche Aufgabe, diese im weitesten Sinne administrativen Aufgaben mit Hilfe von Informations-
und Kommunikationstechnologie zu erleichtern, und zwar in unmittelbarer Zukunft. Wir können nicht von lebensläng-
lichen Patientenakten träumen, ohne zuerst die Grundlagen zu schaffen, welche elektronisch geführte Krankenge-
schichten so aufbauen, dass die darin enthaltenen Informationen ohne Medienbrüche weiterverwendet werden kön-
nen (semantische Interoperabilität).
2.1 Handling von Dokumenten
2.1.1 Gestern
Nur bei wenigen Ärzten befindet sich vielleicht noch eine Schreibmaschine im Sprechzimmer, mit welcher Überwei-
sungsberichte etc. verfasst und dann per Post verschickt werden. Sämtliche Informationen müssen jedes Mal einge-
tippt werden. Einzig der Absender ist auf dem Briefpapier aufgedruckt.
2.1.2 Heute
Die Kommunikation zwischen Arztpraxen und Spitälern geschieht heutzutage meist über den Briefverkehr. Notfallü-
berweisungen erfolgen in der Regel telefonisch mit anschliessender schriftlicher Bestätigung der Überweisung per Fax.
Der einweisende Arzt erstellt – heutzutage kaum mehr auf seiner Schreibmaschine, meistens in seinem Textverarbei-
tungssystem, – ein Einweisungsschreiben, das er ausdruckt (Medienbruch) , unterschreibt, in einen Umschlag steckt,
frankiert und abschickt. Der Klinikarzt entnimmt dem Einweisungsschreiben die Patientendaten und die klinischen
Daten und entscheidet die Dringlichkeit des Aufbietens und das weitere Vorgehen. Das Einweisungsschreiben wird im
Patientendossier abgelegt. Falls ein elektronisches Dossier vorliegt, muss es eingescannt werden (Medienbruch). Nach
Beendigung des Spitalaufenthaltes wird mit dem Spitalentlassungsbericht ähnlich verfahren, in umgekehrter Richtung:
der Patient überbringt den Entlassungsbericht, oder dieser wird per Post, Fax oder E-Mail dem zuweisenden Arzt ge-
sendet (Abbildung 1).
Es entstehen dadurch nebst langen Transportwegen viele Medienbrüche. Diese haben zur Folge, dass wertvolle In-
formationen in nicht auswertbarer Form vorliegen. Es fehlen dadurch Möglichkeiten für die Weiterverarbeitung der
Daten (z.B. Übernahme der Diagnosen- oder Medikamentenliste). Diese Daten müssen oft erneut eingetippt werden.
Darüber hinaus stehen (auch bei eingescannten Dokumenten) keine Grundlagen für eine strukturierte Suche nach
Informationen zur Verfügung (z.B. Rückverfolgbarkeit, Forschung).
1 Rüegg-Stürm J, Tuckermann H , Warum immer mehr «Administration»? Wege aus der «Administrationsfalle» , 2008,7(271-275),
Schweiz Ärztezeitung
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 6 von 54 | 25.08.2012 | Version 1.1
Abbildung 1: Dokumentenaustausch heute
Der Stand der Infrastruktur in Schweizer Arztpraxen sah 2008 so aus2: Es gibt nur noch sehr wenige Arztpraxen, die
ohne Computer arbeiten. 50 % benutzen einen Computer im Sprechzimmer, 12.5 % benutzen eine elektronische Kran-
kengeschichte, 8 % planen eine elektronische Krankengeschichte innerhalb der nächsten 2 Jahre3.
Die Erstellung und das Versenden, wie auch der Empfang und die strukturierte lokale Ablage von elektronischen Do-
kumenten gehört heute vielerorts zum Alltag (z.B. Tarmed Rechnungen, Mails, Bestellungen, Aufträge etc.). Insofern
ist der Schritt zur Übertragung von Arztbriefen und anderen Dokumenten mit medizinischen Informationen zu Patien-
ten über diese etablierten Mechanismen nicht sehr gross. Vielerorts werden heute bereits Arztbriefe in Form von PDF
Dateien (Medienbruch) übertragen.
2.1.3 Morgen
Die medizinischen Daten im eigenen Informationssystem sollen zur Erstellung von Arztbriefen weiterverwendet wer-
den können: Diagnoselisten, Medikamentenlisten, aktuelle Probleme etc. Auch sollen die von aussen erhaltenen klini-
schen Dokumente (Spitalentlassungsberichte, Röntgenberichte, Laborbefunde etc.) ohne weiteres in elektronischer
Form vorliegen und automatisch dem richtigen Patienten zugeordnet werden können (Abbildung 2).
Abbildung 2: Dokumentenaustausch in Zukunft
2 H. Bhend, F. Marty, J. Wagner, M. Zoller, Status quo der IT Infrastruktur und IT Kompetenz in Schweizer Arztpraxen, 2008
3 Anmerkung des Autors: hat sich seit dieser Veröffentlichung nur unmerklich verändert
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 7 von 54 | 25.08.2012 | Version 1.1
3 Zielsetzung
Das vorliegende Dokument soll die Bedeutung des harmonisierten, elektronischen Datenaustausches zwischen ver-
schiedenen beteiligten Personen und Institutionen im Gesundheitswesen aufzeigen und darstellen, wie eine Integrati-
on in einer Branchensoftware für Arztpraxen, sogenannte Arztpraxissoftware realisiert werden sollte, um eine mög-
lichst hohe Interoperabilität und Konformität zur eHealth Architektur Schweiz zu erreichen.
Um das Konzept mit konkreten Aussagen anreichern zu können, werden einzelne Aussagen am Beispiel von Elexis
demonstriert. Elexis ist eine frei verfügbare Arztpraxissoftware (APS). Sie wird in der Schweiz und in Österreich einge-
setzt und im Kapitel „3.6 Elexis“ auf Seite 19 genauer eingeführt. Wichtig ist an dieser Stelle festzuhalten, dass die
Umsetzung auch in anderen Produkten nach diesem Konzept erfolgen könnte. Allerdings kann dieses Konzept für
kommerzielle Produkte nicht den notwendigen Detaillierungsgrad erreichen, weil keine Details zur Architektur dieser
Produkte öffentlich bekannt sind.
Das Konzept geht davon aus, dass ein sogenannter Konnektor realisiert wird, welcher als generische, robuste und
wiederverwendbare Komponente für verschiedene Anwendungsfälle im betriebsübergreifenden Dokumentenaus-
tausch eingesetzt werden kann. Der Fokus bleibt dabei auf dem Austausch von Dokumenten. Diese Dokumente sollen
von Menschen und Maschinen gleichermassen gelesen und inhaltlich ausgewertet werden können.
Nachfolgend werden einige Elemente aus dem Umfeld eingeführt, weil sie im weiteren Verlauf des Dokuments ge-
nannt werden. Die Texte stammen zum Teil unverändert aus öffentlichen Publikationen der genannten Quellen.
3.1 eHealth Strategie Schweiz
Im Januar 2006 hat der Bundesrat die «Strategie für eine Informationsgesellschaft in der Schweiz» aus dem Jahr 1998
revidiert. Als Folge davon hat er am 27.06.2007 eine «Strategie „eHealth” Schweiz» herausgegeben. Darin steht:
Unter „eHealth” oder „Elektronischen Gesundheitsdiensten“ versteht man den integrierten Einsatz von Informa-
tions- und Kommunikationstechnologien (IKT) zur Gestaltung, Unterstützung und Vernetzung aller Prozesse und
Teilnehmerinnen und Teilnehmer im Gesundheitswesen.
Technik steht nicht im Vordergrund. Vielmehr müssen die bestehenden Prozesse verknüpft und vereinfacht wer-
den – mit dem Ziel, neue und bessere Prozesse zu etablieren.
Seit der Bundesrat im Jahr 2007 eine Strategie eHealth Schweiz verabschiedet hat, wird konsequent an der Umsetzung
der Vision gearbeitet. Die Vision der eHealth Strategie Schweiz lautet folgendermassen:
Die Menschen in der Schweiz können im Gesundheitswesen den Fachleuten ihrer Wahl unabhängig von Ort und Zeit
relevante Informationen über ihre Person zugänglich machen und Leistungen beziehen. Sie sind aktiv an den Entschei-
dungen in Bezug auf ihr Gesundheitsverhalten und ihre Gesundheitsprobleme beteiligt und stärken damit ihre Gesund-
heitskompetenz. Die Informations- und Kommunikationstechnologien werden so eingesetzt, dass die Vernetzung der
Akteure im Gesundheitswesen sichergestellt ist und dass die Prozesse qualitativ besser, sicherer und effizienter sind.
Die übergeordneten Ziele lauten Effizienz, Qualität, Sicherheit und Förderung der Wirtschaft. Die Strategie hat 3 Hand-
lungsfelder identifiziert:
Elektronisches Patientendossier
Online-Dienste
Umsetzung der Strategie
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 8 von 54 | 25.08.2012 | Version 1.1
Innerhalb dieser Handlungsfelder wurden verschiedene Ziele formuliert. Die beiden folgenden scheinen im vorliegen-
den Kontext besonders interessant:
Ziel A7:
Bis Ende 2015 können alle Menschen in der Schweiz unabhängig von Ort und Zeit den Leistungserbringern ihrer
Wahl den elektronischen Zugriff auf behandlungsrelevante Informationen ermöglichen („Elektronisches Patien-
tendossier“).
Ziel B4:
Bis Ende 2015 ist der sichere Zugang der Bürgerinnen und Bürger auf ihr elektronisches Patientendossier über das
Gesundheitsportal verknüpft mit der Möglichkeit, strukturierte und spezifische Informationen abzurufen.
Die Projektleitung von "eHealth Suisse" hat per März 2012 eine Zwischenbilanz der Strategieumsetzung gezogen. Von
den 21 konkreten Zielen wurde knapp die Hälfte "erreicht" oder "eher erreicht", während die andere Hälfte "eher
nicht erreicht" oder "nicht erreicht" wurde.
Diese Tatsache zeigt auf, dass aktiv an der Umsetzung der eHealth Strategie der Schweiz gearbeitet wird, dass aber die
Zielsetzungen insbesondere in Bezug auf die Zeitachse wohl zu ehrgeizig gesetzt wurden.
Weitere Informationen zur eHealth Strategie Schweiz und deren Umsetzung: www.e-health-suisse.ch
3.2 eHealth Architektur Schweiz
Die Umsetzung des elektronischen Patientendossiers soll in der Schweiz basierend auf einer dezentralen Datenhaltung
erfolgen. Dazu hat das Teilprojekt Standards und Architektur folgende Architektur empfohlen:
Abbildung 3: eHealth Architektur Schweiz
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 9 von 54 | 25.08.2012 | Version 1.1
Folgende Empfehlungen von eHealth-Suisse sind bisher erschienen. Sie nennen eine Standardisierung, die prozessori-
entiert mit Anwendungsfällen, basierend auf der IHE Initiative erfolgt.
2009: Empfehlungen I
Schwerpunkt dezentrales Patientendossier, Basisgrundsätze
Definieren die eigentliche Architektur eHealth Schweiz
Empfohlene Standards in der Startphase, basierend auf IHE
2010: Empfehlungen II
Schwerpunkt Datenaustausch zwischen Gemeinschaften
Rollenkonzept
Erste Angaben zu Metadaten
2011: Empfehlungen III
Schwerpunkt Vertiefung Rollenkonzept
Personenidentifikation
Berechtigungskonzept
2012: Empfehlungen IV (derzeit in Arbeit, Vernehmlassung folgt im Herbst 2012)
Erste Empfehlungen zu Inhalte und Semantik
Kommunikation zwischen Gemeinschaften
Zugangsportal
3.3 Elektronisches Patientendossier Gesetz (EPDG)
Das elektronische Patientendossier soll zu einer besseren Qualität der Behandlungsprozesse, einer höheren Patien-
tensicherheit sowie zu mehr Effizienz im Gesundheitssystem führen. Das elektronische Patientendossier ist Teil der
Strategie eHealth Schweiz; die gesetzlichen Grundlagen sind für die Umsetzung der Strategie unabdingbar.
Am 3.12.2010 hat der Bundesrat das Eidgenössische Departement des Innern (EDI) beauftragt, bis im September 2011
die gesetzlichen Grundlagen zur Einführung eines elektronischen Patientendossiers auszuarbeiten. Der Bundesrat hat
am 16. September 2011 die Vernehmlassung zum Vorentwurf des Bundesgesetzes über das elektronische Patienten-
dossier eröffnet. Die Vernehmlassung dauerte bis am 20. Dezember 2011. Es sind 96 Stellungnahmen eingegangen,
welche auf der Website des BAG zugänglich sind4. Grundsätzlich ablehnend sind die Stellungnahmen der EVP und von
Hausärzte Schweiz. Rund 20 Organisationen haben grundsätzliche Bedenken. Die Zustimmung ist aber insgesamt sehr
gross. Aufgrund der Eingaben muss der Bundesrat nun vor allem folgende wichtigen Fragen beantworten:
Wie werden Patienten gemeinschaftsübergreifend identifiziert (soll die z.B. die AHV-Nr verwendet werden)?
Welche Anreize sollen geschaffen werden, um eHealth rascher vorwärts zu bringen?
Im April 2012 hat der Bundesrat das Eidgenössische Departement des Innern EDI damit beauftragt, bis Ende 2012
Botschaft und Gesetzesentwurf zum elektronischen Patientendossier auszuarbeiten.
Weitere Informationen zum elektronischen Patientendossier Gesetz (EPDG):
http://www.bag.admin.ch/themen/gesundheitspolitik/10357/10360/index.html?lang=de
4 http://www.bag.admin.ch/themen/gesundheitspolitik/10357/10360/index.html?lang=de
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 10 von 54 | 25.08.2012 | Version 1.1
3.4 IHE Initiative
IHE (Integrating the Healthcare Enterprise) ist eine internationale Initiative zur Verbesserung des technischen Daten-
austausches von IT-Systemen im Gesundheitswesen.
Bei IHE geht es nicht darum neue Standards zu entwickeln, sondern existierende Standards wie DICOM (Digital Ima-
ging and Communications in Medicine) oder HL7 (Health Level 7, in Anlehnung an das ISO-OSI Referenzmodell) zu
fördern. Dazu wurden verschiedene IHE Technical Frameworks erarbeitet, die beschreiben wie existierende Kommu-
nikationsstandards eingesetzt werden sollen um einen fehlerfreien Datenaustausch zu ermöglichen. In einem IHE
Technical Framework werden in Form von Integrationsprofilen verschiedene Anwendungsszenarien beschrieben, in
denen Interaktionen zwischen vielen Computersystemen erforderlich sind.
Die Initiative von IHE wurde im Jahr 1998 in den USA von den Organisationen HIMSS (Healthcare Information and
Management System Society) und RSNA (Radiology Society of North America) gegründet. Die Initiative von IHE ent-
stand aus dem Bedürfnis heraus die immer wiederkehrenden Integrationsprobleme beim Vernetzen von Computer-
systemen zu vermindern. Mittlerweile ist IHE zu einer weltweiten Initiative mit mehreren Länderorganisationen ge-
worden.
Die IHE hat die Technical Frameworks in einzelne Anwendungsgebiete der Gesundheitsinformatik aufgeteilt (IHE Do-
mains). Momentan sind Informationen zu folgenden IHE Domänen öffentlich zugänglich:
Abbildung 4: Evolution IHE Frameworks (Quelle: ihe.net)
3.4.1 IHE Integrationsprofile
Für die Lösung der identifizierten Interoperabilitätsprobleme werden entsprechende Implementierungsleitfäden er-
stellt. Dabei werden bestehende Standards und Normen evaluiert und eingesetzt. Erfahrene IT-Experten im Gesund-
heitswesen legen fest, wie die entsprechenden Standards und Normen angewendet werden sollen. Diese Anweisun-
gen werden in Zusammenarbeit von medizinischen und technischen Fachpersonen in so genannten IHE Integration
Profiles dokumentiert.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 11 von 54 | 25.08.2012 | Version 1.1
Technische Frameworks sind die Kombination von Branche (Gesundheitswesen) und Technologie (ICT). Jedes IHE
Technical Framework besteht darum aus zwei Teilen: Profile und Transaktionen. Die Profile modellieren Geschäfts-
prozesse und beschreiben Probleme und deren Lösungen. Transaktionen definieren im Detail, wie die Profile umge-
setzt werden sollen. Dabei werden existierende und etablierte Standards referenziert und detailliert angegeben, wie
diese Standards im vorliegenden Fall konkret eingesetzt werden sollen.
Abbildung 5: Aufbau IHE Integrationsprofil (Quelle: ihe.net)
3.4.2 IHE Content Profiles
Für ein gemeinsames Verständnis von Dateninhalten werden ebenfalls entsprechende Implementierungsleitfäden
erstellt. Diese, sogenannten Inhaltsprofile (Content Profile) erlauben eine semantische Interoperabilität, ohne dass
Sender und Empfänger sich notwendigerweise kennen. Um die verschiedenen Arten von Dokumenten im Gesund-
heitswesen und den darin stattfindenden Behandlungsprozessen abbilden zu können, hat IHE bereits zahlreiche In-
haltsprofile definiert. Einige Beispiele:
Cardiac Imaging Report Content (CIRC)
Cath Report Content (CRC)
Sharing Laboratory Reports (XD-LAB)
Emergency Department Physician Note (EDPN)
Triage Note (TN)
eNursing Summary (ENS)
Immunization Content (IC)
Newborn Discharge Summary (NDS)
Etc.
Zahlreiche IHE Inhaltsprofile referenzieren dabei den Standard der HL7 Clinical Document Architecture (CDA), welcher
im nachfolgenden Kapitel detaillierter vorgestellt wird.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 12 von 54 | 25.08.2012 | Version 1.1
3.4.3 IHE Connectathon (CAT)
Softwarelieferanten und Gerätehersteller implementieren IHE Integration Profile in ihre Produkte. Im Rahmen der IHE
werden jährlich so genannte Connectathons (CAT) durchgeführt, an welchen die Hersteller die Interoperabilitätsfähig-
keit ihrer Systeme unter Beweis stellen können. Die Teilnahme an einem CAT ermöglicht es einem Anbieter, in einer
überwachten Testumgebung die Reife seiner Umsetzung zu prüfen. An einem CAT werden die Systeme der verschie-
denen Teilnehmer-Firmen vernetzt und es wird getestet ob der Datenaustausch reibungslos funktioniert. Zu diesen
Connectathons können sich Firmen anmelden, deren Produkte Anforderungen von IHE Integrationsprofilen erfüllen.
Um zu den Connectathons zugelassen zu werden, müssen vorgängig Tests durchgeführt werden. Die IHE stellt dafür
Testsoftware zur Verfügung. Anhand der dabei entstandenen Logfiles wird entschieden, ob eine Firma zu dem
Connectathon zugelassen wird und für welche Integrationsprofile sie testberechtigt ist.
Abbildung 6: CAT 2012 in Bern (Bild: Daniel Bleuer)
Die Resultate der Connectathons sind für jeden Interessierten im Internet abrufbar5. Diese Resultate können in Be-
schaffungsprojekten von Informationssystemen verwendet werden. Das Prinzip dieser Testveranstaltung ist einzigar-
tig. Die Verbindung durch die Entwickler von Systemen erfolgt dabei nicht nur auf technischer Ebene. Der Gedanken-
austausch ohne Konkurrenzdruck zugunsten der Sache, also der Interoperabilität ist ein wichtiger Schritt in die Rich-
tung „Plug and Play“, den andere Industrien längst vollzogen haben.
3.4.3.1 Nutzen für die Hersteller
Ausserhalb des Connectathons kann nirgends innerhalb weniger Arbeitstage die eigene Software auf Interoperabilität
mit Konkurrenzprodukten getestet und gegebenenfalls korrigiert werden. Nur am Connectathon sind die relevanten
Personen (Entwickler, Schiedsrichter und nicht selten auch Autoren der Spezifikationen) im gleichen Raum und neh-
men sich für einander Zeit. Nicht selten ziehen sich die Softwareentwickler abends nach Schliessung der Connecta-
thon-Testhalle in ihre Hotelzimmer zurück, um in der eigenen Software Erweiterungen zu implementieren oder Kor-
rekturen vorzunehmen und am Folgetag allfällige, fehlgeschlagenen Tests erneut durchzuführen.
Die Publikation der Testresultate der IHE Webseite kann zu Marketingzwecken durch die Hersteller genutzt werden.
Ein Eintrag beweist die erfolgreiche Teilnahme an den IHE Connectathons und ist dank der Tatsache, dass die Daten-
bank durch die neutrale IHE Organisation geführt wird, besonders aussagekräftig. Darüber hinaus können die Herstel-
ler mittels Selbstdeklaration sogenannte „Integration Statements“ publizieren. Diese zeigen dem interessierten Leser
in einem über alle Hersteller vereinheitlichten Layout auf, welche IHE Akteure und Transaktionen durch ein bestimm-
tes Produkt unterstützt werden.
5 http://connectathon-results.ihe.net/
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 13 von 54 | 25.08.2012 | Version 1.1
3.4.3.2 Nutzen für Anwender
Dank der, durch IHE zunehmend vereinheitlichten Schnittstellen werden Softwaresysteme einfacher austauschbar.
Kunden erhalten somit mehr Handlungsspielraum bei der Wahl der Lieferanten. Zudem werden mit der Publikation
der Testresultate entsprechende Aussagen der Anbieter verifizierbar. Beschaffungen werden effizienter, da einerseits
der Aufwand zur Erstellung von Ausschreibungen mit der Nennung der konkret verlangten und genau referenzierten
IHE Profile wesentlich reduziert werden kann und die eingehenden Angebote damit besser vergleichbar werden. Dar-
über hinaus kann der Kunde davon ausgehen, dass Fehler, die an einem IHE Connectathon gefunden werden, bei der
Migration in seinem Umfeld nicht mehr auftreten. Wenn ein Test als erfolgreich publiziert wird, bedeutet das nämlich,
dass der Hersteller den Test mit mindestens drei Konkurrenzsystemen erfolgreich durchgeführt hat.
3.5 HL7 CDA
Die, in der eHealth Strategie formulierte Vision und die daraus resultierenden Ziele sind sehr ehrgeizig, denn der Ar-
beitsalltag im stark spezialisierten Gesundheitswesen, mit Prozessketten, an denen mehrere Ärzte, diagnostische
Einrichtungen und Spitäler beteiligt sind, erfordert vorgängig die Lösung der Probleme an der Basis. Die „relevanten
Informationen“ müssen zuerst in einer allgemein lesbaren, verständlichen und transportierbaren Form vorliegen.
Mit der Clinical Document Architecture (CDA) von HL7 lassen sich die menschliche Lesbarkeit und die elektronische
Weiterverarbeitung sehr elegant in einem einzigen Standard vereinigen. Die CDA trägt deshalb einen wichtigen Teil
zur Verbesserung der Interoperabilität zwischen verschiedenen Beteiligten in unserem Gesundheitswesen bei. Dabei
wird in erster Linie der betriebsübergreifende Austausch fokussiert. Somit ermöglicht die CDA sowohl den medien-
bruchfreien Dokumentenaustausch wie auch den Aufbau eines zukünftigen elektronischen Patientendossiers im Sinne
der eHealth Strategie des Bundes.
Unser Gesundheitssystem entwickelt sich in Richtung zunehmender Komplexität. Behandlungswege beginnen meist
im ambulanten Sektor, durchlaufen dann mehrere Abklärungsstationen und kommen schliesslich in den stationären
Sektor in Form eines Aufenthaltes im Akutspital, möglicherweise anschliessend in einer Rehabilitationsklinik, um dann
wieder im ambulanten Sektor weitergeführt zu werden. Die Verkettung dieser Behandlungsprozesse mehrerer Ge-
sundheitseinrichtungen erfordert einen engen Datenaustausch. In vielen heutigen Situationen steht der elektroni-
schen Weiterverwendung von Daten nur noch der PDF-Medienbruch im Wege. Anstatt PDF Dateien zu übertragen,
eröffnet sich rein durch die Umstellung des Dateiformats (CDA) ein grosses Potenzial und dies dank der Darstellbarkeit
in jedem Webbrowser erst noch ohne, vom Empfänger eine Anpassung der technischen Infrastruktur oder der Ar-
beitsabläufe zu verlangen.
Deshalb wurde von der HL7 Benutzergruppe Schweiz in einer eigens dafür zusammengestellten Arbeitsgruppe ein
Implementierungsleitfaden in Form einer Spezifikation zur Anwendung der CDA in der Schweiz erarbeitet. Diese Spezi-
fikation ist öffentlich frei verfügbar6. Die aktuelle Version der Spezifikation definiert im Header hauptsächlich die or-
ganisatorischen Eigenschaften eines medizinischen Dokuments (Patientendaten, Empfänger, Ereignis, Dokumen-
tenidentifikation etc.). Die medizinischen Informationen werden in Abschnitte (Sections) und Einträge (Entries) geglie-
dert und im CDA Body dokumentiert (siehe unten). Im CDA Body Level 1, welcher immer zwingend vorhanden sein
muss, werden die medizinischen Informationen als von Menschen lesbarer Freitext erfasst. Mit den CDA Body Levels 2
und 3 können optional elektronisch auswertbare Informationen (Codiersysteme, Codes) ergänzt werden.
6 http://www.hl7.ch
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 14 von 54 | 25.08.2012 | Version 1.1
Von den technischen Möglichkeiten her gesehen wäre es nun ein Einfaches, Arztbriefe anstelle von PDF oder Office-
Dateien in Form von CDA Dokumenten z.B. mittels eMail Attachement zu versenden (Abbildung 7).
Abbildung 7: Wechsel zu strukturierten Dokumenten
Mit dem Einsatz von CDA kann man weiter gehen, als dies bisher allgemein angenommen wird (z.B. automatische
Ablage eines ankommenden Briefes beim richtigen Patienten, direkte Übernahme von Diagnoselisten oder Medika-
mentenlisten). Erforderlich sind Vereinbarungen über Standards, es braucht die eindeutige Identifikation von Patien-
ten, Ärzten, Physiotherapeuten, von Praxis- und Klinikinformationssystemen, es braucht adäquate Diagnose-Codes,
Laboruntersuchungs-Codes, Medikamenten-Codes. Jedes Codierungssystem braucht schliesslich einen eindeutigen
Bezeichner. Je nach Fachgebiet braucht es noch medizinische Terminologien, ein besonders schwieriges Gebiet.
Dazu sollen internationale und damit grenzüberschreitende Standards angewendet werden. Mit dem Einsatz von HL7
CDA und OID können viele dieser Herausforderungen gemeistert werden.
3.5.1 Eigenschaften eines CDA Dokuments
Welches sind nun die Eigenschaften eines CDA-Dokumentes? Ein CDA-Dokument enthält medizinische Informationen
über ein bestimmtes Ereignis (Spitalaufenthalt, konsiliarische Untersuchung, bildgebende Untersuchung usw.) eines
einzigen Patienten (Ausnahmen kommen in der Geburtshilfe vor). Es liegt im XML Format vor, damit handelt es sich
um eine reine Text-Datei mit einem definierten baumartigen Aufbau, der maschinell auf seine Korrektheit kontrolliert
werden kann (XSD; XML Schema). Ein CDA -Dokument kann dank der Verwendung von Stylesheets (XSL Format; Datei,
welche die Darstellung für den Menschen steuert) ohne Installation zusätzlicher Software in jedem heute verfügbaren
Webbrowser dargestellt werden.
Das CDA-Dokument ist unterteilt in einen Header und einen Body (Abbildung 8). Der Header enthält die Informationen
über das Dokument selber: einen weltweit eindeutigen Identifikator (OID), eine Versionierung, eine Referenzierung
(damit nimmt beispielsweise ein Spitalentlassungsbericht Bezug auf einen vorgängig erstellten Kurzbericht), den Ab-
sender und den Empfänger, die für das Dokument verantwortliche Organisation, die Daten zur Person des Patienten,
das Ereignis, welches im Dokument beschrieben ist, z.B. eine bildgebende Untersuchung.
Die eigentlichen klinischen Informationen befinden sich im Body.
Abbildung 8: Aufbau eines CDA- Dokumentes
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 15 von 54 | 25.08.2012 | Version 1.1
Diese Unterteilung in Header und Body hat als grossen Vorteil zur Folge, dass in einem ersten Schritt der Standard
erstellt werden kann, welche die ganze Dokumentenverwaltung grenzüberschreitend über die Institutionen hinweg
frei von Medienbrüchen organisieren kann, indem erst einmal der Header strukturiert ausgestaltet wird. Damit ist der
Weg frei für einen elektronischen Dokumentenaustausch, der die obigen Anforderungen erfüllen kann.
3.5.2 CDA Body Level 1
Im CDA Body Level 1 sind die klinischen Daten völlig frei darstellbar, die Strukturierung erfolgt in sogenannte Sections,
die Freitexte enthalten (Abbildung 9). Damit sind alle Teilnehmer im Gesundheitswesen in der Lage, die Art ihrer bis-
herigen Dokumentenerstellung weiterzuführen.
Abbildung 9: CDA Body Level 1
3.5.3 CDA Body Level 2
Stellt sich nun das Bedürfnis der Teilnehmer nach weiterer Strukturierung ein, müssen sie sich bei Level 2 auf zusätzli-
che Standards einigen. Während Level 1 vor allem die technischen Bereiche der Dokumentenübertragung und damit
die IT-Berufe betrifft, wenden sich Level 2 und 3 fast ausschliesslich an die Teilnehmer in den Gesundheitsberufen. Auf
diesen beiden Levels können Vorlagen für den klinischen Teil vereinbart werden. Diese müssen von den medizinischen
Fachgruppen erarbeitet und von Informatikern implementiert werden. Beispielsweise möchten die Kliniken in den
Überweisungsschreiben gewisse Abschnitte (Sections) vorfinden, etwa einen Abschnitt mit den Diagnosen oder mit
der Medikamentenliste, oder die aktuelle Anamnese (Abbildung 10: Hier wird die Section mit dem Titel „Anamnese“
weltweit eindeutig als „History of present Illness“, übersetzt „Aktuelle Anamnese“, bezeichnet. Dazu wird das Codie-
rungssystem Logical Observation Identifiers Names and Codes (LOINC) verwendet). Mittels XML Schema-Dateien (XSD)
und Schematronregeln lassen sich solche Anforderungen definieren und auch validieren. Diese Informationen lassen
sich dann auch automatisiert aus einem Informationssystem des Absenders übernehmen (Unterstützung beim Erstel-
len eines CDA Arztbriefes) oder automatisiert in ein Informationssystem beim Empfänger ablegen. Die daraus gewon-
nene Effizienz- und Qualitätsverbesserung ist allerdings von der Qualität der zugrunde liegenden Daten abhängig.
Abbildung 10: CDA Body Level 2
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 16 von 54 | 25.08.2012 | Version 1.1
3.5.4 CDA Body Level 3
Im CDA Body Level 3 kommen weitere Spezifikationen hinzu. Über Einträge (Entries) können einzelne Textpassagen
mit zusätzlichen maschinenauswertbaren Informationen angereichert werden. In Abbildung 11 wird das Stichwort
„Asthma“ aus dem Freitext mittels der codierten Terminologe SNOMED CT (Systematized Nomenclature of Human
and Veterinary Medicine) eindeutig bezeichnet und zwecks maschineller Auswertung codiert.
Abbildung 11: CDA Body Level 3
3.5.5 Transport der Dokumente
Beim Transport der Dokumente können verschiedene, heute verfügbare Produkte und Technologien angewendet
werden. Wichtig ist dabei, dass dem Datenschutz gebührend Beachtung geschenkt wird. Gerade die Weitergabe be-
sonders schützenswerter Personendaten, zu welchen insbesondere Daten zur Gesundheit von Personen gehören, wird
durch das Datenschutzgesetz erschwert. Man achte deshalb wie heute beim Austausch von PDF, Fax oder Papierdo-
kumenten darauf, dass die Dokumente nur bei der Existenz einer Einverständniserklärung oder einer daraus resultie-
renden indirekten Legitimation tatsächlich ausgetauscht werden. Beim effektiven Transport sollen digitale Signaturen
(Unverfälschbarkeit der Daten) und Verschlüsselungsalgorithmen (Verhinderung unbefugter Einsichtnahme in die
Daten) eingesetzt werden.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 17 von 54 | 25.08.2012 | Version 1.1
3.5.6 Validierung von CDA Dokumenten
An den internationalen IHE Connectathons in Europa, Nordamerika und Asien wird die Testsoftware „Gazelle“, einge-
setzt. Die Prüfungen von HL7 CDA Dokumenten, welche nach den Vorgaben der verschiedenen IHE Content Profiles
durch Gazelle vorgenommen werden, werden nach folgendem, 3-stufigen Validierungskonzept implementiert:
Abbildung 12: Validierung von CDA Dokumenten
1. Schemakonformität:
Die CDA Dokumente werden gegenüber dem XML Schema von HL7 CDA R2 validiert. Damit wird geprüft, ob das
Dateiformat korrekt ist und den Vorgaben von W3C (wohlgeformtes XML) und den Vorgaben von HL7 CDA
(Schemakonformität) entspricht.
2. Konformität gegenüber dem Modell von HL7 V3 und CDA:
Die CDA Dokumente werden mittels dem Open Source Produkt CDAInstanceValidator, gegenüber dem HL7 Model
Interchange Format (MIF) geprüft. Damit wird geprüft, ob die verwendeten Inhalte im Dokument den Vorgaben
aus dem HL7 Reference In-formation Model (RIM) entsprechen. Dabei werden unter anderem auch vorgegebene
Wertemengen aus HL7 spezifischen Codesystemen validiert (z.B. Geschlecht, Zivilstand etc.).
3. Konformität gegenüber den Geschäftsregeln:
Die CDA Dokumente werden mittels Schematronregeln gegenüber den Vorgaben der verantwortlichen Stellen für
die entsprechenden Dokumenteninhalte validiert (z.B. IHE Content Profiles). Damit wird geprüft, ob das Doku-
ment den, vom Herausgeber der Vorlage beschriebenen Geschäftsregeln entspricht.
Dieses mehrstufige Validierungsverfahren erlaubt die Sicherstellung einer sehr hohen Konformanz auf hohem Detail-
lierungsgrad, ohne die Individualität von Dokumentenvorlagen oder Formularen einzuschränken. Hinzu kommt, dass
die Validierung vollumfänglich unabhängig von den einzelnen Softwareanbietern durchgeführt werden kann. Bei An-
wendung dieses Validierungsverfahrens kann deshalb der Interpretationsspielraum der beteiligten Systeme auf ein
noch nie dagewesenes Minimum beschränkt werden.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 18 von 54 | 25.08.2012 | Version 1.1
3.5.6.1 Schematron
Schematron ist eine XML Technologie zur Validierung von XML Dokumenten wie z.B. HL7 CDA Dokumente. Der Einsatz
von Schematron erlaubt die Prüfung von Geschäftsregeln, welche mit den herkömmlichen und bekannten XML Tech-
nologien (Prüfung nach wohlgeformter XML Syntax und Prüfung der Grammatik mittels XML Schema) nicht geprüft
werden können. Schematron ergänzt die bisherigen Technologien, ersetzt sie aber nicht. Schematron ermöglicht die
Prüfung der Kohärenz der inhaltlichen Beziehungen in einem XML Dokument, welche sich aus der Funktionsweise der
Anwendung ergeben und somit für jede Art von XML Dokumenten unterschiedlich sind. Schematron ermöglicht zu-
dem, Geschäftsregeln für Dokumentenvorlagen oder Formulare durch deren Herausgeber bestimmen und implemen-
tieren zu lassen. Die Schematronregeln liegen damit in der Verantwortlichkeit der herausgebenden Stelle und können
identisch von den verschiedenen verarbeitenden Softwareprodukten eingesetzt werden. Der persönliche Interpretati-
onsspielraum einzelner Entwickler, der bislang etwa zu unterschiedlichen Lösungen geführt hat, ist im Einsatzbereich
von Schematron nicht mehr von Bedeutung.
Abbildung 13: Schematron Prozessschritte
3.5.7 CDATools
Rund um die Erzeugung (Serialisierung) und Verarbeitung (Deserialisierung) von CDA Dokumenten gibt es verschiede-
ne Tools. Aufgrund internationaler Empfehlungen scheint aus heutiger Sicht das OpenSource Projekt CDATools die
erfolgversprechendste Grundlage darzustellen.
Abbildung 14: Methodik zu CDA Tools
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 19 von 54 | 25.08.2012 | Version 1.1
CDA Tools bietet verschiedene Werkzeuge, welche gut zu den hier diskutierten Anforderungen passen:
Erstellen von Code zu Anwendungsspezifischen CDA Dokumenten (Model-Driven Development Process)
Runtime API
o Serialisierung/Deserialisierung von CDA Dokumenten (XML <-> Modell)
o Validierung
Die Plattformunabhängigkeit und die Integration in Arztpraxissoftware (APS) dürfte durch die Verfügbarkeit als Java
Komponente gegeben sein. Eine tiefergehende Beurteilung kann zum heutigen Zeitpunkt nicht abgegeben werden.
CDATools sind sogenannte Model-Driven Health Tools (MDHT) for CDA, die ist heute bereits verfügbar sind und ge-
nutzt werden können.
Abbildung 15: Einsatzbereich MDHT CDA Tools
Weitere Informationen zu CDATools:
http://www.cdatools.org/
http://openhealthtools.org/
http://wiki.siframework.org/Model+Driven+Health+Tools+%28MDHT%29
3.6 Elexis
Elexis ist das führende OpenSource Arztpraxisprogramm im deutschsprachigen Raum. Elexis bietet dank seiner Offen-
heit einen unübertroffenen Investitionsschutz für die Daten einer Arztpraxis. Elexis ist ein Produkt für elektronische
Krankengeschichtsführung, Lagerverwaltung, Abrechnung und Debitorenkontrolle. Es ist flexibel, individuell ausbaubar
und bietet im Bereich Datennutzung viele Vorteile für Ärztenetzwerke, Forschung und Qualitätsentwicklung.
Elexis ist in einem OpenSource Repository von SourceForge7 unter der Eclipse Public License, sowie auf www.elexis.ch
kostenlos veröffentlicht.
Einige Firmen bieten kostenpflichtige Zusatzleistungen rund um Elexis an. So z.B. PraxisIT GmbH, Medelexis AG und
weitere. Zudem bieten mehrere Firmen (unter anderem die medshare GmbH; siehe www.medshare.net/elexis)
Dienstleistungen für Softwareentwicklung rund um Elexis an.
Weitere Informationen zum OpenSource Produkt Elexis: www.elexis.ch, www.elexis-forum.ch
7 ssh://elexis.hg.sourceforge.net/hgroot/elexis/elexis-base
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 20 von 54 | 25.08.2012 | Version 1.1
3.7 FIRE
FIRE steht für Family Medicine ICPC Research using Electronic Medical Records. Nachfolgende Informationen wurden
dem FIRE Flyer und weiteren Informationen ab http://icpc.ch/index.php?id=33 entnommen.
3.7.1 Ausgangslage
In den Schweizer Hausarztpraxen wird noch mehrheitlich papierbasiert dokumentiert. Der Trend zur elektronischen
Dokumentation ist eindeutig, obwohl die Geschwindigkeit der Umstellung sehr langsam ist. Dennoch: Wenn in einer
Praxis der Kernprozess, die medizinische Dokumentation, elektronisch abgewickelt wird, stehen wichtige Daten der
hausärztlichen Tätigkeit digital zur Verfügung und stellen damit ein grosses Potenzial für die Forschung dar.
SGAM.Informatics hat sich dafür eingesetzt und mehrheitlich auch erreicht, dass die Praxisinformationssysteme ge-
wisse minimale Anforderungen erfüllen. Dies gilt im Besonderen für die elektronische Krankengeschichte (siehe
ROADMAP, SAEZ 2008; 89: 32). Nebst der Forderung nach einer minimalen Strukturierung wurde ICPC-2 als Klassifizie-
rungssystem eingeführt und ist der SGAM-Standard zur Führung der Problemliste geworden. Führende Praxissoft-
wareprodukte, darunter auch Elexis unterstützen ICPC-2.
Seit Januar 2009 konnten von 65 Hausärzten erfolgreich Daten hochgeladen werden. Damit waren am 31.12.2011
> 650'000 Konsultationen mit
> 750’000 ICPC-Codes von
> 120'000 Patienten
online und zur Auswertung verfügbar. Der Machbarkeitsnachweis (proof of concept) ist somit erbracht und der
Grundstein für den klinischen Praxisspiegel gelegt. Die Projektteilnehmer erhalten monatliche Feedbacks. Beispiele
von solchen Berichten sind online unter www.icpc.ch einsehbar.
3.7.2 Ablauf und Inhalt
In einer papierarmen Praxis sind viele Daten in elektronischer Form vorhanden und können bei Bedarf anonymisiert
auf einen zentralen Server transferiert werden. So können routinemässig erhobene Daten mit relativ geringem Auf-
wand der Forschung zur Verfügung gestellt werden.
Abbildung 16: FIRE Daten-Export aus Praxissoftware
FIRE sieht in einer ersten Phase ein definiertes Daten-Set vor. Pro Konsultation sind dies:
Alter und Geschlecht des Patienten (Jahrgang; male/female)
Vitaldaten (Systolischer/diastolischer Blutdruck, Puls, Gewicht, BMI, BU)
Labordaten folgender Analysen: Hb, Lc, CRP, BKS, Kreatinin, Cholesterin, HDL, LDL, Triglyceride, Transaminasen,
Glucose nüchtern, HbA1C, PSA
Medikamente (Pharmacode) mit Dosierungen
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 21 von 54 | 25.08.2012 | Version 1.1
Dieses Set wird ergänzt durch den ICPC-2-Code. Dabei werden vorerst nur die behandlungsrelevanten Probleme nach
ICPC-2 erfasst und entsprechend exportiert. Diverse Softwarefirmen haben inzwischen nebst ICPC auch ein Exporttool
implementiert und erlauben so den Projektteilnehmern, ihre Daten zur Verfügung zu stellen.
3.7.2.1 XML Schema
Das FIRE Daten-Set wird anhand des folgenden XML Schemas erstellt:
Abbildung 17: XML Schema der bisherigen FIRE Meldung
3.7.2.2 Beispiel XML <?xml version="1.0" encoding="utf-16"?> <meldung> <konsultation> <konsdate>2009-02-02</konsdate> <patid>14353</patid> <patyear>1931</patyear> <patgender>female</patgender> <arzt>7601000177049</arzt> <diagnose> <icpc>A07</icpc> </diagnose> <diagnose> <icpc>A26</icpc> </diagnose> <diagnose> <icpc>A31</icpc> </diagnose> <vital> <bdsyst>190</bdsyst> <bddiast>90</bddiast> <puls>110</puls> <groesse>187</groesse> <gewicht>102</gewicht> <bauchumfang>95</bauchumfang> </vital>
<labor> <labordate>2008-06-13</labordate> <analyse>BSR</analyse> <einheit>mm/h</einheit> <max> 4</max> <laborwert>8</laborwert> </labor> <medi> <pharmacode>2764434</pharmacode> <dosismo>1</dosismo> <stopdate>2009-02-02</stopdate> </medi> <medi> <pharmacode>1377592</pharmacode> <dosismo>1</dosismo> <dosismi>1</dosismi> <dosisab>1</dosisab> <stopdate>2009-01-01</stopdate> <stopbegr>Unverträglichkeit</stopbegr> </medi> </konsultation> </meldung>
Abbildung 18: Beispiel einer bisherigen XML FIRE Meldung
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 22 von 54 | 25.08.2012 | Version 1.1
3.7.3 Datenqualität
Das Projekt steht oder fällt mit der Datenqualität. Wenn nicht korrekt und möglichst homogen codiert wird, nützt alle
Technik und Architektur nichts. Dies erfordert Schulung und regelmässigen Austausch unter den Projektteilnehmern.
Inzwischen haben schon mehrere Einführungsworkshops stattgefunden. Künftig wird der Schwerpunkt der Projektar-
beit die Optimierung der Datenqualität sein; langfristig werden diese Erkenntnisse auch zur Verbesserung der Praxis-
software-Tools dienen.
3.7.4 Perspektiven
Ziel ist es, eine repräsentative Gruppe von zuverlässig codierenden Hausärzten zu erreichen. In einem ersten Schritt
werden nur die behandlungsrelevanten Probleme erfasst. Ein späterer Ausbau ist möglich, mit der zusätzlichen Codie-
rung des sogenannten Beratungsanlass oder RFE (Reason for Encounter) ebenfalls nach ICPC. Eine spätere Abbildung
des ganzen Episodenkonzeptes ist möglich, erfordert dann aber einen deutlichen Mehraufwand für diejenigen Haus-
ärzte, welche diese Episoden überwachen möchten.
3.7.5 Wissenschaftliche Leitung
Die wissenschaftliche Leitung des Projektes liegt in der Verantwortung des Instituts für Hausarztmedizin der Universi-
tät Zürich (IHAMZ, Prof. Thomas Rosemann). Das Projekt wird begleitet von Dres med. Sima Djalali, Marco Zoller und
Prof. André Busato, Wissenschaftliche Mitarbeiter am IHAMZ. Die Projektleitung hat Dr. med. Heinz Bhend.
3.8 eImpfdossier
Mit einem Projekt „eImpfdossier" möchte der Steuerungsausschuss von „eHealth Suisse" ein erstes national koordi-
niertes „eHealth"-Vorhaben realisieren. Die Chancen für eine erfolgreiche Umsetzung eines „Elektronischen Impfdos-
siers" scheinen gut. Das Koordinationsorgan hat deshalb Mitte 2011 den Auftrag zur Erarbeitung einer Vorstudie e-
Impfungen erteilt.
Die Vorstudie wurde am 16.01.2012 publiziert. Im Bereich der Lösungsarchitektur verweist diese auf ein eigens dafür
erstelltes Whitepaper „Grundlagen für ein elektronisches Impfdossier“ der HL7 Benutzergruppe Schweiz8. Neben den
zu klärenden Punkten (Verhältnis zu bestehenden Modellversuchen, Trägerschaft und Finanzierung, Rechtliche Grund-
lagen, sowie das weitere Vorgehen zur Vertiefung der konzeptionellen Arbeiten und die Roadmap) wurde zu keinem
Zeitpunkt an der Definition des Dateninhaltes gezweifelt, welcher auf HL7 CDA basiert und im IHE Integrationsprofil
„Immunization Content (IC)“9 genauer spezifiziert wird. Für die konkrete Anwendung in der Schweiz muss in Ergän-
zung zum IHE Integrationsprofil noch ein Implementierungsleitfaden erstellt werden, welcher die helvetischen Aus-
prägungen des elektronischen Impfausweises festlegt.
Fazit aus dem Zwischenbericht10
vom 19. April 2012:
Die Resultate der „Vorstudie elektronisches Impfdossier“ vom Januar 2012 haben noch keinen endgültigen Konsens
unter den beteiligten Akteuren gebracht. Bis die kantonalen oder regionalen Modellversuche eine kritische Masse der
Bevölkerung mit einem „e-Impfdossier“ erreichen, könnte es noch länger dauern, da dort ein elektronisches Patien-
tendossier als Basiselement angestrebt wird. Dahingegen scheinen die privaten Bemühungen durch z.B. meineimp-
fungen.ch“ oder das Gesundheitsdossier „Evita“, die beide heute schon ein „e-Impfdossier-Service“ anbieten, schnel-
ler eine kritische Masse zu erreichen.
8 http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/Whitepaper_GrundlagenElektronischesImpfdossier_V1.0.pdf
9 http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Suppl_Immunization_Content_Rev2-2_TI_2011-09-09.pdf
10 http://www.e-health-suisse.ch/umsetzung/00135/00218/index.html?lang=de
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 23 von 54 | 25.08.2012 | Version 1.1
Trotz teilweise gegensätzlichen Standpunkten werden diese konkreten Schritte vorgeschlagen:
1. Umsetzung eines schweizweit verfügbaren Impfcheck-Services als Clinical Decision Support System (CDSS), wahr-scheinlich auf Basis von Viavac (Frau Dr. Siegrist)
2. Die technischen und semantischen Analysen zum Datenaustauschformat des „e-Impfdossiers“ sollten fortgeführt werden und in einer konkreten Empfehlung münden
3. Es soll untersucht werden, welche temporären Zwischenlösungen mit privaten Providern denkbar wären, ohne dabei die Empfehlungen des Teilprojektes „Standards und Architektur“ zu unterlaufen. So könnte zum Beispiel das Thema Identifikation von Patienten und Behandelnden mit den heute zur Verfügung stehenden Mitteln ange-gangen werden.
Abbildung 19: Roadmap eImpfdossier
Weitere Informationen zum eImpfdossier:
http://www.e-health-suisse.ch/umsetzung/00135/00218/index.html?lang=de
3.9 EPha.ch
EPha.ch ist ein Spin Off der Klinischen Pharmakologie des Universitätsspitals Zürich. Die Vision von EPha.ch lebt von
dem Wunsch Ärzten, Patienten und Apotheker in der medikamentösen Therapie optimal zu unterstützen. Über das
Portal von EPha.ch sind folgende Services verfügbar:
Interaktionen
Rezept Service
Diese beiden Services werden in den nachfolgenden Unterkapiteln kurz erklärt. Weitere Informationen können der
Webseite http://epha.ch entnommen werden, welche auch Quelle für diese Zusammenfassung ist.
3.9.1 Interaktionen
Die Interaktionen werden als wissenschaftliches Gut der Allgemeinheit zur Verfügung gestellt. Die
Veröffentlichung erfolgt unter der Creative Commons Attribution-NonCommercial-NoDerivs 3.0
Unported Lizenz. Die Ziele dabei sind:
eine moderne, wissenschaftlich fundierte Datenbank kontinuierlich zu erweitern
die speziellen Anforderungen des Schweizerischen Verordnungsverhaltens zu berücksichtigen
und einen lebhaften Austausch mit Ärzten, Apothekern und Softwarehäusern zu praktizieren
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 24 von 54 | 25.08.2012 | Version 1.1
Der IC2-Interaktions-Check ist als lernendes System konzipiert und in vollem Funktionsumfang nur im Rezeptservice
integriert. Das kollektive Verschreibungsverhalten auf EPha.ch, die Meldungen der Pharmakovigilanz und des Medi-
kamenteninformationsdienstes der Klinischen Pharmakologie und Toxikologie des Universitätsspitals Zürich werden
genutzt, um klinisch relevante Interaktionen zu identifizieren und als visualisierte Information dem Kollektiv der Ärzte
zurückzuführen. Um die Transparenz in diesem Prozess zu sichern, wird namentlich auf den Autor jeder Interaktion
verwiesen und regelmässig der Projektstatus publiziert. Das Verschreibungsverhalten soll durch gezielte visualisierte
Information unterstützt und die medikamentöse Therapie wissenschaftlich nachvollziehbar optimiert werden. Einzig-
artig an diesem Konzept ist, dass jede Interaktion eine Richtung aufweist. Es gibt also normalerweise einen Täter (Ur-
sache der Interaktion) und ein Opfer (unerwünschte Wirkungen dieser Substanz werden wahrscheinlicher). Allerdings
haben manche Substanzen einen Pfeil mit zwei Spitzen, d.h. der Pfeil zeigt in beide Richtungen. Dies ist darüber zu
erklären, dass sich die Substanzen gegenseitig beeinflussen.
Abbildung 20: Visualisierung von Interaktionen auf EPha.ch
3.9.2 Rezept Service
EPha.ch ist ein Rezept Service, welcher das Verschreiben von Arzneimitteln unterstützt. Die Applikation ist für alle
Ärzte und Apotheker kostenfrei. Es können Wirkstoffe und Medikamente gesucht und nach Anmeldung einem Rezept
hinzugefügt werden. Das Rezept wird automatisch auf allfällige Interaktionen überprüft. Auf Wunsch kann das Logo
auf dem Rezept angepasst werden.
Eingebaute Checks
Plausibilitätschecks der verschriebenen Dosis
Tools für das richtige Verschreiben von Medikamenten an Schwangere und Patienten mit Niereninsuffizienz
Automatische Prüfung von Interaktionen
Aktive Vorschläge für alternative Medikamente derselben Therapiegruppe
Einfache Einbindung in die IT-Infrastruktur des Spitals
Freie und unverbindliche Nutzung
Weitere Funktionen
Schnelle Referenz auf das Arzneimittelkompendium
Anbindung an Logistik möglich
Ausgestellte Rezepte werden archiviert und können über die EPha.ch-ID wieder aufgerufen werden.
Zusatzinformationen über das Medikament
Rezeptfunktion für das effiziente Verschreiben von häufigen Therapien
Nachbestellen von Medikamenten und Broschüren, Informationsmaterial und Bestellformulare für Ärzte
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 25 von 54 | 25.08.2012 | Version 1.1
4 Relevante Grundlagen
Das vorliegende Dokument nimmt Bezug auf vorbestehende Architekturgrundlagen und baut insbesondere auf fol-
genden Dokumente und Empfehlungen auf. Die genannten Referenzen sind im Kapitel „8.1 Referenzierte Dokumente“
auf Seite 49 aufgeführt.
4.1 eHealth Suisse
1. Die Standardisierung erfolgt prozessorientiert mit Anwendungsfällen basierend auf der IHE Initiative (Integrating the Healthcare Enterprise, www.ihe.net), insbesondere mit den Integrationsprofilen der Domäne IT-Infrastructure [Empfehlungen I], S. 7
2. Basiskomponenten der Architektur „eHealth Schweiz“ [Empfehlungen I], S. 6
3. Der Dokumentenaustausch in der Schweiz basiert auf gleichberechtigten Gemeinschaften, die über einen oder mehrere Zugangspunkte kommunizieren. [Empfehlungen II], Empfehlung 1, S. 10
4. Damit der Austausch zwischen Gemeinschaften funktioniert, müssen übergeordnete Regeln festgelegt werden. Regeln werden nur formuliert, soweit sie für den Austausch zwischen Gemeinschaften erforderlich sind; Gemein-schaften bleiben in ihrer internen Systemgestaltung frei. [Empfehlungen II], Empfehlung 2, S. 12
5. Es wird ein Schweiz weites Verzeichnis der zertifizierten Gemeinschaften geführt. Nur diese erhalten die Möglich-keit, am Dokumentenaustausch teilzunehmen. [Empfehlungen II], Empfehlung 3, S. 12
Die [Empfehlungen III] enthalten vor allem Empfehlungen zum gemeinschaftsübergreifenden Berechtigungskonzept, welches im vorliegenden Kontext nicht besonders relevant ist, da es sich bei einzelnen Arztpraxen nicht um eine Ge-meinschaft im Sinne von eHealth Suisse handelt.
Hingegen sind die Empfehlungen I besonders relevant, weil diese dezentrale Dokumentenablagen vorsehen. Daraus folgend, müssen gemeinsam verwendete Dokumente von allen Teilnehmern am System „eHealth Schweiz“ verstan-den werden können, auch wenn diese sich nicht notwendigerweise kennen. Deshalb ist es notwendig, dass auch von und zu Arztpraxissoftware (APS), welche sich innerhalb von zukünftigen Gemeinschaften befinden werden, solche Dokumente ausgetauscht werden können.
Das IHE Integrationsprofil Cross-Enterprise Document Sharing (XDS) hat dabei eine besondere Bedeutung (siehe Kapi-tel „6 Technisches Konzept“ auf Seite 32). Dokumente können gemäss Empfehlungen z.B. in sogenannten IHE XDS Repositories und Registries gespeichert werden. Sämtliche Ausführungen im vorliegenden Konzept sind konform zu den Architekturgrundlagen von eHealth Suisse.
4.2 IHE Implementierungsleitfäden
Folgende IHE Implementierungsleitfäden zu Integrationsprofilen sind im vorliegenden Kontext relevant:
1. Audit Trail and Node Authentication (ATNA)
Basisinfrastruktur für eine sichere und vertrauenswürdige Systemteilnahme von IHE Akteuren
Weitere Informationen: [IHE ITI TF-1], Kapitel 9
2. Cross-Enterprise Document Sharing (XDS)
Basisinfrastruktur zur betriebsübergreifenden Nutzung von Dokumenten.
Weitere Informationen: [IHE ITI TF-1], Kapitel 10
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 26 von 54 | 25.08.2012 | Version 1.1
3. IHE Patient Care Coordination (PCC) Technical Framework
Basisinfrastruktur für eine koordinierte Informationsübergabe bei der Übergabe der Verantwortlichkeit an einen
anderen Behandelnden im Behandlungsprozess eines Patienten
Weitere Informationen: [IHE PCC TF-1]
4. Community Medication Prescription and Dispense (CMPD)
Basisinfrastruktur für den betriebsübergreifenden Informationsaustausch zur medikamentösen Therapie
Supplement for Trial Implementation
Weitere Informationen: [IHE PHAR CMPD]
5. Patient Identifier Cross-referencing HL7 V3 (PIXV3)
Integrationsprofil für den Abgleich der Patienten-Identifikationen aus verschiedenen Systemen/Domänen
Weitere Informationen: [IHE ITI TF-1], Kapitel 23
6. Patient Demographics Query HL7 V3 (PDQV3)
Integrationsprofil für die Abfrage von Patienten mittels demografischen Suchattributen
Weitere Informationen: [IHE ITI TF-1], Kapitel 24
7. Document Digital Signature (DSG)
Integrationsprofil für die digitale Signatur von Dokumenten
Supplement for Trial Implementation
Weitere Informationen: [IHE DSG]
8. IHE Notification of Document Availability (NAV)
Integrationsprofil für die Benachrichtigung, wenn ein neues Dokument verfügbar ist
Supplement for Trial Implementation
Weitere Informationen: [IHE NAV]
Folgende IHE Implementierungsleitfäden zu Content Profiles sind im vorliegenden Kontext relevant:
9. IHE Patient Care Coordination CDA Content Modules
Dieses Profil macht zahlreiche Vorgaben zum Einsatz von CDA in mehreren IHE Implementierungsleitfäden
Supplement for Trial Implementation
Weitere Informationen: [IHE PCC CDA]
10. IHE Pharmacy Pharmaceutical Advice (PADV)
Dieses Profil ist für die Rückmeldung von Interaktionschecks aus EPha.ch (Import in APS) relevant
Supplement for Trial Implementation
Weitere Informationen: [IHE PHAR PADV].
11. IHE Pharmacy Prescription (PRE)
Dieses Profil ist für die Übermittlung eines Rezepts von einer APS an EPha.ch relevant - für die Nutzung des Inter-
aktionschecks oder des Rezept Services
Supplement for Trial Implementation
Weitere Informationen: [IHE PHAR PRE]
12. IHE Immunization Content (IC)
Dieses Profil ist für die Übermittlung von Impfungen ans eImpfdossier oder an einen Impfcheck-Service und auch
für die Abfrage des elektronischen Impfausweises aus dem eImpfdossier und dessen Import in eine APS relevant.
Verabschiedetes Supplement for Trial Implementation (wird in den offiziellen Release von IHE PCC einfliessen)
Weitere Informationen: [IHE PCC IC]
Es ist zu beachten, dass einige der obenstehenden IHE Profile den Status „Trial Implementation“ haben und demzufol-
ge nach den ersten Tests an IHE Connectathons noch Änderungen zu erwarten sind. Die Leitfäden scheinen aber quali-
tativ hochwertig und es kann davon ausgegangen werden, dass keine markanten Änderungen notwendig sind.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 27 von 54 | 25.08.2012 | Version 1.1
4.3 CDA-CH Spezifikationen
Folgende Spezifikationen der HL7 Benutzergruppe Schweiz sind im vorliegenden Kontext relevant:
1. CDA-CH
Diese Spezifikation, auch unter eCH-0089 veröffentlicht, macht Vorgaben zum CDA Header und definiert den Ein-
satz von HL7 CDA in der Schweiz.
Weitere Informationen: [CDA-CH]
2. CDA-CH-II
Diese Spezifikation, auch unter eCH-0121 veröffentlicht, macht Vorgaben zum Einsatz von Schematronregeln.
Weitere Informationen: [CDA-CH-II]
4.4 OID Konzept
Folgende Informationen rund um weltweit eindeutige Objektbezeichner, sogenannte OID sind im vorliegenden Kon-
text relevant:
1. OID Konzept
OID-Konzept für das Schweizerische Gesundheitswesen
Weitere Informationen: [OID Konzept]
2. OID Register
OID Register der Stiftung Refdata
Weitere Informationen: [OID Register] ; http://oid.refdata.ch
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 28 von 54 | 25.08.2012 | Version 1.1
5 Organisatorisches Konzept
5.1 Betriebsübergreifende Zusammenarbeit
Der Bedarf, Dokumente im Behandlungsprozess auszutauschen ist gross und unbestritten. Die Fallbeispiele Hüftgelen-
kersatz in [CDA-CH] und Auffahrunfall in [CDA-CH-II] zeigen deutlich die grosse Anzahl Dokumente und die Vielfältig-
keit und Komplexität der Inhalte dieser Dokumente, die zwischen verschiedenen Beteiligten im Behandlungsfall ausge-
tauscht werden müssen. Heute geschieht dies wie einleitend ausgeführt mit herkömmlichen Mitteln, welche zahlrei-
che Medienbrüche zur Folge haben und welche es verhindern, enthaltene Information elektronisch auswerten zu
können.
Damit der medizinische Behandlungsprozess mit dem elektronischem Datenaustausch tatsächlich effizienter gemacht
und damit ein Beitrag zu höherer Behandlungsqualität und Patientensicherheit geleistet werden kann, müssen die
Daten technisch und semantisch interoperabel ausgetauscht werden. Ansonsten verlagern sich die organisatorischen
Problemstellungen nur von der einer technischen Ebene auf eine andere technische Ebene und die Systemteilnehmer
haben damit nur Aufwand statt Nutzen.
Im Zuge der immer mobiler werdenden Gesellschaft, kann der Behandlungspfad nicht geografisch eingegrenzt werden
und nicht selten spielen sich Behandlungsprozesse über Landesgrenzen hinweg ab. Aus diesem Grund ist eine interna-
tionale Harmonisierung von elektronischen Daten im Gesundheitswesen unabdingbar.
Das organisatorische Konzept für die betriebsübergreifende Zusammenarbeit lautet demzufolge:
1. Keine geografischen Grenzen zwischen Beteiligten am Behandlungspfad ziehen
2. Sender und Empfänger kennen sich nicht notwendigerweise. Deshalb kann und darf es keine gesonderten Ab-
sprachen zwischen Sender und Empfänger geben.
3. Interoperabilität muss auf technischer und semantischer Ebene gewährleistet sein, damit der Prozess auch tat-
sächlich unterstützt werden kann.
4. Der Einsatz von international akzeptierten Standards ist demzufolge unabdingbar. Auch wenn Standards nicht
sämtliche erdenklichen Situationen aus der realen Welt abdecken können, ist der Nutzen des Einsatzes von Stan-
dards dennoch viel höher als der Umsetzung mit proprietären Lösungen (vgl. Pareto-Prinzip).
5. Die menschliche Lesbarkeit von Dokumenten muss in jedem Fall ausnahmslos gewährleistet bleiben.
Dies weil Softwaresysteme nicht in der Lage sein müssen, sämtliche verlangten Daten in strukturierter Form zu
produzieren resp. zu verarbeiten.
5.2 Nutzung medizinischer Daten in einer Gemeinschaft
Die Bereitstellung von IT Infrastruktur zur optimalen Erfassung und Nutzung von elektronischen Daten bedeutet für
alle Beteiligten im Gesundheitswesen eine hohe Investition. Die Komplexität solcher Infrastrukturen nimmt fortlau-
fend zu. Die notwendigen Beschaffungen, die für die Umsetzung der eHealth Architektur Schweiz notwendig sind,
können nicht von einzelnen Institutionen getätigt werden. Es ist auch gar nicht zielführend, wenn jede Institution –
z.B. Arztpraxen - ihre Systeme so bereitstellen, dass sie direkt mit allen anderen Institutionen Daten austauschen kön-
nen. In Zukunft werden sich deshalb Behandelnde vermehrt in Gemeinschaften zusammenschliessen.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 29 von 54 | 25.08.2012 | Version 1.1
Die Erstellung einer Gemeinschaft ist ein organisatorischer Prozess, in welchem sich die Beteiligten vertraglich darüber
einigen, gemeinsam medizinische Daten zu verwenden. Der Begriff „Gemeinschaft“ wird aus dem englischen Begriff
„Public Health Information Affinity Domain (PHIAD)“ abgeleitet, welcher von IBM im Jahr 2008 definiert worden ist11
:
Abbildung 21: Affinity Domain (Quelle: IBM)
Wie aus dieser Grafik ersichtlich ist, können Gemeinschaften durchaus ineinander verschachtelt sein. Es kann auch
davon ausgegangen werden, dass die Anzahl und Grösse von Gemeinschaften in der Schweiz über die Zeitachse gese-
hen dynamisch verändern wird.
Als mögliche Gemeinschaften können Ärztenetzwerke, Kantone, Spitalregionen oder auch regionsübergreifende Insti-
tutionen verstanden werden. Es ist auch denkbar, dass sich in grenznahen Regionen auch länderübergreifende Ge-
meinschaften entwickeln. So z.B. Region Basel-Lörrach-Mulhouse, Region Genf-Frankreich, Region Bodensee (CH-AT-
DE) oder das Tessin mit der Lombardei.
Gemäss den bisherigen Empfehlungen von Standards und Architektur werden Gemeinschaften, welche am System
„eHealth Schweiz“ partizipieren wollen, zertifiziert werden müssen und technische Zugangangspunkte, sogenannte
Gateways bereitstellen.
Abbildung 22: Basiskomponenten von Gemeinschaften
11
http://researcher.watson.ibm.com/researcher/view_project.php?id=892 oder http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/trackingdiseases/transform/
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 30 von 54 | 25.08.2012 | Version 1.1
In einer Gemeinschaft nutzen die Systemteilnehmer also gemeinsam medizinische Daten zu Patienten. Die vertragli-
chen, datenschutzrechtlichen und technischen Voraussetzungen sind durch die Gemeinschaft sicherzustellen. Die
bisherigen Empfehlungen von eHealth Suisse lassen den Gemeinschaften die interne Ausgestaltung frei. Sobald Ge-
meinschaften Daten von anderen Gemeinschaften abfragen oder solche zur gemeinschaftsübergreifenden Abfrage zur
Verfügung stellen wollen, werden die Empfehlungen von Standards und Architektur relevant, welche in technologie-
neutraler Form auch in das EPDG einfliessen.
Egal ob Behandelnde innerhalb einer Gemeinschaft oder gemeinschaftsübergreifend gemeinsame Daten nutzen oder
austauschen wollen: Es kann nur dann funktionieren, wenn die von einem beliebigen Sender erstellten Dokumente
von einem beliebigen Empfänger gelesen und verstanden werden können. Die HL7 Clinical Document Architecture
(CDA) bietet dazu heute die weltweit besten Voraussetzungen. Dies insbesondere aufgrund der Kombination von
menschlich lesbarem und maschinenauswertbarem Inhalt.
APS sollen deshalb so erweitert werden, dass HL7 CDA Dokumente mit unterschiedlichen medizinischen Inhalten er-
stellt und verarbeitet werden können. Dabei ist die Umsetzung zwar generisch und wiederverwendbar vorzusehen, im
konkreten Fall müssen aber die genauen Dokumenttypen (IHE Content Profiles resp. CDA Templates) individuell un-
terstützt werden. In jedem Fall muss eine APS die unveränderbare Darstellung zum Zeitpunkt der Signierung durch
den Autor des Dokuments in menschlich lesbarer Form darstellen können. Dies gilt unabhängig von Erstellungs- und
Anzeigezeitpunkt sowohl für importierte, wie auch für exportierte Dokumente.
5.3 Schützenswerte Information
Rund um den Austausch von elektronischen Dokumenten gelten die gleichen Schutzmassnahmen wie für herkömmli-
che Dokumente. Im Unterschied zum papierbasierten Datenaustausch ist beim elektronischen Datenaustausch aller-
dings zusätzlich zu berücksichtigen, dass das Missbrauchspotenzial und auch die Auswirkung bei einem Missbrauch
grösser sind, da eine maschinelle Verarbeitung unabhängig von Zeit und Ort möglich ist. Demzufolge sind zu den bis-
her geltenden Zutrittsschutz und Geheimhaltungsmassnahmen auch elektronische Schutzmassnahmen zu treffen,
welche Unbefugten den Zugang zu digitalen Informationen verweigern. Diese Schutzmassnahmen sollen allerdings
ausserhalb des vorliegenden Konzepts vor allem im Bereich der IT Infrastruktur einer Institution eingebaut werden.
Die dazu relevanten gesetzlichen Grundlagen sind vielfältig und befinden sich in verschiedenen Bereichen der Gesetz-
gebung. So unter anderem im Datenschutzgesetz oder im Krankenversicherungsgesetz. Darüber hinaus wird auch das
EPDG eine wichtige Bedeutung haben. Es würde den Rahmen des vorliegenden Konzeptes sprengen, hier alle relevan-
ten Gesetzesgrundlagen zusammen zu stellen. Dieses Konzept beschränkt sich deshalb auf die Nennung folgender
wesentlicher Elemente (Liste nicht abschliessend).
Daten zur Gesundheit von Personen gehören gemäss Datenschutzgesetz in die Kategorie besonders schützenswerter
Daten. Dem Schutz dieser Daten ist also besondere Aufmerksamkeit zu schenken. Dabei gilt es zwischen Persönlich-
keitsschutz und Patientensicherheit zu unterscheiden.
Die Behandlungsqualität ist dann am höchsten, wenn Behandelnde eine vollständige Sicht auf den Gesundheitszu-
stand des Patienten haben. Sobald der Patient dem Behandelnden etwas nicht mitteilt oder dafür sorgt, dass Teile der
Krankengeschichte wegen Berechtigungsverweigerung nicht auffindbar sind, führen dazu, dass der Patient dem Be-
handelnden gezielt Informationen verschweigt, ohne sich möglicherweise bewusst zu sein, dass er damit seine eigene
Gesundheit gefährden oder zumindest die Behandlungsqualität verschlechtern kann.
Dennoch kann es durchaus im Interesse des Patienten sein, gerade sogenannt stigmatisierende Daten nur Vertrau-
enspersonen zugänglich zu machen.
Jeder Bürger muss sich also ganz persönlich dazu entscheiden, ob ihm der Schutz seiner Persönlichkeit oder die Be-
handlungsqualität und Patientensicherheit wichtiger ist. Dazu ist zu beachten, dass sich dieses individuelle Bedürfnis je
nach Lebenslage sehr rasch ändern kann. Ein gesunder Mensch wird wohl eher den Persönlichkeitsschutz als wichtig
einstufen und ein kranker Mensch wird evtl. die Behandlungsqualität über den Persönlichkeitsschutz stellen.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 31 von 54 | 25.08.2012 | Version 1.1
Die Softwaresysteme sollen deshalb in Zukunft auch technische Möglichkeiten bieten, Einverständniserklärungen von
Patienten digital zu verwalten und diese bei Zugriffen auf Dokumente durch Behandelnde anzuwenden. Zudem sollen
sowohl lesende, wie auch schreibende Zugriffe auf Dokumente systematisch und lückenlos protokolliert werden, weil
solche Logbücher sind im Falle von juristischen Auseinandersetzungen besonders hilfreich sind. Jeder Behandelnde,
der seine Arbeit seriös macht, hat durch diese Transparenz nichts zu befürchten. Zudem wird die Zurverfügungstellung
eines solchen Protokolls in einem Rechtsfall als kooperativ beurteilt. Die Verschweigung von Zugriffen wird dagegen
als Behinderung von Ermittlungen beurteilt. Die Transparenz kann also selbst dann zum Schutz eines Behandelnden
dienen, wenn er in einem konkreten Fall einen Fehler gemacht hat. Wenn das Protokoll aufzeigt, dass es sich um eine
unbeabsichtigte Ausnahme handelte, wird sich das mildernd auf ein allfälliges Strafmass auswirken.
Um den Datenschutzmassnahmen gerecht zu werden, sollen in elektronischen Dokumenten nur Daten übertragen
werden, für die eine Einwilligung des Patienten vorliegt und die für Anwendungsfall auch tatsächlich notwendig sind.
Die Einwilligung des Patienten kann dabei implizit (z.B. Beantworten einer Konsiliaranfrage, bei der davon ausgegan-
gen werden darf, dass die Einwilligung des Patienten durch den anfragenden Behandelnden eingeholt wurde) oder
explizit (Unterzeichnung einer Einverständniserklärung durch den Patienten) erfolgen. Hinweis: Einwilligungen, welche
in Form von Aushängen im Wartezimmer oder am Empfang eingeholt werden, sind rechtlich kaum anwendbar.
Zusammenfassend soll also nur der kleinste gemeinsame Nenner an Information in einem Dokument angegeben wer-
den, damit Sender und Empfänger ohne gesonderte Absprache den vor- resp. nachgelagerten Prozess korrekt abarbei-
ten können. Die Angabe von redundanten oder zusätzlichen Informationen ist sowohl hinsichtlich Erfüllung der Anfor-
derungen zum Datenschutz, wie auch hinsichtlich der Performance zu vermeiden.
Die, mit dem zu vorliegenden Konzept ausgetauschten Daten gehören also gemäss Schweizerischem Datenschutzge-
setz in die Kategorie „besonders schützenswerte Daten“. Damit wird insbesondere die Weitergabe dieser Daten er-
schwert. Die Verantwortung für diese Daten im produktiven Einsatz liegt bei den Anwendern.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 32 von 54 | 25.08.2012 | Version 1.1
6 Technisches Konzept
6.1 Konformität zur eHealth Architektur Schweiz
Eine APS kann ein Primärsystem innerhalb einer Gemeinschaft der zukünftigen eHealth Architektur Schweiz sein. Die
Kunden / Anwender von APS können jederzeit frei entscheiden ob und wann sie Teil einer Gemeinschaft werden wol-
len. APS sollen deshalb als Produkt die Schnittstellen zu den Dokumentenablagen in einer Gemeinschaft unterstützen
und über den Zugangspunkt einer Gemeinschaft auch gemeinschaftsübergreifende Abfrage machen können.
Obschon die Empfehlungen von Standards und Architektur keine Vorgaben zum Innenleben einer Gemeinschaft ma-
chen, macht es durchaus Sinn, dass APS mit den dafür vorgesehenen IHE Akteuren kommunizieren können. Dies ver-
einfacht den gemeinschaftsübergreifenden Datenaustauch wesentlich. APS sollen also (wo nicht bereits erfolgt) in
folgenden Bereichen erweitert werden:
1. Patientenidentifikation
Eine APS muss in der Lage sein, Patienten-Identifikatoren der Gemeinschaft zu verwalten. In Elexis ist dies heute
über das Konzept der sogenannten XID möglich. Zusätzlich muss der Benutzer auch die Möglichkeit haben, in sei-
ner APS einen Patienten anhand der Patientenidentifikation der Gemeinschaft zu finden. Die bestehenden Such-
fenster für die Patientenauswahl müssen alle mit dieser neuen Funktion ergänzt werden. Es handelt sich hierbei
um eine Erweiterung der bestehenden Funktionalität. Die Umsetzung kann anhand der IHE Integrationsprofile
PIXV3 und PDQV3 realisiert werden. Details dazu folgen weiter unten.
2. Dokumentenaustausch
Eine APS muss in der Lage sein, Dokumente in die Dokumentenablage der Gemeinschaft einzustellen und Doku-
mente abzufragen, die von anderen Systemen in die Dokumentenablage der Gemeinschaft eingestellt worden
sind. Diese Abfrage von Dokumenten soll zusätzlich die Option bieten, die Suchabfrage auf die eigene Gemein-
schaft zu beschränken oder eine gemeinschaftsübergreifende Suchabfrage zu starten. Die Suchabfragen müssen
dabei asynchron durchgeführt werden. Erhaltene Suchresultate sollen also „on the fly“ im Suchresultat dem An-
wender angezeigt werden. Es handelt sich dabei für die meisten APS um die Erweiterung mit neuer Funktionalität.
Die Umsetzung kann anhand des IHE Integrationsprofils XDS erfolgen.
Das IHE Integrationsprofil „Cross-Enterprise Document Sharing (XDS)“ wurde als Basisprofil bei vielen Empfehlungen
von Standards und Architektur verwendet. Es definiert konkrete Akteure und Transaktionen für die gemeinsame Ver-
wendung von Dokumenten in einer Gemeinschaft.
Abbildung 23: IHE XDS Akteure (Quelle: offis.de)
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 33 von 54 | 25.08.2012 | Version 1.1
Der Einsatz von IHE XDS ist abhängig vom Einsatz weiterer IHE Integrationsprofile:
Audit Trail and Node Authentication (ATNA)
Beschreibt die sichere Authentifizierung und die rückverfolgbare Protokollierung von Ereignissen
Siehe auch [IHE ITI TF-1]
Consistent Time (CT)
Beschreibt die Anwendung gemeinsamer Zeitgeber in einer Gemeinschaft
Siehe auch [IHE ITI TF-1]
Wie aus folgender Grafik ersichtlich ist, gibt es 2 Versionen von XDS Transaktionen (A und B). Seit dem IHE Connecta-
thon 2011 werden nur noch XDS.b Transaktionen getestet. APS sollen deshalb die XDS.b Transaktionen implementie-
ren (siehe dazu nachfolgende Auflistung).
Abbildung 24: IHE XDS Transaktionen (Quelle: offis.de)
APS müssen als Konsequenz aus obenstehenden Ausführungen mit den Funktionen folgender IHE Akteure erweitert
werden:
IHE XDS Document Source
Damit wird eine APS zur Dokumentenquelle innerhalb einer Gemeinschaft
Zu implementierende Transaktionen:
o Provide and Register Document Set-b [ITI-41] (siehe [IHE ITI TF-2b], Kapitel 3.41)
IHE XDS Document Consumer
Damit kann eine APS Dokumente innerhalb der Gemeinschaft oder gemeinschaftsübergreifend abfragen/anzeigen
Zu implementierende Transaktionen:
o Registry Stored Query [ITI-18] (siehe [IHE ITI TF-2a], Kapitel 3.18)
o Retrieve Document Set [ITI-43] (siehe [IHE ITI TF-2b], Kapitel 3.43)
IHE PIX Patient Identifier Cross-reference Consumer
Damit kann eine APS die Patientenidentifikation der Gemeinschaft erfragen
Zu implementierende Transaktionen:
o PIXV3 Query [ITI-45] (siehe [IHE ITI TF-2b], Kapitel 3.45)
Hinweis:
Allenfalls kann es Sinn machen zusätzlich Transaktionen aus dem IHE Patient Demographics Query
(PDQV3) zu implementieren.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 34 von 54 | 25.08.2012 | Version 1.1
IHE ATNA Secure Application
Damit wird eine APS zu einer vertrauenswürdigen Applikation, die in Gemeinschaften eingesetzt werden kann,
welche am System eHealth teilnehmen.
Zu implementierende Transaktionen:
o Authenticate Node [ITI-19] (siehe [IHE ITI TF-2a], Kapitel 3.19)
o Record Audit Event [ITI-20] (siehe [IHE ITI TF-2a], Kapitel 3.20)
IHE CT Time Client
Damit wird sichergestellt, dass in der APS die identische Zeit verwendet wird wie bei anderen Systemen der Ge-
meinschaft. Grundsätzlich erfolgt der Abgleich der Systemuhr auf der Ebene des Betriebssystems. Da APS auf un-
terschiedlich gut gewarteten Infrastrukturen betrieben wird, sollen APS deshalb diese Transaktion so implemen-
tieren, dass der Zeitserver abgefragt wird und die erhaltene Zeit mit der lokalen Systemuhr verglichen wird.
Weicht die lokale Systemuhr mehr als 2 Sekunden vom Zeitserver ab, kann in der APS nichts mehr gespeichert
werden bis die Abweichung wieder innerhalb dieser Toleranz ist.
Zu implementierende Transaktionen:
o Maintain Time [ITI-1] (siehe [IHE ITI TF-2a], Kapitel 3.1)
6.2 Allgemeines zur CDA Unterstützung in einer APS
Eine APS muss in der Lage sein, verschiedene HL7 CDA Dokumenteninhalte zu verarbeiten (erstellen und anzeigen
resp. importieren und exportieren). Mit den in diesem Konzept genannten Elementen wird eine APS auf der Ebene der
Architektur (Datenablage und logische Funktionalität) soweit vorbereitet, dass sämtliche Arten von HL7 CDA Doku-
menten unterstützt werden. Allerdings ist, wie einleitend erwähnt, der Inhalt eines CDA Dokuments sehr stark vom
medizinischen Kontext abhängig. Jedes Dokument wird sich demzufolge auch inhaltlich unterscheiden. So können z.B.
im einen Dokument eine Liste von Laborwerten und die Medikamentenliste wichtig sein und in einem anderen Doku-
ment werden beispielsweise ein kranio-zervikales Beschleunigungstrauma oder eine Anamnese und ein Status bei
Eintritt beschrieben. Im ersten Dokument können zahlreiche Informationen in maschinenauswertbarer Form geliefert
werden (Laborresultat, Referenzbereich Laborresultat, Artikelnummer des Medikaments, Einnahmeplan der Medika-
mente, etc.). Im zweiten Fall werden viele Textbeschreibungen geliefert, welche sich nicht in maschinenauswertbarer
Form darstellen lassen.
Zur Illustration hier einige Ausschnitte aus den Fallbeispielen zu [CDA-CH] und [CDA-CH-II]:
Abbildung 25: Strukturierte Medikamentenliste
Abbildung 26: Strukturierte Laborwerte
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 35 von 54 | 25.08.2012 | Version 1.1
Abbildung 27: Freitext zu Unfallhergang
Abbildung 28: Freitext zu Anamnese
Abbildung 29: Freitext zu Status bei Eintritt
Eine APS muss also in der Lage sein, beliebige Inhalte in ein HL7 CDA Dokument zusammenzustellen oder aus einem
HL7 Dokument zu verarbeiten. Aufgrund der oben beschrieben wesentlichen Unterschiede zwischen einzelnen Infor-
mationseinheiten wird eine generische Umsetzung kaum möglich sein. Pro Dokument muss also wohl eine eigene
Implementation erfolgen. Selbstverständlich können dabei einzelne Elemente in verschiedenen Dokumenten wieder-
verwendet werden. Dies wurde bereits mit CDA-CH-II gemacht:
Abbildung 30: Wiederverwendbare CDA Templates
Gemäss Auftraggeberin sollen in diesem Konzept vor allem die Anwendungsfälle in Kapitel „7 Anwendungsfälle“ ab
Seite 44 behandelt werden. Nachfolgende Auflistungen zeigen die Kapitel pro Dokument, wie sie in den referenzierten
Implementierungsleitfäden vorgegeben werden.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 36 von 54 | 25.08.2012 | Version 1.1
6.2.1 Medikament-Interaktionscheck
Basis: IHE Pharmacy Prescription (PRE) und IHE Pharmacy Pharmaceutical Advice (PADV). Ein helvetisierter Implemen-
tierungsleitfaden muss zusätzlich noch erstellt werden.
Abbildung 31: Struktur IHE PRE Dokument
Inhalt IHE PRE Dokument Template
Participants Information R 1.3.6.1.4.1.19376.1.5.3.1.1.1
Required if known Patient Information
R2 1.3.6.1.4.1.19376.1.5.3.1.1.1
Optional Participant Information
O 1.3.6.1.4.1.19376.1.5.3.1.1.1
Authorization R2 1.3.6.1.4.1.19376.1.5.3.1.2.5
Patient Contacts O4 1.3.6.1.4.1.19376.1.5.3.1.2.4
Payers R2 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7
Coded Vital Signs O5 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Allergies and Drug Sensitivities
O 1.3.6.1.4.1.19376.1.5.3.1.3.13
Active Problems O 1.3.6.1.4.1.19376.1.5.3.1.3.6
Resolved Problems O 1.3.6.1.4.1.19376.1.5.3.1.3.8
Immunizations O 1.3.6.1.4.1.19376.1.5.3.1.3.23
Pregnancy History O6 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4
Prescription R 1.3.6.1.4.1.19376.1.9.1.2.1
Tabelle 1: Struktur IHE PRE Dokument
Abbildung 32: Struktur eines IHE PADV Dokuments
Inhalt IHE PADV Dokument Template
Participants Information R 1.3.6.1.4.1.19376.1.5.3.1.1.1
Required if known Patient Information
R2 1.3.6.1.4.1.19376.1.5.3.1.1.1
Optional Participant Information
O 1.3.6.1.4.1.19376.1.5.3.1.1.1
Authorization R2 1.3.6.1.4.1.19376.1.5.3.1.2.5
Pharmaceutical Advice R 1.3.6.1.4.1.19376.1.9.1.2.2
Tabelle 2: Struktur IHE PADV Dokument
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 37 von 54 | 25.08.2012 | Version 1.1
6.2.2 Elektronischer Impfausweis
Basis: IHE Immunization Content (IC). Ein helvetisierter Implementierungsleitfaden muss noch erstellt werden
Inhalt IHE IC Dokument Optionalität Template
Immunizations R 1.3.6.1.4.1.19376.1.5.3.1.3.23
Authors and Informants R NONE
Active Problems R2 1.3.6.1.4.1.19376.1.5.3.1.3.6
History of Past Illness R2 1.3.6.1.4.1.19376.1.5.3.1.3.8
Allergies and Other Adverse Reactions R2 1.3.6.1.4.1.19376.1.5.3.1.3.13
Medications R2 1.3.6.1.4.1.19376.1.5.3.1.3.19
Coded Results R2 1.3.6.1.4.1.19376.1.5.3.1.3.28
Coded Vital Signs R2 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Pregnancy History R2 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4
Coded Advance Directives R2 1.3.6.1.4.1.19376.1.5.3.1.3.35
Comments R2 1.3.6.1.4.1.19376.1.5.3.1.4.2
Simple Observation R2 1.3.6.1.4.1.19376.1.5.3.1.4.13
Tabelle 3: Struktur IHE IC Dokument
6.2.3 Upload FIRE-Daten
Dazu kann noch nicht auf einen Implementierungsleitfaden zurückgegriffen werden (muss zuerst erstellt werden).
6.3 Auswirkungen auf Applikationslogik einer APS
Eine mehrschichtige Softwarearchitektur lässt es nicht zu, dass Benutzerinterfaces direkt auf die Datenbank zugreifen.
Das ist heute bereits in vielen Produkten bereits so implementiert und muss bei der Umsetzung der CDA Integration
entsprechend weitergeführt werden. Die Erstellung von CDA Dokumenten soll nicht direkt im Kern der APS implemen-
tiert werden. Hingegen soll ein „eHealth Connector“ (bei Elexis in Form eines oder mehreren Plug-Ins) erstellt werden,
welcher die Transformation zwischen dem Daten- und Objektmodell der APS und dem Daten- und Objektmodell der
Dokumente macht, welche betriebsübergreifend verschickt werden sollen.
Abbildung 33: eHealth Connector Modell für eine APS
Dieses Modell zeigt auf abstrakter Ebene auf, wie die Integration erfolgen soll. Für Elexis sollen sowohl der „eHealth
Connector“, wie auch seine einzelnen Module als Plug-Ins implementiert werden. Dafür muss in einer nächsten Pro-
jektphase ein Design entworfen werden, bevor mit der eigentlichen Implementierung begonnen wird.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 38 von 54 | 25.08.2012 | Version 1.1
6.4 Auswirkungen auf Datenhaltung einer APS
APS sind aus historischen Gründen oft so konstruiert, dass die Datenhaltung exakt zu den Fenstern passt, welche die
Daten anzeigen.
6.4.1 Erstellen von CDA Dokumenten (Versand)
Jede Informationseinheit, die vom Empfänger eines CDA Dokuments maschinell weiterverarbeitet werden soll, muss
in der Datenhaltung der APS vorhanden sein. Mit der heutigen Datenhaltung könnten die meisten APS Dokumente mit
CDA Body Level 1 und CDA Body Level 2 erstellen (analog zur Berichterstellung / Textintegration).
Die genaue Auswirkung auf die Datenhaltung ist bei jeder APS anders, da sich diese zum Teil erheblich voneinander
unterscheiden. Nachfolgendes Unterkapitel zeugt die Konsequenzen für Elexis auf.
6.4.1.1 Konsequenzen für Elexis
Derzeit ist die Datenhaltung in Elexis nicht ausreichend strukturiert. Die notwendigen CDA Body Level 3 Elemente
können mit der heutigen Datenhaltung von Elexis noch nicht produziert werden. Selbst bei den Laborwerten und den
Medikamenten, welche gute Beispiele für HL7 Body Level 3 darstellen, muss die Elexis Datenhaltung erweitert resp.
optimiert werden. Folgende Auflistungen sind Beispiele, die während der Erarbeitung des vorliegenden Konzepts auf-
gefallen sind. Diese Liste ist nicht abschliessend und bezieht sich auf den Stand der Dinge in der, am 12.07.2012 pro-
duktiven Elexis Version 2.1.6.4.
Mängel in der Datenhaltung bei Medikamenten
Dosierung nur als Freitext.
Für das CDA-CH Medikationstemplate ist eine strukturierte Form notwendig.
Applikationsart des Medikaments nicht vorhanden (z.B. spritzen, schlucken, …).
Für das CDA-CH Medikationstemplate ist eine strukturierte Form notwendig.
Verknüpfung zum Artikel nur über zusammengesetzte Schlüssel möglich, die nur von der Applikationslogik ver-
standen werden (keine referenzielle Integrität). Beispiel aus dem Inhalt der Spalte patient_artikel_joint.Artikel:
'ch.elexis.artikel_ch.data.Medikament::Wf53f3964e5d9da782b529'
Keine Historisierung der Änderungen an Rezepten oder Rezeptzeilen
Einzelne Daten werden in BLOB’s gespeichert (Spalte ExtInfo), die nur von der Applikationslogik verstanden wer-
den können. Es besteht die Gefahr von Inkonsistenzen bei Softwareupdates und auch bei der Anwendung durch
mehrere, voneinander unabhängigen Plug-Ins.
Rezeptempfänger nicht vorhanden
Mängel in der Datenhaltung bei Laborwerten
Referenzbereiche sind auf dem Labortest und nicht auf dem Laborresultat hinterlegt
(aus Labormedizinischer Sicht ein klarer Systemfehler!)
Die unterschiedlichen Zeitpunkte, welche aus labormedizinischer Sicht relevant sind, sind nicht vorhanden. Es gibt
lediglich 1 Datum und optional eine Zeit. Notwendig wären Verordnungszeitpunkt, Entnahmezeitpunkt der Probe,
Untersuchungszeitpunkt der Probe im Labor, Übermittlungszeitpunkt des Laborresultates und Zeitpunkt der
Kenntnisnahme durch den Arzt.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 39 von 54 | 25.08.2012 | Version 1.1
Notwendige Erweiterungen für die Verwaltung von CDA Dokumenten
Zwecks Rückverfolgbarkeit sollen alle erstellten CDA Dokumente in der Datenhaltung von Elexis gespeichert wer-
den. Somit kann gewährleistet werden, dass zu späteren Zeitpunkten das Original konsultiert werden kann.
Eine entsprechende Bereinigung muss implementiert werden (gesetzliche Aufbewahrungspflicht einhalten.)
Für jede spezialisierte Dokumentenform müssen gegebenenfalls weitere Datentabellen erstellt werden. Dabei
muss die referenzielle Integrität auf der Datenbank gewährleistet werden. Nur so können verfügbare Daten in
verschiedenen Dokumenten wiederverwendet werden und nur so entsteht eine verlässliche und nutzbare Quelle
für Auswertungen (Statistiken, Rückverfolgungen, Forschung, etc.). Die dritte Normalform des Datenbankdesigns
soll angestrebt werden, wo die Performance dies zulässt.
6.4.2 Verarbeiten von CDA Dokumenten (Empfang)
Jedes empfangene CDA Dokument soll im Original abgespeichert werden. Das hat den Vorteil, dass die Originalansicht
des Absenders jederzeit eingesehen werden kann.
Diejenigen Daten, die in einer APS strukturiert vorliegen sollen je nach Anwenderwunsch automatisch oder optional
(also konfigurierbar) aus den erhaltenen CDA Dokumenten extrahiert und entsprechend abgespeichert werden.
Zudem wird es so sein, dass keine APS jemals sämtliche, strukturiert vorhandenen Daten in einem CDA Dokument
auch tatsächlich verarbeitet und in den dafür vorgesehenen Datentabellen ablegt. Es wird oft so sein, dass CDA Do-
kumente Informationen enthalten, für die es kein passendes Datenablagegefäss in der APS gibt. Hingegen kann es
sein, dass zu einem späteren Zeitpunkt nach Empfang von bestimmten Typen von CDA Dokumenten eine Erweiterung
der APS zur Verfügung steht, die neue, bisher nicht unterstützte, strukturierte Daten aus den CDA Dokumenten auf-
nehmen kann. Dank der XML Strukturierung der CDA Dokumente und obiger Empfehlung, jedes empfangene CDA
Dokument im Original abzuspeichern, können diese auch zu einem späteren Zeitpunkt nochmals verarbeitet werden
und weitere strukturierte Daten in entsprechende Datentabellen extrahiert werden.
6.4.2.1 Analyse strukturiert vorliegender Daten in Elexis
Folgende Liste an strukturierten Daten in Elexis ist bekannt aber nicht abschliessend:
1. Patient
Das Dokument soll in die patientenzentrierte Dokumentenablage gespeichert und von dort aufgerufen werden
können (Omnivore)
2. Adressaten (Absender, Kopie-Empfänger)
Wenn eine Person/Institution, die im CDA als Participant angegeben ist, in Elexis nicht existiert (je nach Anwen-
derwunsch automatisch oder optional).
3. Diagnosen
4. Medikamente
5. Laborwerte
6. Vitalzeichen
7. Arbeitsfähigkeit
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 40 von 54 | 25.08.2012 | Version 1.1
6.5 Auswirkungen auf Benutzerinterface einer APS
6.5.1 Erstellen von CDA Dokumenten (Versand)
Die Benutzerinterfaces der meisten APS lassen heute keine Erstellung von HL7 CDA Dokumente im Body Level 3 zu.
Die nachfolgend beschriebenen Elemente müssen noch implementiert werden. Die Erstellung eines CDA Dokuments
soll im Benutzerinterface interaktiv mit dem Anwender erfolgen. Dabei sollen so viele Informationen aus den beste-
henden Datenbeständen vorgeladen werden können, wie möglich. Der Anwender muss die Möglichkeit haben, eine
bestehende Information zu überschreiben. Die Integration in einer APS kann am Beispiel folgender Mockups aufge-
zeigt werden. Da für die genannten Anwendungsfälle (Interaktionscheck, eImpfdossier und FIRE Upload) noch keine
CDA Beispieldokumente existieren, zeigen wir das Verhalten am Beispiel eines Suva Arztzeugnisses auf (Beispieldoku-
ment aus dem Fallbeispiel “Auffahrunfall aus [CDA-CH-II]).
Der Benutzer soll durch einen Wizard geführt werden, der es ihm erlaubt die notwendigen Daten zusammenzustellen:
Abbildung 34: Arztzeugnis: Auswahl Beteiligte
Abbildung 35: Arztzeugnis: Eingabe Schadeninformationen
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 41 von 54 | 25.08.2012 | Version 1.1
Abbildung 36: Angaben des Patienten für Arztzeugnis
Die Schritte für Allgemeinzustand bis Bemerkungen erfolgt analog zu obenstehenden Mockups. Auf eine komplette
Darstellung an dieser Stelle wird verzichtet.
Unter Vorschau kann das HL7 CDA Dokument noch angezeigt werden:
Abbildung 37: Vorschau Arztzeugnis
Mit dem Knopf Fertigstellen soll es auch möglich sein, das CDA Dokument digital zu signieren. Dazu soll unter anderem
die Health Professional Card oder die SuisseID verwendet werden können, sofern der Behandelnde über eine solche
verfügt. Optional können APS eine PDF Repräsentation des menschlich lesbaren Teils in das HL7 CDA Dokument ein-
betten (PDF base64-codiert im XML). Mit dem Format PDF/A können die Vorgaben für Langzeitarchivierung des Bun-
desarchivs erfüllt werden.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 42 von 54 | 25.08.2012 | Version 1.1
6.5.1.1 Einbau in Elexis
In Elexis soll die Integration dort erfolgen wo der Anwender heute bei Erstellung eines Briefes die Vorlage auswählt.
Für CDA Dokumente wird anstelle der automatischen Berichtgenerierung in Office der obenstehend gezeigte Wizard
gestartet.
Abbildung 38: Integration CDA Erstellung in Elexis
6.5.2 Verarbeiten von CDA Dokumenten (Empfang)
Elektronische Dokumente – darunter auch CDA Dokumente können auf verschiedene Wege in eine Arztpraxis gelan-
gen (z.B. Mail, USB-Stick, CD-ROM, Download, Abfrage über Webservices). Eine APS soll deshalb einerseits einen Im-
port (in Elexis normalerweise über Dreiecksmenü – vgl. z.B. Laborimport) und andererseits über die IHE Transaktionen
[ITI-18] und [ITI-43] unterstützen.
Import
Das Dokument wird angezeigt und der Anwender kann entscheiden, ob es verarbeitet und gespeichert werden soll.
IHE Transaktionen
Es wird zunächst eine Abfrage an das ferne Dokumentenregister gestellt. Dazu können verschiedene Metadaten als
Suchattribute verwendet werden. In der Folge erhält der Anwender eine Liste verfügbarer Dokumente, auf welche er
Zugriff hat. Mit einem Doppelklick wird das Dokument tatsächlich aus der fernen Dokumentenablage abgeholt und
angezeigt. Wie beim Import kann der Anwender dann entscheiden, ob es verarbeitet und patientenzentriert abgelegt
werden soll. Siehe dazu folgender Screenshot aus der Bachelorarbeit der Hochschule für Technik Buchs (NTB) von
Arben Thaqi, welche eine gemeinschaftsübergreifende Dokumentenabfrage nach dem IHE Cross Community Access
(XCA) Integrationsprofil durchführt.
Abbildung 39: Screenshot Bachelorarbeit Arben Thaqi
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 43 von 54 | 25.08.2012 | Version 1.1
6.6 Validieren von CDA Dokumenten
Der Herausgeber eines Formulars, also auch die verantwortliche Stelle für ein CDA-Template soll gemäss [CDA-CH-II]
nicht nur einen Implementierungsleitfaden in Textform, sondern auch Schematronregeln zur automatisierten Validie-
rung von CDA Dokumenten herausgeben. Siehe dazu auch die Einführung in Kapitel „3.5.6 Validierung von CDA Doku-
menten“ ab Seite 17. Damit kann erreicht werden, dass für alle Beteiligten die gleichen Validierungsregeln gelten und
bei Sender und Empfänger angewendet werden können.
Nun kann es durchaus sein, dass in gewissen Fällen nicht sämtliche Informationen vorhanden sind, die für ein valides
CDA Dokument notwendig sind. Dennoch könnte der Teilbestand der Information für den Empfänger hilfreicher sein
und damit zu einer höheren Patientensicherheit und Behandlungsqualität führen, als wenn das Dokument wegen
fehlgeschlagener Validierung nicht verfügbar wird.
Validierung der semantischen Interoperabilität
Beim Empfangen von CDA Dokumenten:
Eine APS soll aufgrund obiger Ausführung auch in der Lage sein, Dokumente zu verarbeiten, die nicht gegenüber
den Schematronregeln validieren (betrifft ausschliesslich Schritt 3 gemäss Abbildung 12 auf Seite 17).
Wichtig:
Solche Dokumente sind optisch besonders aussagekräftig als invalide Dokumente zu kennzeichnen und die,
bei der Validierung entstandenen Meldungen müssen angezeigt werden können.
Beim Versenden von CDA Dokumenten:
Es kann nicht davon ausgegangen werden, dass jede Software so fehlertolerant ist, wie oben beschrieben. Damit
beim fernen Empfänger von CDA Dokumenten nicht unnötige Fehlermeldungen auftreten, muss in einer APS pro
Empfänger und Dokumentenart konfigurierbar sein, ob Dokumente nur versendet werden dürfen, die gegenüber
den Schematronregeln validieren. Dabei muss auch der Schweregrad-Level der Validierungsresultate konfiguriert
werden können (Error, Warning, Information).
Validierung der technischen Interoperabilität
In jedem Fall muss ein CDA-Dokument ein wohlgeformtes XML Dokument sein und dem XML Schema von HL7 CDA R2
entsprechen. Andernfalls kann das Dokument technisch nicht verarbeitet werden und muss als fehlerhaft zurückge-
wiesen werden. Hier gibt es keine Aufweichung der Validierung wie oben bei der semantischen Interoperabilität er-
wähnt.
6.7 Bestehende IHE/CDA Plug-Ins für Elexis
Es existieren folgende, derzeit nicht offiziell freigegebene Plug-Ins, welche ansatzweise IHE resp. HL7 CDA Funktionen
umgesetzt haben:
Anbindung der docbox (http://www.docbox.ch/) an Elexis
Weitere Informationen sind bei Oliver Egger, visionary AG, Quellenstrasse 25, 8005 Zürich erhältlich
Prototyp für die Identifikation von Behandelnden bei gemeinschaftsübergreifenden Zugriffen
Bachelorarbeit „Musteranwendung eHealth für die Behandelnden-Identifikation“
Hochschule für Technik Buchs (NTB)
Siehe auch Abbildung 39 auf Seite 42.
Weitere Informationen sind bei Arben Thaqi, Rorschacherstrasse 235, 9016 St. Gallen erhältlich
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 44 von 54 | 25.08.2012 | Version 1.1
7 Anwendungsfälle
Die hier beschriebenen Anwendungsfälle zeigen auf, wie die technische und semantische Interoperabilität umgesetzt
werden soll. Sie geben aber keine Auskunft über die Ausgestaltung von Business Modellen. Dass Dienstleistungen
einen Preis haben, liegt auf der Hand. Das vorliegende Konzept will keinesfalls suggerieren, dass die hier beschriebe-
nen Anwendungsfälle kostenlos angewendet werden können. Das Preismodell ist Sache der Anbieter und wird hier
nicht behandelt.
Bei allen nachfolgenden Dokumentschnittstellen gilt (Ausnahme URL Aufruf Visualisierung EPha.ch):
Der Datentransfer soll mittels Transport Layer Security (TLS) verschlüsselt sein. Idealerweise, aber nicht zwingend
sollen die Dokumente digital so signiert werden, dass sie authentisch und unverfälschbar sind. Dazu wird ein X.509
Zertifikat benötigt (z.B. von HPC oder SuisseID).
7.1 Interaktionscheck und Rezeptservice
Wie einleitend beschrieben, bietet EPha.ch einen Rezept Service und einen Medikamenten-Interaktionscheck mit
schön gemachter 3D-Visualisierung im Webbrowser an. Der Medikamenten-Interaktionscheck ist ein hervorragendes
Decision Support System und der Rezept Service eine optimale Dienstleistung für den Arzt. Beide Dienste sollen des-
halb so in eine APS integriert werden, dass ein Prozessablauf mit technischer und semantischer Interoperabilität ge-
währleistet ist und zudem aus Sicht EPha.ch für Schnittstellen zu anderen Softwaresystemen verwendet werden kann.
Abbildung 40: Interaktionen APS - EPha.ch
Mit dem Einsatz der genannten IHE Profile kann EPha.ch auch anderen Stakeholdern wie z.B. Versandapotheken oder
andere Abgabestellen im In- und Ausland elektronische Rezepte und pharmazeutische Beurteilungen in digitaler Form
anbieten. Dabei können die hier beschriebenen Inhalte und Transaktionen eingesetzt werden. Voraussetzung ist aller-
dings, dass diese anderen Stakeholder in der Lage sind, damit umzugehen. Gerade im Verschreibungs- und Distributi-
onsprozess von Medikamenten sind die Vorteile durch den Einsatz von international interoperablen Schnittstellen
ganz erheblich. Der Medikationsprozess lässt sich durch die grosse Mobilität unserer Gesellschaft kaum mehr inner-
halb der Landesgrenzen abwickeln. Touristen, Geschäftsreisende oder Rentner die im Süden den Winter verbringen
könnten wesentlich von solchen, grenzüberschreitenden Prozessen profitieren.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 45 von 54 | 25.08.2012 | Version 1.1
7.1.1 Datentransfer zwischen Sender und Empfänger
Der Datentransfer erfolgt gemäss obiger Abbildung 40 auf zwei unterschiedlichen Ebenen:
1. Klassischer Dokumentenaustausch
Dabei wird ein Rezept mittels [ITI-41] (Content Profile: IHE PRE) von der APS an EPha.ch übermittelt. Je nachdem,
welche EPha.ch Dienste durch einen Arzt in Anspruch genommen werden, wird der eine oder andere resp. beide
nachfolgende Prozesse ablaufen.
a. Die Resultate des Interaktionschecks werden als Dokumentation in Form einer pharmazeutischen Bera-
tung mittels [ITI-43] (Content Profile: IHE PADV) zurück an die APS übermittelt. Der weitere Ablauf in
der APS wird durch den Arzt bestimmt.
b. Im Portal von EPha.ch wird das Rezept weiter bearbeitet. Bei Abschluss des Rezepts kann dieses z.B. an
eine Versandapotheke weitergeleitet werden (idealerweise ebenfalls als IHE PRE). Dabei kann je nach
Ausgestaltung von EPha.ch [ITI-41] oder [ITI-43] angewendet werden.
In jedem Fall soll mit [ITI-43] (Content Profile: IHE PRE) das aktualisierte Rezept zurück in die APS über-
nommen werden. Andernfalls ist beim Arzt eine, von der Realität abweichende Medikamentenverschrei-
bung dokumentiert, was für spätere Verschreibungen verheerende Folgen haben kann.
2. Fremdstart der Visualisierung im Webbrowser
a. Mit der Medikamentenliste aus der APS kann die Visualisierung der Interaktionen im Webbrowser darge-
stellt werden. Als Parameter können die GTIN (Strichcode) der Medikamente übergeben werden. Diese
Information ist in den meisten APS (darunter auch Elexis) heute bereits vorhanden. Dieser Prozess ist
deshalb völlig unabhängig von obenstehend beschriebenem Dokumentenaustausch zwischen APS und
EPha.ch. Die Medikamentenliste kann also vom Arzt selbständig in der APS erfasst werden. Selbstver-
ständlich macht es aber durchaus Sinn, diesen Prozess mit dem Rezept Service von EPha.ch zu kombinie-
ren. Dies ist aber keine Voraussetzung.
Technische Beschreibung: URL mit URL Parametern aufrufen und Webseite im Browser anzeigen.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 46 von 54 | 25.08.2012 | Version 1.1
7.2 Elektronischer Impfausweis
Wie einleitend beschrieben, soll in der Schweiz dereinst ein eImpfdossier verfügbar sein. Da dieses erst im Aufbau
(Definitionsphase) begriffen ist, basieren die nachfolgend genannten Ausführungen auf Annahmen und dem aktuellen
Stand der Dinge.
Auszug aus dem Bericht für die Anhörung zum elektronischen Impfdossier:
Die meisten Impfungen werden in den ersten Lebensjahren verabreicht. Im Erwachsenenalter verliert das Thema zwar
an Bedeutung, das Bewusstsein für die individuelle Impfsituation nimmt ab. Ausnahmen sind beispielsweise die vor-
beugende Tetanus-Impfung bei Verletzungen, Impfungen bei Reisen in Risikogebiete oder Grippeimpfungen bei be-
stimmten Bevölkerungsgruppen. Impfen als lebenslanges Thema muss deshalb auch lebenslang dokumentiert werden.
In der Schweiz ist der Papier-Impfausweis üblich. Die Folge sind verlorene Ausweise oder Lücken im Impfplan. Fehlende
Informationen müssen aus dem Gedächtnis des Bürgers (z.B. erlittene Krankheiten, Allergien) oder in kritischen Fällen
sogar durch Serologien (z.B. Hepatitis B) ergänzt werden. Die Fachwelt ist sich einig, dass der Impfausweis in Zukunft
ein elektronisches Dokument sein wird.
Abbildung 41: Impfprozess (Quelle: eHealth Suisse)
Die Empfehlungen zum elektronischen Impfdossier, zu welchen in einer öffentlichen Anhörungsphase vom 3.9.2012
bis 9.11.2012 Rückmeldungen gesammelt werden, unterscheiden einen e-Impfcheck-Dienst (VAC-CDSS), welcher
basierend auf anonymisierten Patienteninformationen konkrete Impfempfehlungen herausgibt und ein elektroni-
schen Impfdossier, also der eigentliche Ablageort des elektronischen Impfausweises eines Patienten.
Die Empfehlungen von Standards & Architektur erklären sogenannte Stammgemeinschaften als Ablageort für Doku-
mente, die vom Patienten selbst verwaltet werden (z.B. Einverständniserklärungen). Der Autor geht aufgrund seiner
Erfahrung davon aus, dass in den Stammgemeinschaften auch Dokumente verwaltet werden, welche nach Änderun-
gen aus verschiedenen Gemeinschaften aktualisiert werden müssen.
Weil Impfungen an verschiedensten Orten durchgeführt werden, zählt insbesondere auch der eImpfausweis zu den
Dokumenten, welche wohl in der Stammgemeinschaft aktualisiert vorgehalten werden. Nachfolgende Grafik beruht
auf dieser Annahme. Sollte die Annahme falsch sein, wird allenfalls die Beschriftung „Stammgemeinschaft Patient“
geändert und evtl. mehrere Systeme ergänzt werden müssen. Am eHealth Connector der APS und auch am auszutau-
schenden Datenformat ändert damit aber nichts.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 47 von 54 | 25.08.2012 | Version 1.1
Abbildung 42: Interaktionen APS - eImpfdossier
7.2.1 Datentransfer zwischen Sender und Empfänger
Der Datentransfer erfolgt gemäss obiger Abbildung 42 an zwei unterschiedliche, externe Systeme.
1. Impfcheck Service (VAC-CDSS)
Dabei wird ein elektronischer Impfausweis mit anonymisierten Patientendaten voraussichtlich mittels [ITI-41]
(Content Profile: IHE IC) an den Impfcheck Service (VAC-CDSS) übermittelt. Zahlreiche Anfragen können durch
den Algorithmus im VAC-CDSS automatisch beantwortet werden. Andere müssen zuerst von einem Impfexperten
bearbeitet werden. Demzufolge kann nicht bestimmt werden, wann die Impfempfehlung verfügbar sein wird.
Eine APS soll innerhalb für eine konfigurierbare Dauer automatisch in kurzen Intervallen (z.B. alle 10 Sekunden)
versuchen die Impfempfehlung mittels [ITI-43] (Content Profile: IHE IC) abzufragen. Sollte die Impfempfehlung
innerhalb dieser Zeitspanne nicht verfügbar sein, muss der Arzt vom Impfcheck Service (VAC-CDSS) über einen
anderen Kanal benachrichtigt werden, sobald die Impfempfehlung verfügbar ist. Eine APS soll dazu die Möglich-
keit bieten, die Transaktion Impfempfehlung mittels [ITI-43] (Content Profile: IHE IC) abholen, manuell zu star-
ten.
Optional könnte IHE Notification of Document Availability (NAV) eingesetzt werden. Es ist aber heute noch nicht
klar, wie die Spezifikationen rund um das eImpfdossier genau aussehen werden. Deshalb gehen wir an dieser Stel-
le nicht weiter ins Detail.
2. Elektronisches Impfdossier (eImpfausweis)
Die aktuellen Empfehlungen von Standards und Architektur nennen derzeit einen gemeinschaftsübergreifenden
Datenaustausch, welcher nur lesend ausgestaltet werden soll. Es ist dem Autor zum Zeitpunkt der Erstellung die-
ses Konzepts noch nicht bekannt, wie Dokumente gemeinschaftsübergreifend aktualisiert werden sollen. Grund-
sätzlich werden auch hier die IHE Transaktionen [ITI-41]12
und [ITI-43] (Content Profile bei beiden: IHE IC) einge-
setzt. Das IHE Integrationsprofil „Notification of Document Availability (NAV)“ könnte dazu eingesetzt werden um
die Stammgemeinschaft darüber zu benachrichtigen, dass eine neue Version eines Dokuments in einer anderen
Gemeinschaft vorliegt (also z.B. dann, wenn ein Arzt in einer APS eine neue Impfung dokumentiert hat). Es ist
dann der Stammgemeinschaft überlassen, diese Notifikation zu verwenden um das entsprechende Dokument
gemeinschaftsübergreifend abzufragen und in die eigene Dokumentenablage einzutragen. Weil das aber noch
unklar ist, gehen wir an dieser Stelle nicht weiter ins Detail.
12
nur gemeinschaftsintern
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 48 von 54 | 25.08.2012 | Version 1.1
7.3 Upload FIRE-Daten
Wie einleitend beschrieben worden ist, sollen Daten zu Forschungszwecken von APS an entsprechende Forschungsin-
stitute übermittelt werden können. Eine APS soll deshalb den Datenaustausch von FIRE Daten im CDA Format zum
Institut für Hausarztmedizin Zürich (IHAMZ) anbieten. Derzeit ist eine Umsetzung im SMEEX Format im Gespräch.
SMEEX ist ein öffentlicher Standard, aber es existiert derzeit kein Framework für plattformunabhängigen Einsatz. Das
verfügbare SMEEX Framework basiert auf Microsoft .Net und kann deshalb nicht bei APS Installationen auf Mac oder
Linux eingesetzt werden. Deshalb sollen Mac und Linux APS und auch APS die auf Windows ohne SMEEX Framework
arbeiten die FIRE Daten in Form von HL7 CDA Dokumenten bereitstellen. Aufgrund der Tatsache, dass alle involvierten
Daten-Container (bisheriges FIRE Format, SMEEX und HL7 CDA) auf der XML Technologie beruhen, kann beim Emp-
fänger - im vorliegenden Fall das IHAMZ - eine Umwandlung auf das SMEEX Format erfolgen. Die Verantwortung für
solche Datentransformationen kann aus Qualitäts-, Kosten- und Verantwortlichkeitsgründen nicht an jede einzelne
Arztpraxis delegiert werden.
Abbildung 43: Interaktionen APS - IHAMZ (FIRE)
7.3.1 Datentransfer zwischen Sender und Empfänger
Für den FIRE Upload gibt es keine IHE Profile oder andere Implementierungsleitfäden. Es gibt deshalb derzeit keine
konkreten Integrations- und CDA Inhaltsprofile. Diese müssen für den FIRE Upload zuerst erstellt werden. Unabhängig
davon kann an dieser Stelle festgehalten werden, dass eine APS über den eHealth Connector entweder HL7 CDA Do-
kumente oder SMEEX Container produziert und diese über einen, noch zu definierenden Webservice ans IHAMZ
übermittelt.
7.3.2 Dateninhalt
Derzeit existiert lediglich ein XML Schema (siehe Kapitel „3.7.2.1 XML Schema“ auf Seite 21). Weitergehende Informa-
tionen liegen dem Autor nicht vor. Es ist aber bekannt, dass der heutige FIRE Upload bei der Datenauswertung zur
Forschung grosse semantische Probleme verursacht. Dies unter anderem deshalb, weil jede Arztsoftware andere Co-
dierungen teilweise gleiche Daten verwendet. Das IHAMZ arbeitet deshalb derzeit in Zusammenarbeit mit dem Ver-
band Schweizerischer Fachhäuser für Medizinal-Informatik (VSFM) an einem KTI Projekt für die komplette Überarbei-
tung der FIRE Daten Sammlung.
Aufgrund der Tatsache, dass der bisherige FIRE Upload bereits in den wichtigsten APS (darunter auch Elexis) imple-
mentiert ist, gibt es derzeit keinen Handlungsbedarf. Sobald die neue FIRE Daten Schnittstelle bekannt ist, können
weitere Details spezifiziert werden.
Unter Berücksichtigung der Tatsache, dass bei einem KTI Projekt Fördergelder des Bundes (also Steuergelder) einge-
setzt werden, sollte versucht werden allen Marktteilnehmern gerecht zu werden. Ein Hersteller einer APS soll frei
entscheiden können, ob er HL7 CDA oder SMEEX einsetzen will.
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 49 von 54 | 25.08.2012 | Version 1.1
8 Anhang
8.1 Referenzierte Dokumente
Alle nachfolgenden Internet Links wurden zuletzt am 21.07.2012 besucht. Aufgrund der täglichen Veränderungen im
Internet, kann keine Garantie für die zukünftige Verfügbarkeit gegeben werden.
[CDA-CH] CDA-CH: SPEZIFIKATION ZUM ELEKTRONISCHEN AUSTAUSCH VON MEDIZINISCHEN DOKU-
MENTEN IN DER SCHWEIZ
Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2
Etappe 1, Version 1.2 (genehmigt) vom 27. Januar 2009
http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf
[CDA-CH-II] CDA-CH-II: SPEZIFIKATION ZUM ERSTELLEN VON VORLAGEN FÜR DIE HEALTH LEVEL 7 CLINI-
CAL DOCUMENT ARCHITECTURE
Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2
Etappe 2, Version 1.2 (genehmigt) vom 27. Januar 2011
http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH-II_de_V1.2a.pdf
[eImpfdossier] eHealth Suisse - Zwischenbericht „Elektronisches Impfdossier“ Vom Steuerungsausschuss zur Kenntnis genommen am 19. April 2012 http://goo.gl/jzrnL
[Empfehlungen I] Empfehlungen I "Standards und Architektur"
verabschiedet am 19. März 2009
http://goo.gl/EjZ2G
[Empfehlungen II] Empfehlungen II "Standards und Architektur"
verabschiedet am 21. Oktober 2010
http://goo.gl/2KloM
[Empfehlungen III] Empfehlungen III "Standard und Architektur"
verabschiedet am 27. Oktober 2011
http://goo.gl/hMevI
[HL7 CDA] HL7 Clinical Document Architecture, Release 2.0
ANSI/HL7 CDA, R2-2005 4/21/2005
HL7 Version 3 Standard; Last Published: 03/27/2006 3:35 AM
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
[IHE DSG] IHE IT Infrastructure (ITI) Technical Framework Supplement
Document Digital Signature (DSG)
Trial Implementation Supplement vom 10. August 2009
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Digital_Signature-2009-08-10.pdf
[IHE ITI TF-1] IHE IT Infrastructure (ITI) Technical Framework
Volume 1 (ITI TF-1): Integration Profiles
Revision 8.0 vom 19. August 2011
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol1_FT_2011-08-19.pdf
[IHE ITI TF-2a] IHE IT Infrastructure (ITI) Technical Framework
Volume 2a (ITI TF-2a): Transactions Part A – Sections 3.1 – 3.28
Revision 8.0 vom 19. August 2011
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2a_FT_2011-08-19.pdf
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 50 von 54 | 25.08.2012 | Version 1.1
[IHE ITI TF-2b] IHE IT Infrastructure (ITI) Technical Framework
Volume 2b (ITI TF-2b): Transactions Part B – Sections 3.29 – 3.51
Revision 8.0 vom 19. August 2011
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2b_FT_2011-08-19.pdf
[IHE ITI TF-2x] IHE IT Infrastructure (ITI) Technical Framework
Volume 2x (ITI TF-2x): Volume 2 Appendices
Revision 8.0 vom 19. August 2011
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2x_FT_2011-08-19.pdf
[IHE ITI TF-3] IHE IT Infrastructure (ITI) Technical Framework
Volume 3 (ITI TF-3)
Cross-Transaction Specifications and Content Specifications
Revision 8.0 vom 19. August 2011
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol3_FT_2011-08-19.pdf
[IHE NAV] IHE IT Infrastructure Technical Framework Supplement
Notification of Document Availability (NAV)
Trial Implementation vom 10. August 2010
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_NAV_Rev2-1_TI_2010-08-10.pdf
[IHE PCC CDA] IHE Patient Care Coordination (PCC) Technical Framework Supplement
CDA Content Modules
Trial Implementation vom 2. September 2011
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Suppl_CDA_Content_Modules_Rev2-1_TI_2011-09-02.pdf
[IHE PCC IC] IHE Patient Care Coordination (PCC) Technical Framework Supplement
Immunization Content (IC)
Trial Implementation vom September 9, 2011
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Suppl_Immunization_Content_Rev2-2_TI_2011-09-09.pdf
[IHE PCC TF-1] IHE Patient Care Coordination (PCC) Technical Framework
Volume 1 (PCC TF-1) Integration Profiles
Revision 7.0 vom 19. September 2011
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev7-0_Vol_1_2011-09-09.pdf
[IHE PCC TF-2] IHE Patient Care Coordination (PCC) Technical Framework
Volume 2 (PCC TF-2) Transactions and Content Profiles
Revision 7.0 - 9. September 2011
http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev7-0_Vol_2_2011-09-09.pdf
[IHE PHAR CMPD] IHE Pharmacy Technical Framework Supplement
Community Medication Prescription and Dispense (CMPD)
Trial Implementation vom 30. Dezember 2010
http://www.ihe.net/Technical_Framework/upload/IHE_Pharmacy_Suppl_CMPD_Rev1-2_TI_2011-12-31.pdf
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 51 von 54 | 25.08.2012 | Version 1.1
[IHE PHAR PADV] IHE Pharmacy Technical Framework Supplement
Pharmacy Pharmaceutical Advice (PADV)
Trial Implementation vom 31. Dezember 2010
http://www.ihe.net/Technical_Framework/upload/IHE_Pharmacy_Suppl_PADV_Rev1-2_TI_2011-12-31.pdf
[IHE PHAR PRE] IHE Pharmacy Technical Framework Supplement
Pharmacy Prescription (PRE)
Trial Implementation vom 31. Dezember 2010
http://www.ihe.net/Technical_Framework/upload/IHE_Pharmacy_Suppl_PRE_Rev1-2_TI_2011-12-31.pdf
[OID Konzept] eHealth Schweiz
OID-Konzept für das Schweizerische Gesundheitswesen
Ausgabe vom 24. März 2010
http://goo.gl/x534f
[OID Register] OID Register der Stiftung Refdata
http://oid.refdata.ch
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 52 von 54 | 25.08.2012 | Version 1.1
8.2 Abkürzungen und Glossar
Die nachfolgenden Definitionen stammen aus den referenzierten Dokumenten und aus dem Internet (u.a. Firmen-
und Institutionswebseiten, Wikipedia, Google):
APS Arztpraxissoftware (APS). Wird ab und zu für die Abkürzung von Branchensoftware für die Arztpraxis verwendet (siehe auch Ärztesoftware)
Ärztesoftware Arztpraxen Software (z.B. Aeskulap, Elexis, Triamed, Vitomed, …)
BLOB Binary large object (BLOB). Damit werden binäre Daten aus irgendwelchen Quelle verstanden, welche für eine Datenbank nicht weiter verarbeitbar sind und „as is“ gespeichert resp. in Anfragen zurückge-geben werden.
CDA Clinical Document Architecture. Speziell für die medizinische Dokumentation und Kommunikation definierte XML basierte Dokumen-tenarchitektur zur Ermöglichung der herstellerunabhängigen elektronischen Dokumentation und Kommunikation medizinischer Informationen.
CDSS Clinical Decision Support System
DSS Decision Support System
EAN European Article Number (EAN) Frühere (veraltete) Bezeichnung für die heutige GTIN
EPD Elektronisches Patientendossier
EPDG Bundesgesetz über das elektronische Patientendossier
GLN Global Location Number (GLN) ist ein Identifikationsschlüssel innerhalb des standardisierten GS1-Systems.
GTIN Global Trade Item Number (GTIN) Ist eine von der GS1 verwaltete und vergebene Identifikationsnummer, mit der Produkte und Pack-stücke weltweit eindeutig identifiziert werden können. GTIN ist ein Sammelbegriff für die Code-Schemata der Barcode-Kennzeichen. Frühere Bezeichnung: EAN
GS1 Global Standards One (GS1) Ist eine weltweite Organisation, die globale Standards zur Verbesserung von Wertschöpfungsketten gestaltet und umsetzt sowie weltweit für die Vergabe der Global Trade Item Number (GTIN) zustän-dig ist.
HL7 Health Level 7 Kommunikationsstandard für medizinische Informationssysteme mit umfangreichen Definitionen zu Nachrichtentypen und Trigger Events, die Nachrichtenübermittlungen auslösen. www.hl7.org, www.hl7.de, www.hl7.ch
IHE IHE (Integrating the Healthcare Enterprise) Ist eine Initiative zur Verbesserung des technischen Datenaustauschs von IT Systemen im Gesund-heitswesen. Die Initiative, die im Jahr 1998 vom amerikanischen Radiologenverband RSNA (Radiologi-cal Society of North America) und der Vereinigung der Anbieter von medizinischen Informationssys-temen HIMSS (Healthcare Information and Management Systems Society) in den USA gegründet wurde, wird getragen von medizinischen Anwendern, Fachgesellschaften, Verwaltungs- und IT Fach-leuten sowie der medizintechnischen Industrie. Im Laufe der Zeit hat sich IHE zu einer internationalen Bewegung entwickelt, die jetzt auch die speziellen Anforderungen der Gesundheitswesen in Europa und Japan in Betracht zieht. Der europäische Zweig der Initiative arbeitet dabei eng mit der internati-onalen Initiative zusammen und hilft, die besonderen europäischen und nationalen Bedingungen in den internationalen Konzepten zu verankern. Siehe auch www.ihe.org, www.ihe-europe.org, www.ihe-suisse.ch
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 53 von 54 | 25.08.2012 | Version 1.1
KIS Klinisches Informationssystem Damit ist die Gesamtheit aller informationsverarbeitenden Systeme für medizinische und administra-tive Daten in einem Spital gemeint.
Mockup Der aus dem Englischen stammende Begriff Mockup bezeichnet eine Attrappe. Ein Mockup in der Softwareentwicklung bezeichnet einen rudimentären Wegwerf-Prototypen der Benutzerschnittstelle einer zu erstellenden Software. Mockups werden insbesondere in frühen Ent-wicklungsphasen eingesetzt, um Anforderungen an die Benutzeroberfläche in Zusammenarbeit mit Auftraggeber und Anwendern besser ermitteln zu können. Es handelt sich meist um ein reines Grundgerüst der Bedienelemente ohne weitere Funktionalität.
OID In der Informatik ist ein Object Identifier (OID) ein weltweit eindeutiger Bezeichner, der benutzt wird um ein Informationsobjekt zu benennen.
PIS Praxis Informations-System (PIS) Wird ab und zu für die Abkürzung von Branchensoftware für die Arztpraxis verwendet (siehe auch Ärztesoftware)
RIM Reference Information Model Generisches Klassenmodell für medizinische Informationssysteme, das als Ausgangsbasis zur Definiti-on von Nachrichtentypen für den HL7 Standard Version 3 dient.
TC HL7.ch Technisches Komitee (TC) des Vereins „HL7 Benutzergruppe Schweiz“ Entstanden aus der HL7 Projektgruppe xEPR.
W3C Das World Wide Web Consortium (kurz: W3C) Ist das Gremium zur Standardisierung der das World Wide Web betreffenden Techniken. www.w3c.org
X.509 X.509 ist ein ITU-T-Standard für eine Public-Key-Infrastruktur Weitere Informationen: http://de.wikipedia.org/wiki/X.509
HL7 CDA in Arztpraxissoftware | Konzept zur Integration
Seite 54 von 54 | 25.08.2012 | Version 1.1
8.3 Abbildungsverzeichnis
Abbildung 1: Dokumentenaustausch heute ............................ 6
Abbildung 2: Dokumentenaustausch in Zukunft ..................... 6
Abbildung 3: eHealth Architektur Schweiz .............................. 8
Abbildung 4: Evolution IHE Frameworks (Quelle: ihe.net) .... 10
Abbildung 5: Aufbau IHE Integrationsprofil (Quelle: ihe.net) 11
Abbildung 6: CAT 2012 in Bern (Bild: Daniel Bleuer) ............. 12
Abbildung 7: Wechsel zu strukturierten Dokumenten .......... 14
Abbildung 8: Aufbau eines CDA- Dokumentes ...................... 14
Abbildung 9: CDA Body Level 1 ............................................. 15
Abbildung 10: CDA Body Level 2 ........................................... 15
Abbildung 11: CDA Body Level 3 ........................................... 16
Abbildung 12: Validierung von CDA Dokumenten ................. 17
Abbildung 13: Schematron Prozessschritte ........................... 18
Abbildung 14: Methodik zu CDA Tools .................................. 18
Abbildung 15: Einsatzbereich MDHT CDA Tools .................... 19
Abbildung 16: FIRE Daten-Export aus Praxissoftware ........... 20
Abbildung 17: XML Schema der bisherigen FIRE Meldung .... 21
Abbildung 18: Beispiel einer bisherigen XML FIRE Meldung . 21
Abbildung 19: Roadmap eImpfdossier .................................. 23
Abbildung 20: Visualisierung von Interaktionen auf EPha.ch 24
Abbildung 21: Affinity Domain (Quelle: IBM) ........................ 29
Abbildung 22: Basiskomponenten von Gemeinschaften ....... 29
Abbildung 23: IHE XDS Akteure (Quelle: offis.de) ..................32
Abbildung 24: IHE XDS Transaktionen (Quelle: offis.de) ........33
Abbildung 25: Strukturierte Medikamentenliste ...................34
Abbildung 26: Strukturierte Laborwerte ................................34
Abbildung 27: Freitext zu Unfallhergang ...............................35
Abbildung 28: Freitext zu Anamnese .....................................35
Abbildung 29: Freitext zu Status bei Eintritt ..........................35
Abbildung 30: Wiederverwendbare CDA Templates .............35
Abbildung 31: Struktur IHE PRE Dokument ............................36
Abbildung 32: Struktur eines IHE PADV Dokuments ..............36
Abbildung 33: eHealth Connector Modell für eine APS .........37
Abbildung 34: Arztzeugnis: Auswahl Beteiligte ......................40
Abbildung 35: Arztzeugnis: Eingabe Schadeninformationen .40
Abbildung 36: Angaben des Patienten für Arztzeugnis ..........41
Abbildung 37: Vorschau Arztzeugnis .....................................41
Abbildung 38: Integration CDA Erstellung in Elexis ................42
Abbildung 39: Screenshot Bachelorarbeit Arben Thaqi .........42
Abbildung 40: Interaktionen APS - EPha.ch ...........................44
Abbildung 41: Impfprozess (Quelle: eHealth Suisse) .............46
Abbildung 42: Interaktionen APS - eImpfdossier ...................47
Abbildung 43: Interaktionen APS - IHAMZ (FIRE) ...................48
8.4 Tabellenverzeichnis
Tabelle 1: Struktur IHE PRE Dokument .................................. 36
Tabelle 2: Struktur IHE PADV Dokument ............................... 36
Tabelle 3: Struktur IHE IC Dokument .....................................37