HL7 CDA in Arztpraxissoftware

Transkript

1 HL7 CDA in Arztpraxissoftware Konzept zur Integration Im Auftrag von Franz Marty, Medizinisches Zentrum gleis d, Chur 25. August 2012 Version 1.1 medshare GmbH Tempelstrasse 8b 3608 Thun-Allmendingen Switzerland

2 Impressum Auftraggeberin Redaktion Medizinisches Zentrum gleis d AG Dr. med. Franz Marty, F.Marty@mez-chur.ch Gürtelstrasse 46, 7000 Chur Tony Schaller, medshare GmbH, tony.schaller@medshare.net 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: Aktuelle Revision 72 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 Benutzergruppe Schweiz erhalten über den Mitgliederbereich von Zugang zu allen Dokumenten im Mitgliederbereich von Obwohl diese Publikation mit grösster Sorgfalt erstellt wurde, kann weder die Auftraggeberin, noch die medshare GmbH irgendwelche Haftung für direkte oder indirekte Schäden übernehmen, die durch den Inhalt dieses Konzepts entstehen könnten. Revisionen V Erste Publikation der genehmigten Dokumentenversion V Einzelne Textkorrekturen ohne Anpassung am Inhalt Seite 2 von Version 1.1

3 Inhalt Impressum... 2 Inhalt Management Summary Ausgangslage Handling von Dokumenten Gestern Heute Morgen Zielsetzung ehealth Strategie Schweiz ehealth Architektur Schweiz Elektronisches Patientendossier Gesetz (EPDG) IHE Initiative IHE Integrationsprofile IHE Content Profiles IHE Connectathon (CAT) HL7 CDA Eigenschaften eines CDA Dokuments CDA Body Level CDA Body Level CDA Body Level Transport der Dokumente Validierung von CDA Dokumenten CDATools Elexis FIRE Ausgangslage Ablauf und Inhalt Datenqualität Perspektiven Wissenschaftliche Leitung eimpfdossier EPha.ch Interaktionen Rezept Service Relevante Grundlagen ehealth Suisse IHE Implementierungsleitfäden CDA-CH Spezifikationen OID Konzept Organisatorisches Konzept Betriebsübergreifende Zusammenarbeit Nutzung medizinischer Daten in einer Gemeinschaft Schützenswerte Information Technisches Konzept Konformität zur ehealth Architektur Schweiz Allgemeines zur CDA Unterstützung in einer APS Medikament-Interaktionscheck Elektronischer Impfausweis Upload FIRE-Daten Auswirkungen auf Applikationslogik einer APS Auswirkungen auf Datenhaltung einer APS Erstellen von CDA Dokumenten (Versand) Verarbeiten von CDA Dokumenten (Empfang) Auswirkungen auf Benutzerinterface einer APS Erstellen von CDA Dokumenten (Versand) Verarbeiten von CDA Dokumenten (Empfang) Validieren von CDA Dokumenten Bestehende IHE/CDA Plug-Ins für Elexis Anwendungsfälle Interaktionscheck und Rezeptservice Datentransfer zwischen Sender und Empfänger Elektronischer Impfausweis Datentransfer zwischen Sender und Empfänger Upload FIRE-Daten Datentransfer zwischen Sender und Empfänger Dateninhalt Anhang Referenzierte Dokumente Abkürzungen und Glossar Abbildungsverzeichnis Tabellenverzeichnis Seite 3 von Version 1.1

4 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 Bedeutung des harmonisierten, elektronischen Datenaustausches zwischen verschiedenen beteiligten Personen und Institutionen 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 Empfehlungen zu Standards und Architektur sind von ehealth-suisse erschienen. Diese nennen eine Standardisierung, die prozessorientiert mit Anwendungsfällen, basierend auf der IHE Initiative erfolgen soll. Die weltweit verankerte IHE Initiative entstand aus dem Bedürfnis heraus die immer wiederkehrenden Integrationsprobleme beim Vernetzen von Computersystemen zu vermindern. IHE erstellt dazu Integrationsprofile, welche auf bestehende, weltweit etablierte Standards 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 werden. 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 verstanden werden können. Dazu müssen Daten technisch und semantisch interoperabel ausgetauscht werden. Eine internationale 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 eingesetzt. 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 umgesetzt 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, solche 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. Seite 4 von Version 1.1

