HL7 CDA in Arztpraxissoftware

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

http://www.mez-chur.ch/

http://creativecommons.org/licenses/by-sa/3.0/ch/

http://hl7.ch/

http://hl7.org/

http://creativecommons.org/licenses/by-sa/3.0/ch/



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.3 Upload FIRE-Daten ....................................................... 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



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.



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



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



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



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

http://www.e-health-suisse.ch/



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





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.



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.



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/

http://connectathon-results.ihe.net/



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

http://www.hl7.ch/



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



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


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.





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.


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.



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.



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



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

http://www.cdatools.org/

http://openhealthtools.org/

http://wiki.siframework.org/Model+Driven+Health+Tools+%28MDHT%29

http://www.elexis.ch/

http://www.medshare.net/elexis

http://www.elexis.ch/

http://www.elexis-forum.ch/



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

http://icpc.ch/index.php?id=33

http://www.icpc.ch/



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



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

http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/Whitepaper_GrundlagenElektronischesImpfdossier_V1.0.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Suppl_Immunization_Content_Rev2-2_TI_2011-09-09.pdf

http://www.e-health-suisse.ch/umsetzung/00135/00218/index.html?lang=de



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:


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


http://epha.ch/



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



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.




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


6. Patient Demographics Query HL7 V3 (PDQV3)

Integrationsprofil für die Abfrage von Patienten mittels demografischen Suchattributen


7. Document Digital Signature (DSG)

Integrationsprofil für die digitale Signatur von Dokumenten


Weitere Informationen: [IHE DSG]

8. IHE Notification of Document Availability (NAV)

Integrationsprofil für die Benachrichtigung, wenn ein neues Dokument verfügbar ist


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


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


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


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.



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

http://oid.refdata.ch/



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.



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/

http://researcher.watson.ibm.com/researcher/view_project.php?id=892

http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/trackingdiseases/transform/



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.



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.



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)



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


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


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.



IHE ATNA Secure Application

Damit wird eine APS zu einer vertrauenswürdigen Applikation, die in Gemeinschaften eingesetzt werden kann,

welche am System eHealth teilnehmen.


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.


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



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.



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



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.



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.



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



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



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.



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



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

http://www.docbox.ch/



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.



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.



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.



Abbildung 42: Interaktionen APS - eImpfdossier


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



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)


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.



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


http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2a_FT_2011-08-19.pdf

http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf

http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH-II_de_V1.2a.pdf

http://goo.gl/jzrnL

http://goo.gl/EjZ2G

http://goo.gl/2KloM

http://goo.gl/hMevI

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7









[IHE ITI TF-2b] IHE IT Infrastructure (ITI) Technical Framework

Volume 2b (ITI TF-2b): Transactions Part B – Sections 3.29 – 3.51


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


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



[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


[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


[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





















[IHE PHAR PADV] IHE Pharmacy Technical Framework Supplement

Pharmacy Pharmaceutical Advice (PADV)


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)


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





http://goo.gl/x534f

http://oid.refdata.ch/



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



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

http://www.w3c.org/

http://de.wikipedia.org/wiki/X.509



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

Documents

HL7 CDA in Arztpraxissoftware