5 2 Ausgangslage Der Alltag des Arztes ist heute immer noch zu oft belastet durch Unzulänglichkeiten von Organisation und Informations- und Kommunikationstechnologien. Oft hat er den Wunsch, auf alle seine Informationen, die sich in seiner Dokumentation ü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 Berichte, 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, Leistungserfassungen, Beurteilungen und andere «administrative» Arbeiten erledigt werden. «Administration» hält von der eigentlichen 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 Informationsund Kommunikationstechnologie zu erleichtern, und zwar in unmittelbarer Zukunft. Wir können nicht von lebenslänglichen Patientenakten träumen, ohne zuerst die Grundlagen zu schaffen, welche elektronisch geführte Krankengeschichten so aufbauen, dass die darin enthaltenen Informationen ohne Medienbrüche weiterverwendet werden können (semantische Interoperabilität). 2.1 Handling von Dokumenten Gestern Nur bei wenigen Ärzten befindet sich vielleicht noch eine Schreibmaschine im Sprechzimmer, mit welcher Überweisungsberichte etc. verfasst und dann per Post verschickt werden. Sämtliche Informationen müssen jedes Mal eingetippt werden. Einzig der Absender ist auf dem Briefpapier aufgedruckt 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 Textverarbeitungssystem, 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 dem zuweisenden Arzt gesendet (Abbildung 1). Es entstehen dadurch nebst langen Transportwegen viele Medienbrüche. Diese haben zur Folge, dass wertvolle Informationen 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( ), Schweiz Ärztezeitung Seite 5 von Version 1.1

6 Abbildung 1: Dokumentenaustausch heute Der Stand der Infrastruktur in Schweizer Arztpraxen sah 2008 so aus 2 : Es gibt nur noch sehr wenige Arztpraxen, die ohne Computer arbeiten. 50 % benutzen einen Computer im Sprechzimmer, 12.5 % benutzen eine elektronische Krankengeschichte, 8 % planen eine elektronische Krankengeschichte innerhalb der nächsten 2 Jahre 3. Die Erstellung und das Versenden, wie auch der Empfang und die strukturierte lokale Ablage von elektronischen Dokumenten 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 Patienten über diese etablierten Mechanismen nicht sehr gross. Vielerorts werden heute bereits Arztbriefe in Form von PDF Dateien (Medienbruch) übertragen Morgen Die medizinischen Daten im eigenen Informationssystem sollen zur Erstellung von Arztbriefen weiterverwendet werden können: Diagnoselisten, Medikamentenlisten, aktuelle Probleme etc. Auch sollen die von aussen erhaltenen klinischen 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, Anmerkung des Autors: hat sich seit dieser Veröffentlichung nur unmerklich verändert Seite 6 von Version 1.1

7 3 Zielsetzung Das vorliegende Dokument soll die Bedeutung des harmonisierten, elektronischen Datenaustausches zwischen verschiedenen beteiligten Personen und Institutionen im Gesundheitswesen aufzeigen und darstellen, wie eine Integration in einer Branchensoftware für Arztpraxen, sogenannte Arztpraxissoftware realisiert werden sollte, um eine möglichst 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 eingesetzt 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 Dokumentenaustausch 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 genannt 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 eine «Strategie ehealth Schweiz» herausgegeben. Darin steht: Unter ehealth oder Elektronischen Gesundheitsdiensten versteht man den integrierten Einsatz von Informations- 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 werden 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 Entscheidungen in Bezug auf ihr Gesundheitsverhalten und ihre Gesundheitsprobleme beteiligt und stärken damit ihre Gesundheitskompetenz. 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 Handlungsfelder identifiziert: Elektronisches Patientendossier Online-Dienste Umsetzung der Strategie Seite 7 von Version 1.1

8 Innerhalb dieser Handlungsfelder wurden verschiedene Ziele formuliert. Die beiden folgenden scheinen im vorliegenden 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 Patientendossier ). 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: 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 Seite 8 von Version 1.1

9 Folgende Empfehlungen von ehealth-suisse sind bisher erschienen. Sie nennen eine Standardisierung, die prozessorientiert 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 Patientensicherheit 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 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 Patientendossier eröffnet. Die Vernehmlassung dauerte bis am 20. Dezember Es sind 96 Stellungnahmen eingegangen, welche auf der Website des BAG zugänglich sind 4. 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): Seite 9 von Version 1.1

10 3.4 IHE Initiative IHE (Integrating the Healthcare Enterprise) ist eine internationale Initiative zur Verbesserung des technischen Datenaustausches von IT-Systemen im Gesundheitswesen. Bei IHE geht es nicht darum neue Standards zu entwickeln, sondern existierende Standards wie DICOM (Digital Imaging 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 Kommunikationsstandards 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 entstand aus dem Bedürfnis heraus die immer wiederkehrenden Integrationsprobleme beim Vernetzen von Computersystemen zu vermindern. Mittlerweile ist IHE zu einer weltweiten Initiative mit mehreren Länderorganisationen geworden. Die IHE hat die Technical Frameworks in einzelne Anwendungsgebiete der Gesundheitsinformatik aufgeteilt (IHE Domains). Momentan sind Informationen zu folgenden IHE Domänen öffentlich zugänglich: Abbildung 4: Evolution IHE Frameworks (Quelle: ihe.net) IHE Integrationsprofile Für die Lösung der identifizierten Interoperabilitätsprobleme werden entsprechende Implementierungsleitfäden erstellt. Dabei werden bestehende Standards und Normen evaluiert und eingesetzt. Erfahrene IT-Experten im Gesundheitswesen legen fest, wie die entsprechenden Standards und Normen angewendet werden sollen. Diese Anweisungen werden in Zusammenarbeit von medizinischen und technischen Fachpersonen in so genannten IHE Integration Profiles dokumentiert. Seite 10 von Version 1.1

11 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äftsprozesse und beschreiben Probleme und deren Lösungen. Transaktionen definieren im Detail, wie die Profile umgesetzt 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) 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 Gesundheitswesen und den darin stattfindenden Behandlungsprozessen abbilden zu können, hat IHE bereits zahlreiche Inhaltsprofile 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. Seite 11 von Version 1.1

12 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ähigkeit 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 verschiedenen 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 abrufbar 5. Diese Resultate können in Beschaffungsprojekten von Informationssystemen verwendet werden. Das Prinzip dieser Testveranstaltung ist einzigartig. Die Verbindung durch die Entwickler von Systemen erfolgt dabei nicht nur auf technischer Ebene. Der Gedankenaustausch ohne Konkurrenzdruck zugunsten der Sache, also der Interoperabilität ist ein wichtiger Schritt in die Richtung Plug and Play, den andere Industrien längst vollzogen haben 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 nehmen sich für einander Zeit. Nicht selten ziehen sich die Softwareentwickler abends nach Schliessung der Connectathon-Testhalle in ihre Hotelzimmer zurück, um in der eigenen Software Erweiterungen zu implementieren oder Korrekturen 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 Datenbank durch die neutrale IHE Organisation geführt wird, besonders aussagekräftig. Darüber hinaus können die Hersteller 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 bestimmtes Produkt unterstützt werden. 5 Seite 12 von Version 1.1

13 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 Arbeitsalltag 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 medienbruchfreien 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 Gesundheitseinrichtungen erfordert einen engen Datenaustausch. In vielen heutigen Situationen steht der elektronischen 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 Arbeitsablä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 Spezifikation ist öffentlich frei verfügbar 6. Die aktuelle Version der Spezifikation definiert im Header hauptsächlich die organisatorischen Eigenschaften eines medizinischen Dokuments (Patientendaten, Empfänger, Ereignis, Dokumentenidentifikation etc.). Die medizinischen Informationen werden in Abschnitte (Sections) und Einträge (Entries) gegliedert 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 Seite 13 von Version 1.1

14 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 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 Medikamentenlisten). Erforderlich sind Vereinbarungen über Standards, es braucht die eindeutige Identifikation von Patienten, Ä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 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 Absender 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 Seite 14 von Version 1.1

15 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 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 bisherigen Dokumentenerstellung weiterzuführen. Abbildung 9: CDA Body Level CDA Body Level 2 Stellt sich nun das Bedürfnis der Teilnehmer nach weiterer Strukturierung ein, müssen sie sich bei Level 2 auf zusätzliche 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 Codierungssystem 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 Erstellen eines CDA Arztbriefes) oder automatisiert in ein Informationssystem beim Empfänger ablegen. Die daraus gewonnene Effizienz- und Qualitätsverbesserung ist allerdings von der Qualität der zugrunde liegenden Daten abhängig. Abbildung 10: CDA Body Level 2 Seite 15 von Version 1.1

16 3.5.4 CDA Body Level 3 Im CDA Body Level 3 kommen weitere Spezifikationen hinzu. Über Einträge (Entries) können einzelne Textpassagen mit zusätzlichen maschinenauswertbaren Informationen angereichert werden. In Abbildung 11 wird das Stichwort Asthma aus dem Freitext mittels der codierten Terminologe SNOMED CT (Systematized Nomenclature of Human and Veterinary Medicine) eindeutig bezeichnet und zwecks maschineller Auswertung codiert. Abbildung 11: CDA Body Level 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 besonders 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 Papierdokumenten darauf, dass die Dokumente nur bei der Existenz einer Einverständniserklärung oder einer daraus resultierenden 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. Seite 16 von Version 1.1

17 3.5.6 Validierung von CDA Dokumenten An den internationalen IHE Connectathons in Europa, Nordamerika und Asien wird die Testsoftware Gazelle, eingesetzt. 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 Dokument den, vom Herausgeber der Vorlage beschriebenen Geschäftsregeln entspricht. Dieses mehrstufige Validierungsverfahren erlaubt die Sicherstellung einer sehr hohen Konformanz auf hohem Detaillierungsgrad, 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 Anwendung dieses Validierungsverfahrens kann deshalb der Interpretationsspielraum der beteiligten Systeme auf ein noch nie dagewesenes Minimum beschränkt werden. Seite 17 von Version 1.1

18 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 Technologien (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 zudem, Geschäftsregeln für Dokumentenvorlagen oder Formulare durch deren Herausgeber bestimmen und implementieren 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 Interpretationsspielraum 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 CDATools Rund um die Erzeugung (Serialisierung) und Verarbeitung (Deserialisierung) von CDA Dokumenten gibt es verschiedene Tools. Aufgrund internationaler Empfehlungen scheint aus heutiger Sicht das OpenSource Projekt CDATools die erfolgversprechendste Grundlage darzustellen. Abbildung 14: Methodik zu CDA Tools Seite 18 von Version 1.1

19 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 genutzt werden können. Abbildung 15: Einsatzbereich MDHT CDA Tools Weitere Informationen zu CDATools: Elexis Elexis ist das führende OpenSource Arztpraxisprogramm im deutschsprachigen Raum. Elexis bietet dank seiner Offenheit 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 SourceForge 7 unter der Eclipse Public License, sowie auf 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 Dienstleistungen für Softwareentwicklung rund um Elexis an. Weitere Informationen zum OpenSource Produkt Elexis: ssh://elexis.hg.sourceforge.net/hgroot/elexis/elexis-base Seite 19 von Version 1.1

20 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 entnommen 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 gewisse 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 Klassifizierungssystem eingeführt und ist der SGAM-Standard zur Führung der Problemliste geworden. Führende Praxissoftwareprodukte, darunter auch Elexis unterstützen ICPC-2. Seit Januar 2009 konnten von 65 Hausärzten erfolgreich Daten hochgeladen werden. Damit waren am > 650'000 Konsultationen mit > 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 einsehbar 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 Aufwand 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 Seite 20 von Version 1.1

21 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 XML Schema Das FIRE Daten-Set wird anhand des folgenden XML Schemas erstellt: Abbildung 17: XML Schema der bisherigen FIRE Meldung Beispiel XML <?xml version="1.0" encoding="utf-16"?> <meldung> <konsultation> <konsdate> </konsdate> <patid>14353</patid> <patyear>1931</patyear> <patgender>female</patgender> <arzt> </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> </labordate> <analyse>bsr</analyse> <einheit>mm/h</einheit> <max> 4</max> <laborwert>8</laborwert> </labor> <medi> <pharmacode> </pharmacode> <dosismo>1</dosismo> <stopdate> </stopdate> </medi> <medi> <pharmacode> </pharmacode> <dosismo>1</dosismo> <dosismi>1</dosismi> <dosisab>1</dosisab> <stopdate> </stopdate> <stopbegr>unverträglichkeit</stopbegr> </medi> </konsultation> </meldung> Abbildung 18: Beispiel einer bisherigen XML FIRE Meldung Seite 21 von Version 1.1

22 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 Projektarbeit die Optimierung der Datenqualität sein; langfristig werden diese Erkenntnisse auch zur Verbesserung der Praxissoftware-Tools dienen 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 Codierung 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 Wissenschaftliche Leitung Die wissenschaftliche Leitung des Projektes liegt in der Verantwortung des Instituts für Hausarztmedizin der Universitä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 koordiniertes ehealth"-vorhaben realisieren. Die Chancen für eine erfolgreiche Umsetzung eines Elektronischen Impfdossiers" scheinen gut. Das Koordinationsorgan hat deshalb Mitte 2011 den Auftrag zur Erarbeitung einer Vorstudie e- Impfungen erteilt. Die Vorstudie wurde am publiziert. Im Bereich der Lösungsarchitektur verweist diese auf ein eigens dafür erstelltes Whitepaper Grundlagen für ein elektronisches Impfdossier der HL7 Benutzergruppe Schweiz 8. Neben den zu klärenden Punkten (Verhältnis zu bestehenden Modellversuchen, Trägerschaft und Finanzierung, Rechtliche Grundlagen, 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änzung zum IHE Integrationsprofil noch ein Implementierungsleitfaden erstellt werden, welcher die helvetischen Ausprägungen des elektronischen Impfausweises festlegt. Fazit aus dem Zwischenbericht 10 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 Patientendossier als Basiselement angestrebt wird. Dahingegen scheinen die privaten Bemühungen durch z.b. meineimpfungen.ch oder das Gesundheitsdossier Evita, die beide heute schon ein e-impfdossier-service anbieten, schneller eine kritische Masse zu erreichen Seite 22 von Version 1.1

23 Trotz teilweise gegensätzlichen Standpunkten werden diese konkreten Schritte vorgeschlagen: 1. Umsetzung eines schweizweit verfügbaren Impfcheck-Services als Clinical Decision Support System (CDSS), wahrscheinlich 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 angegangen werden. Abbildung 19: Roadmap eimpfdossier Weitere Informationen zum eimpfdossier: 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 entnommen werden, welche auch Quelle für diese Zusammenfassung ist 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 Seite 23 von Version 1.1

24 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 Medikamenteninformationsdienstes 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. Einzigartig an diesem Konzept ist, dass jede Interaktion eine Richtung aufweist. Es gibt also normalerweise einen Täter (Ursache 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 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 Seite 24 von Version 1.1

25 4 Relevante Grundlagen Das vorliegende Dokument nimmt Bezug auf vorbestehende Architekturgrundlagen und baut insbesondere auf folgenden 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, insbesondere mit den Integrationsprofilen der Domäne IT-Infrastructure [Empfehlungen I], S Basiskomponenten der Architektur ehealth Schweiz [Empfehlungen I], S Der Dokumentenaustausch in der Schweiz basiert auf gleichberechtigten Gemeinschaften, die über einen oder mehrere Zugangspunkte kommunizieren. [Empfehlungen II], Empfehlung 1, S 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; Gemeinschaften bleiben in ihrer internen Systemgestaltung frei. [Empfehlungen II], Empfehlung 2, S Es wird ein Schweiz weites Verzeichnis der zertifizierten Gemeinschaften geführt. Nur diese erhalten die Möglichkeit, 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 Gemeinschaft 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 verstanden 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 Kapitel 6 Technisches Konzept auf Seite 32). Dokumente können gemäss Empfehlungen z.b. in sogenannten IHE XDS Repositories und Registries gespeichert werden. Sämtliche Ausführungen im vorliegenden Konzept sind konform zu den Architekturgrundlagen von ehealth Suisse. 4.2 IHE Implementierungsleitfäden Folgende IHE Implementierungsleitfäden zu Integrationsprofilen sind im vorliegenden Kontext relevant: 1. Audit Trail and Node Authentication (ATNA) Basisinfrastruktur für eine sichere und vertrauenswürdige Systemteilnahme von IHE Akteuren Weitere Informationen: [IHE ITI TF-1], Kapitel 9 2. Cross-Enterprise Document Sharing (XDS) Basisinfrastruktur zur betriebsübergreifenden Nutzung von Dokumenten. Weitere Informationen: [IHE ITI TF-1], Kapitel 10 Seite 25 von Version 1.1

26 3. IHE Patient Care Coordination (PCC) Technical Framework Basisinfrastruktur für eine koordinierte Informationsübergabe bei der Übergabe der Verantwortlichkeit an einen anderen Behandelnden im Behandlungsprozess eines Patienten Weitere Informationen: [IHE PCC TF-1] 4. Community Medication Prescription and Dispense (CMPD) Basisinfrastruktur für den betriebsübergreifenden Informationsaustausch zur medikamentösen Therapie Supplement for Trial Implementation Weitere Informationen: [IHE PHAR CMPD] 5. Patient Identifier Cross-referencing HL7 V3 (PIXV3) Integrationsprofil für den Abgleich der Patienten-Identifikationen aus verschiedenen Systemen/Domänen Weitere Informationen: [IHE ITI TF-1], Kapitel Patient Demographics Query HL7 V3 (PDQV3) Integrationsprofil für die Abfrage von Patienten mittels demografischen Suchattributen Weitere Informationen: [IHE ITI TF-1], Kapitel Document Digital Signature (DSG) Integrationsprofil für die digitale Signatur von Dokumenten Supplement for Trial Implementation Weitere Informationen: [IHE DSG] 8. IHE Notification of Document Availability (NAV) Integrationsprofil für die Benachrichtigung, wenn ein neues Dokument verfügbar ist Supplement for Trial Implementation Weitere Informationen: [IHE NAV] Folgende IHE Implementierungsleitfäden zu Content Profiles sind im vorliegenden Kontext relevant: 9. IHE Patient Care Coordination CDA Content Modules Dieses Profil macht zahlreiche Vorgaben zum Einsatz von CDA in mehreren IHE Implementierungsleitfäden Supplement for Trial Implementation Weitere Informationen: [IHE PCC CDA] 10. IHE Pharmacy Pharmaceutical Advice (PADV) Dieses Profil ist für die Rückmeldung von Interaktionschecks aus EPha.ch (Import in APS) relevant Supplement for Trial Implementation Weitere Informationen: [IHE PHAR PADV]. 11. IHE Pharmacy Prescription (PRE) Dieses Profil ist für die Übermittlung eines Rezepts von einer APS an EPha.ch relevant - für die Nutzung des Interaktionschecks oder des Rezept Services Supplement for Trial Implementation Weitere Informationen: [IHE PHAR PRE] 12. IHE Immunization Content (IC) Dieses Profil ist für die Übermittlung von Impfungen ans eimpfdossier oder an einen Impfcheck-Service und auch für die Abfrage des elektronischen Impfausweises aus dem eimpfdossier und dessen Import in eine APS relevant. Verabschiedetes Supplement for Trial Implementation (wird in den offiziellen Release von IHE PCC einfliessen) Weitere Informationen: [IHE PCC IC] Es ist zu beachten, dass einige der obenstehenden IHE Profile den Status Trial Implementation haben und demzufolge nach den ersten Tests an IHE Connectathons noch Änderungen zu erwarten sind. Die Leitfäden scheinen aber qualitativ hochwertig und es kann davon ausgegangen werden, dass keine markanten Änderungen notwendig sind. Seite 26 von Version 1.1

27 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 Einsatz 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 Kontext 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] ; Seite 27 von Version 1.1

28 5 Organisatorisches Konzept 5.1 Betriebsübergreifende Zusammenarbeit Der Bedarf, Dokumente im Behandlungsprozess auszutauschen ist gross und unbestritten. Die Fallbeispiele Hüftgelenkersatz in [CDA-CH] und Auffahrunfall in [CDA-CH-II] zeigen deutlich die grosse Anzahl Dokumente und die Vielfältigkeit und Komplexität der Inhalte dieser Dokumente, die zwischen verschiedenen Beteiligten im Behandlungsfall ausgetauscht werden müssen. Heute geschieht dies wie einleitend ausgeführt mit herkömmlichen Mitteln, welche zahlreiche 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 internationale 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 Absprachen zwischen Sender und Empfänger geben. 3. Interoperabilität muss auf technischer und semantischer Ebene gewährleistet sein, damit der Prozess auch tatsä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 Standards 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 fortlaufend 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önnen. In Zukunft werden sich deshalb Behandelnde vermehrt in Gemeinschaften zusammenschliessen. Seite 28 von Version 1.1

29 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 ist 11 : 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 gesehen dynamisch verändern wird. Als mögliche Gemeinschaften können Ärztenetzwerke, Kantone, Spitalregionen oder auch regionsübergreifende Institutionen verstanden werden. Es ist auch denkbar, dass sich in grenznahen Regionen auch länderübergreifende Gemeinschaften 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 oder Seite 29 von Version 1.1

30 In einer Gemeinschaft nutzen die Systemteilnehmer also gemeinsam medizinische Daten zu Patienten. Die vertraglichen, datenschutzrechtlichen und technischen Voraussetzungen sind durch die Gemeinschaft sicherzustellen. Die bisherigen Empfehlungen von ehealth Suisse lassen den Gemeinschaften die interne Ausgestaltung frei. Sobald Gemeinschaften 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 technologieneutraler 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 erstellt 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 unterstü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ömmliche Dokumente. Im Unterschied zum papierbasierten Datenaustausch ist beim elektronischen Datenaustausch allerdings 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 bisher 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 Gesetzgebung. 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 relevanten 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önlichkeitsschutz und Patientensicherheit zu unterscheiden. Die Behandlungsqualität ist dann am höchsten, wenn Behandelnde eine vollständige Sicht auf den Gesundheitszustand 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 Behandelnden 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 Vertrauenspersonen zugänglich zu machen. Jeder Bürger muss sich also ganz persönlich dazu entscheiden, ob ihm der Schutz seiner Persönlichkeit oder die Behandlungsqualitä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. Seite 30 von Version 1.1

31 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 ausgegangen 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 werden, damit Sender und Empfänger ohne gesonderte Absprache den vor- resp. nachgelagerten Prozess korrekt abarbeiten können. Die Angabe von redundanten oder zusätzlichen Informationen ist sowohl hinsichtlich Erfüllung der Anforderungen zum Datenschutz, wie auch hinsichtlich der Performance zu vermeiden. Die, mit dem zu vorliegenden Konzept ausgetauschten Daten gehören also gemäss Schweizerischem Datenschutzgesetz in die Kategorie besonders schützenswerte Daten. Damit wird insbesondere die Weitergabe dieser Daten erschwert. Die Verantwortung für diese Daten im produktiven Einsatz liegt bei den Anwendern. Seite 31 von Version 1.1

32 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 wollen. 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 machen, macht es durchaus Sinn, dass APS mit den dafür vorgesehenen IHE Akteuren kommunizieren können. Dies vereinfacht 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 seiner APS einen Patienten anhand der Patientenidentifikation der Gemeinschaft zu finden. Die bestehenden Suchfenster 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 Dokumente 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 Gemeinschaft 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 Anwender 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 Verwendung von Dokumenten in einer Gemeinschaft. Abbildung 23: IHE XDS Akteure (Quelle: offis.de) Seite 32 von Version 1.1

33 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 Connectathon 2011 werden nur noch XDS.b Transaktionen getestet. APS sollen deshalb die XDS.b Transaktionen implementieren (siehe dazu nachfolgende Auflistung). Abbildung 24: IHE XDS Transaktionen (Quelle: offis.de) APS müssen als Konsequenz aus obenstehenden Ausführungen mit den Funktionen folgender IHE Akteure erweitert werden: IHE XDS Document Source Damit wird eine APS zur Dokumentenquelle innerhalb einer Gemeinschaft Zu implementierende Transaktionen: o Provide and Register Document Set-b [ITI-41] (siehe [IHE ITI TF-2b], Kapitel 3.41) IHE XDS Document Consumer Damit kann eine APS Dokumente innerhalb der Gemeinschaft oder gemeinschaftsübergreifend abfragen/anzeigen Zu implementierende Transaktionen: o Registry Stored Query [ITI-18] (siehe [IHE ITI TF-2a], Kapitel 3.18) o Retrieve Document Set [ITI-43] (siehe [IHE ITI TF-2b], Kapitel 3.43) IHE PIX Patient Identifier Cross-reference Consumer Damit kann eine APS die Patientenidentifikation der Gemeinschaft erfragen Zu implementierende Transaktionen: o PIXV3 Query [ITI-45] (siehe [IHE ITI TF-2b], Kapitel 3.45) Hinweis: Allenfalls kann es Sinn machen zusätzlich Transaktionen aus dem IHE Patient Demographics Query (PDQV3) zu implementieren. Seite 33 von Version 1.1

34 IHE ATNA Secure Application Damit wird eine APS zu einer vertrauenswürdigen Applikation, die in Gemeinschaften eingesetzt werden kann, welche am System ehealth teilnehmen. Zu implementierende Transaktionen: o Authenticate Node [ITI-19] (siehe [IHE ITI TF-2a], Kapitel 3.19) o Record Audit Event [ITI-20] (siehe [IHE ITI TF-2a], Kapitel 3.20) IHE CT Time Client Damit wird sichergestellt, dass in der APS die identische Zeit verwendet wird wie bei anderen Systemen der Gemeinschaft. Grundsätzlich erfolgt der Abgleich der Systemuhr auf der Ebene des Betriebssystems. Da APS auf unterschiedlich gut gewarteten Infrastrukturen betrieben wird, sollen APS deshalb diese Transaktion so implementieren, dass der Zeitserver abgefragt wird und die erhaltene Zeit mit der lokalen Systemuhr verglichen wird. Weicht die lokale Systemuhr mehr als 2 Sekunden vom Zeitserver ab, kann in der APS nichts mehr gespeichert werden bis die Abweichung wieder innerhalb dieser Toleranz ist. Zu implementierende Transaktionen: o Maintain Time [ITI-1] (siehe [IHE ITI TF-2a], Kapitel 3.1) 6.2 Allgemeines zur CDA Unterstützung in einer APS Eine APS muss in der Lage sein, verschiedene HL7 CDA Dokumenteninhalte zu verarbeiten (erstellen und anzeigen resp. importieren und exportieren). Mit den in diesem Konzept genannten Elementen wird eine APS auf der Ebene der Architektur (Datenablage und logische Funktionalität) soweit vorbereitet, dass sämtliche Arten von HL7 CDA Dokumenten 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 Dokument 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 Medikamente, 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 Seite 34 von Version 1.1

35 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 Informationseinheiten 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 wiederverwendet 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. Seite 35 von Version 1.1

36 6.2.1 Medikament-Interaktionscheck Basis: IHE Pharmacy Prescription (PRE) und IHE Pharmacy Pharmaceutical Advice (PADV). Ein helvetisierter Implementierungsleitfaden muss zusätzlich noch erstellt werden. Inhalt IHE PRE Dokument Template Participants Information R Required if known Patient Information Optional Participant Information R O Authorization R Patient Contacts O Payers R Coded Vital Signs O Allergies and Drug Sensitivities O Active Problems O Resolved Problems O Immunizations O Pregnancy History O Abbildung 31: Struktur IHE PRE Dokument Prescription R Tabelle 1: Struktur IHE PRE Dokument Inhalt IHE PADV Dokument Template Participants Information R Required if known Patient Information Optional Participant Information R O Authorization R Pharmaceutical Advice R Tabelle 2: Struktur IHE PADV Dokument Abbildung 32: Struktur eines IHE PADV Dokuments Seite 36 von Version 1.1

37 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 Authors and Informants R NONE Active Problems R History of Past Illness R Allergies and Other Adverse Reactions R Medications R Coded Results R Coded Vital Signs R Pregnancy History R Coded Advance Directives R Comments R Simple Observation R Tabelle 3: Struktur IHE IC Dokument 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 implementiert 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 Projektphase ein Design entworfen werden, bevor mit der eigentlichen Implementierung begonnen wird. Seite 37 von Version 1.1

38 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 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 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 aufgefallen sind. Diese Liste ist nicht abschliessend und bezieht sich auf den Stand der Dinge in der, am produktiven Elexis Version 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 verstanden 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 werden 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. Seite 38 von Version 1.1

39 Notwendige Erweiterungen für die Verwaltung von CDA Dokumenten Zwecks Rückverfolgbarkeit sollen alle erstellten CDA Dokumente in der Datenhaltung von Elexis gespeichert werden. 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 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 Dokumente 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 aufnehmen 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 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 Anwenderwunsch automatisch oder optional). 3. Diagnosen 4. Medikamente 5. Laborwerte 6. Vitalzeichen 7. Arbeitsfähigkeit Seite 39 von Version 1.1

40 6.5 Auswirkungen auf Benutzerinterface einer APS 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 bestehenden 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 aufgezeigt 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 (Beispieldokument 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 Seite 40 von Version 1.1

41 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 einbetten (PDF base64-codiert im XML). Mit dem Format PDF/A können die Vorgaben für Langzeitarchivierung des Bundesarchivs erfüllt werden. Seite 41 von Version 1.1

42 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 Verarbeiten von CDA Dokumenten (Empfang) Elektronische Dokumente darunter auch CDA Dokumente können auf verschiedene Wege in eine Arztpraxis gelangen (z.b. Mail, USB-Stick, CD-ROM, Download, Abfrage über Webservices). Eine APS soll deshalb einerseits einen Import (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 Seite 42 von Version 1.1

43 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 Validierung von CDA Dokumenten herausgeben. Siehe dazu auch die Einführung in Kapitel Validierung von CDA Dokumenten 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ückgewiesen werden. Hier gibt es keine Aufweichung der Validierung wie oben bei der semantischen Interoperabilität erwä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 ( 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 Seite 43 von Version 1.1

44 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 beschriebenen 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 deshalb so in eine APS integriert werden, dass ein Prozessablauf mit technischer und semantischer Interoperabilität gewä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 allerdings, dass diese anderen Stakeholder in der Lage sind, damit umzugehen. Gerade im Verschreibungs- und Distributionsprozess 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 innerhalb der Landesgrenzen abwickeln. Touristen, Geschäftsreisende oder Rentner die im Süden den Winter verbringen könnten wesentlich von solchen, grenzüberschreitenden Prozessen profitieren. Seite 44 von Version 1.1

45 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 Beratung 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 übernommen werden. Andernfalls ist beim Arzt eine, von der Realität abweichende Medikamentenverschreibung 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 dargestellt 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. Selbstverständlich macht es aber durchaus Sinn, diesen Prozess mit dem Rezept Service von EPha.ch zu kombinieren. Dies ist aber keine Voraussetzung. Technische Beschreibung: URL mit URL Parametern aufrufen und Webseite im Browser anzeigen. Seite 45 von Version 1.1

46 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 vorbeugende Tetanus-Impfung bei Verletzungen, Impfungen bei Reisen in Risikogebiete oder Grippeimpfungen bei bestimmten 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 bis Rückmeldungen gesammelt werden, unterscheiden einen e-impfcheck-dienst (VAC-CDSS), welcher basierend auf anonymisierten Patienteninformationen konkrete Impfempfehlungen herausgibt und ein elektronischen Impfdossier, also der eigentliche Ablageort des elektronischen Impfausweises eines Patienten. Die Empfehlungen von Standards & Architektur erklären sogenannte Stammgemeinschaften als Ablageort für Dokumente, 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 Änderungen 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 auszutauschenden Datenformat ändert damit aber nichts. Seite 46 von Version 1.1

47 Abbildung 42: Interaktionen APS - eimpfdossier Datentransfer zwischen Sender und Empfänger Der Datentransfer erfolgt gemäss obiger Abbildung 42 an zwei unterschiedliche, externe Systeme. 1. Impfcheck Service (VAC-CDSS) Dabei wird ein elektronischer Impfausweis mit anonymisierten Patientendaten voraussichtlich mittels [ITI-41] (Content Profile: IHE IC) an den Impfcheck Service (VAC-CDSS) übermittelt. Zahlreiche Anfragen können durch den Algorithmus im VAC-CDSS automatisch beantwortet werden. Andere müssen zuerst von einem Impfexperten bearbeitet werden. Demzufolge kann nicht bestimmt werden, wann die Impfempfehlung verfügbar sein wird. Eine APS soll innerhalb für eine konfigurierbare Dauer automatisch in kurzen Intervallen (z.b. alle 10 Sekunden) versuchen die Impfempfehlung mittels [ITI-43] (Content Profile: IHE IC) abzufragen. Sollte die Impfempfehlung innerhalb dieser Zeitspanne nicht verfügbar sein, muss der Arzt vom Impfcheck Service (VAC-CDSS) über einen anderen Kanal benachrichtigt werden, sobald die Impfempfehlung verfügbar ist. Eine APS soll dazu die Möglichkeit bieten, die Transaktion Impfempfehlung mittels [ITI-43] (Content Profile: IHE IC) abholen, manuell zu starten. 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 Stelle 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 dieses Konzepts noch nicht bekannt, wie Dokumente gemeinschaftsübergreifend aktualisiert werden sollen. Grundsätzlich werden auch hier die IHE Transaktionen [ITI-41] 12 und [ITI-43] (Content Profile bei beiden: IHE IC) eingesetzt. 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 Seite 47 von Version 1.1

48 7.3 Upload FIRE-Daten Wie einleitend beschrieben worden ist, sollen Daten zu Forschungszwecken von APS an entsprechende Forschungsinstitute ü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 Empfä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) Datentransfer zwischen Sender und Empfänger Für den FIRE Upload gibt es keine IHE Profile oder andere Implementierungsleitfäden. Es gibt deshalb derzeit keine konkreten Integrations- und CDA Inhaltsprofile. Diese müssen für den FIRE Upload zuerst erstellt werden. Unabhängig davon kann an dieser Stelle festgehalten werden, dass eine APS über den ehealth Connector entweder HL7 CDA Dokumente oder SMEEX Container produziert und diese über einen, noch zu definierenden Webservice ans IHAMZ übermittelt Dateninhalt Derzeit existiert lediglich ein XML Schema (siehe Kapitel XML Schema auf Seite 21). Weitergehende Informationen 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 Codierungen teilweise gleiche Daten verwendet. Das IHAMZ arbeitet deshalb derzeit in Zusammenarbeit mit dem Verband Schweizerischer Fachhäuser für Medizinal-Informatik (VSFM) an einem KTI Projekt für die komplette Überarbeitung der FIRE Daten Sammlung. Aufgrund der Tatsache, dass der bisherige FIRE Upload bereits in den wichtigsten APS (darunter auch Elexis) implementiert 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) eingesetzt 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. Seite 48 von Version 1.1