grobkonzept - Portal Kanton St.Gallen

Transcription

GROBKONZEPT
Master Patient Index
07. September 2007, Version 1.2 (freigegeben)
medshare GmbH
Speckhubel 132
3631 Höfen b. Thun
Switzerland
phone: 033 341 23 44
fax: 033 341 23 46
[email protected]
www.medshare.net
Grobkonzept, Master Patient Index
Dokumentinformationen
Auftraggeber
Gesundheitsdepartement St. Gallen
Moosbruggstrasse 11, 9001 St. Gallen
Kontaktperson des
Auftraggebers
Hansjörg Looser
Telefon: +41 71 229 47 99
eMail: [email protected]
Autoren / Ansprechpartner
medshare GmbH
Tony Schaller
Telefon: +41 33 341 23 44
Christoph Knoepfel
Telefon: +41 62 777 45 10
Datum
07. September 2007
Version
Version 1.2 (freigegeben)
Dokumentgeschichte
Version 1.2 freigegeben am 07. September 2007 durch Hansjörg Looser
grobkonzept_v1.2.doc
Seite 2 von 2
Inhalt
Dokumentinformationen .....................................................................................................................................2 Inhalt ...................................................................................................................................................................3 1 Management Summary ...............................................................................................................................5 2 Ausgangslage..............................................................................................................................................6 2.1 Zielsetzung .........................................................................................................................................6 2.2 Abgrenzung ........................................................................................................................................6 3 Grundlagen (Basistechnologien) .................................................................................................................7 3.1 HL7 .....................................................................................................................................................7 3.1.1 Reference Information Model (RIM) ...............................................................................................8 3.2 VHitG Initiative „Intersektorale Kommunikation“.................................................................................8 3.2.1 VHitG PID Profil: Konzept zur Patientenidentifikation ....................................................................9 3.3 IHE Initiative........................................................................................................................................9 3.3.1 IHE Patient Identity Cross Referencing (PIX)...............................................................................11 3.3.2 Beziehung zwischen dem IHE Integrationsprofil PIX und der Verwaltung eines MPI ..................12 3.3.3 IHE Consistent Time (CT) ............................................................................................................12 3.3.4 IHE Audit Trail and Node Authentication (ATNA) .........................................................................13 3.4 Object Identifier (OID) .......................................................................................................................14 3.4.1 Beispiel Patientenidentifikation .....................................................................................................15 3.4.2 Beispiel Diagnose .........................................................................................................................15 3.4.3 HL7 OID in der Schweiz ...............................................................................................................15 3.5 Routing im Internet ...........................................................................................................................15 4 Alternative Grundlagen..............................................................................................................................17 4.1 ISO/TC 215 .......................................................................................................................................17 4.2 CEN/TC 251 .....................................................................................................................................17 4.3 Schweizerische Normenvereinigung (SNV) .....................................................................................18 5 Blick ins benachbarte Ausland ..................................................................................................................19 5.1 Deutschland ......................................................................................................................................19 5.2 Österreich .........................................................................................................................................19 5.3 Frankreich .........................................................................................................................................20 5.4 Italien ................................................................................................................................................20 5.5 Kanada .............................................................................................................................................21 6 Lösungskonzept ........................................................................................................................................22 6.1 Klinisches Szenario ..........................................................................................................................22 6.2 Business Use Cases ........................................................................................................................22 6.2.1 Anmeldung einer Untersuchung ...................................................................................................23 6.2.2 Abklärung der Kostengutsprache .................................................................................................24 6.2.3 Auskunft zum Krankheitsverlauf ...................................................................................................24 6.2.4 Behandlung eines Patienten abschliessen...................................................................................25 6.3 Abhängigkeiten zur Performance der Systeme ................................................................................25 6.3.1 Patientenanmeldung .....................................................................................................................25 6.3.2 Diagnostik .....................................................................................................................................26 6.3.3 Zu empfehlende Anforderungen an die Systemlandschaft ..........................................................26 6.4 System- und Projektlandschaft des Auftraggebers ..........................................................................27 6.5 Konzeptvorschlag .............................................................................................................................28 6.6 SWOT des Konzeptvorschlages.......................................................................................................31 7 Umsetzungskonzept ..................................................................................................................................32 7.1 MPI Service Provider ........................................................................................................................32 7.1.1 Organisationsform ........................................................................................................................33 7.1.2 MPI Datenbank .............................................................................................................................33 7.1.3 Automatisierbarer Zusammenführungsmechanismus ..................................................................34 7.2 Architektur.........................................................................................................................................36 7.3 Organisatorisch.................................................................................................................................37 7.3.1 Administration MPI Service Provider ............................................................................................37 7.3.2 Register und Institutionen .............................................................................................................37 7.3.3 Datenschutz ..................................................................................................................................37 7.3.4 Etappierung ..................................................................................................................................37 07. September 2007, Version 1.2 (freigegeben)
Seite 3 von 3
7.3.5 Aufgabenteilung, Kosten und Finanzierung .................................................................................38 7.4 Technisch .........................................................................................................................................38 7.4.1 Betrieb MPI Service Provider - Webservices ...............................................................................38 7.4.2 Semantik .......................................................................................................................................39 7.4.3 Sicherheit ......................................................................................................................................39 7.5 Gegenüberstellung des Umsetzungskonzepts zum klinischen Szenario .........................................40 8 Weiteres Vorgehen....................................................................................................................................41 8.1 Bezug zur eHealth Strategie.............................................................................................................41 8.2 Roadmap ..........................................................................................................................................42 8.3 Massnahmenkatalog ........................................................................................................................42 8.4 Mögliche Umsetzung der Massnahmen ...........................................................................................43 9 Anhang ......................................................................................................................................................44 9.1 Referenzierte Dokumente.................................................................................................................44 9.2 Abkürzungen und Glossar ................................................................................................................46 9.3 Abbildungsverzeichnis ......................................................................................................................48 9.4 Tabellenverzeichnis ..........................................................................................................................48 9.5 HL7 Reference Information Model (RIM) .........................................................................................49 9.6 IHE Connectathon Resultate für das Integrationsprofil PIX .............................................................50 9.6.1 Aufbau der Tabelle .......................................................................................................................51 9.6.2 Interpretationen der Resultate ......................................................................................................51 9.6.3 Mögliche Rückschlüsse für den Kanton St. Gallen ......................................................................51 07. September 2007, Version 1.2 (freigegeben)
Seite 4 von 4
1 Management Summary
Ausgangslage
Im Rahmen der Anstrengungen im Bereich eHealth des Kantons St. Gallen sind verschiedene Projekte wie
eKOGU, MeDIswiss und PMS gestartet worden. All diese Projekte erfordern den systemübergreifenden Datenaustausch und deshalb eine Lösung für die Patientenidentifikation.
Das Grobkonzept soll sowohl in technischer, als auch organisatorischer Hinsicht aufzeigen, wie Patientenidentifikationen aus verschiedenen Unternehmen mit einem zentralen Master Patient Index (MPI) ausgetauscht werden können. Dabei ist zu berücksichtigen, dass es mehrere, hierarchisch abgestufte MPI geben
wird (Spital - Verbund - Kanton - Region - CH - international).
Grundlagen
Das Grobkonzept basiert auf existierenden und international anerkannten Standards und Definitionen:
HL7
"Health Level Seven" hat seinen Ursprung 1987 in den USA genommen. Mittlerweile
vertreibt die Organisation Standards in den Versionen 2.x (Flatfiles) und 3.0 (XML).
Gleichzeitig ist HL7.org die Dachorganisation aller HL7 Benutzer und der 27 Mitgliedsländer zu denen auch die Schweiz gehört.
IHE PIX Profil
Das Integrationsprofil „Patient Identity Cross Referencing“ beschreibt den Umgang mit
Patientenidentifikationen in grossen Gesundheitsinstitutionen auf Basis von HL7 2.x
VHitG PID Profil
Im Rahmen der VHitG Initiative „Intersektorale Kommunikation“ in Deutschland wurde
basierend auf dem PIX Profil der IHE Initiative und der HL7 Version 3 ein Konzept zur
Patientenidentifikation erarbeitet.
OID
Object Identifier sind weltweit eindeutige Kennzeichnungen für Objekte und sind in
ISO/IEC 9834/1 normiert. Dabei ist die Kombination aus der eigentlichen Identifikation
und der ausgegebenen Instanz zusammen genommen weltweit eindeutig.
Routing im Internet Netze von der Grösse des Internet erfordern spezielle Architekturen und Protokolle,
damit die Netzwerkverwaltung noch möglich ist und die Belastung der Router nicht ins
Unermessliche steigt. Deshalb wurde in den 80er-Jahren das Internet in eine Anzahl
„Autonomer Systeme“ aufgeteilt, die alle mit einem Backbone verbunden sind. Dieses
Szenario hat viele Parallelen mit der vorliegenden Patientenidentifikationsproblematik.
Eine MPI Domäne kann durchaus mit einem Autonomen System im Internet verglichen
werden.
Konzeptvorschlag
Sowohl das IHE Integrationsprofil PIX als auch das VHitG PID-Profil bilden ausgezeichnete Grundlagen für
die Umsetzung domänenübergreifender MPIs. Der Konzeptvorschlag lautet deshalb: Umsetzen des IHE
Integrationsprofil PIX und des VHitG PID Profils als Basis. Die von einem Cross Reference Manager gebildeten Cross Reference Domänen, bilden ihrerseits wieder eine Patient Identifier Domäne welche via einen
übergeordneten Cross Reference Manger zusammengefasst werden können.
Umsetzungskonzept
Im Lösungskonzept wurden sogenannte Gateways eingeführt um Patientenidentifikationen über Cross Reference Domänen hinweg auszutauschen. Diese Gateways sollen in Form von MPI Service Providern organisiert werden. MPI Service Provider sind neu zu schaffende Einheiten. Administrative Aufgabe eines MPI
Providers ist die manuelle Pflege der internen MPI Datenbank wie z.B. Freigabe von neuen Registrationen,
Zusammenführen von Duplikaten, stornieren von ungültigen Einträgen. Technische Aufgabe eines MPI Service Providers ist die Bereitstellung von Diensten, welche eine serviceorientierte Anbindung von Institutionen
oder anderen MPI Service Providern erlauben. Ziel ist es die manuellen Eingriffe im MPI Service Provider zu
minimieren. Deshalb sollen entsprechende Algorithmen für das Record Matching eingesetzt werden. Im Sinne einer Befähigung statt Behinderung führt das Umsetzungskonzept dazu, dass der Betrieb in den bestehenden Institutionen genau so weiter geführt werden kann wie es heute der Fall ist. Ergänzend können Patienten in Partnerinstitutionen auf einfache Weise manuell oder automatisiert verknüpft werden.
Weiteres Vorgehen
Der Massnahmenkatalog auf Seite 42 beinhaltet 14 Massnahmen, welche koordiniert realisiert werden sollen. Die Verfasser schlagen vor, dass die Umsetzung dieser Massnahmen in einem Realisierungskonzept
erarbeitet wird. Der parallel erstellte Voranalysebericht enthält dazu die entsprechenden Anträge.
Seite 5 von 5
2 Ausgangslage
Im Rahmen der Anstrengungen im Bereich eHealth des Kantons St. Gallen wurde medshare zur Erarbeitung
des vorliegenden Grobkonzeptes beauftragt.
Im Kanton St. Gallen sind verschiedene Projekte wie eKOGU, MeDIswiss und PMS gestartet worden. All
diese Projekte erfordern den systemübergreifenden Datenaustausch, weshalb immer wieder die Frage nach
der Patientenidentifikation aufgeworfen wird.
2.1 Zielsetzung
Das Grobkonzept soll aufzeigen, wie Patientenidentifikationen aus verschiedenen Unternehmen mit einem
zentralen Master Patient Index (MPI) ausgetauscht werden können. Dabei ist zu berücksichtigen, dass es
mehrere, hierarchisch abgestufte MPI geben wird (Spital - Verbund - Kanton - Region - CH - international).
Es werden einerseits technische Elemente gefordert, wie zum Beispiel standardisierte Schnittstellendefinitionen oder vielleicht sogar Komponenten wie z.B. Plugins für die betroffenen IT Systeme. Andererseits sind
aber auch organisatorische Elemente gefordert, welche das Handling menschlicher Aktivitäten und
Workflows rund um den Master Patient Index regeln.
Für die Realisierung der technischen Elemente sollen anerkannte Standards und Konzepte von IHE, HL7
und VHitG eingesetzt werden.
Bei positiver Bestätigung der Machbarkeit einer Patientenidentifikation für die Projekte im Kanton St. Gallen
wird angestrebt, den Lösungsansatz als bewährtes Beispiel (good practice) in das nationale Koordinationsorgan Bund-Kantone einzubringen.
2.2 Abgrenzung
Bei der Erarbeitung des Grobkonzeptes werden keine Produktevaluationen durchgeführt.
Seite 6 von 6
3 Grundlagen (Basistechnologien)
Gemäss Zielsetzung sollen anerkannte Standards und Konzepte wie IHE, HL7 und VHitG eingesetzt werden. Dieses Kapitel listet die verfügbaren Grundlagen auf, welche sich für die Umsetzung anbieten.
Quellen für nachfolgende Unterkapitel:
www.hl7.org, www.hl7.de, www.hl7.ch, www.vhitg.de, www.ihe-europe.org
3.1 HL7
"HL7" ist eine Abkürzung und steht für "Health Level Seven", was sich auf die siebte Schicht des OSI Modells bezieht. HL7 hat seinen Ursprung in den USA genommen, wo es nach einem ersten Treffen an der
Universitätsklinik in Palo Alto 1987 in seiner ersten Version entwickelt wurde. Mittlerweile hat sich eine
kommerzielle Organisation gebildet (HL7.org), die HL7 heute in den Versionen 2.x (Flatfiles) und 3.0 (XML)
vertreibt. Gleichzeitig ist HL7.org die Dachorganisation aller HL7 Benutzer und koordiniert deren Aktivitäten
auch auf internationaler Ebene. 27 Länder, darunter auch die Schweiz sind als so genannte Affiliates ebenfalls unter der Dachorganisation zusammengefasst.
Die Version 3 von HL7 ist ein XML basierter Nachrichtenstandard, der auf einem umfangreichen Objektmodell, dem Reference Information Model (RIM) aufbaut und damit die Basis für angewandte Spezifikationen
wie die Clinical Document Architecture (CDA) oder Sciphox bildet.
Abbildung 1: Geschichte von HL7
Seite 7 von 7
3.1.1 Reference Information Model (RIM)
Allen Modellen bei HL7 Version 3 liegt das so genannte Reference Information Model (RIM) zugrunde. Es
beschreibt generisch zum Beispiel einen Behandlungsprozess. Dabei wird von einer Aktivität (Act) ausgegangen, an der Entitäten (z. B. Personen) in bestimmten Rollen (Arzt, Patient, Angehöriger) teilnehmen (Participation). Aktivitäten können miteinander in Beziehung (Kontext) stehen (Act Relationship), beispielsweise
eine Laboranforderung und das daraus folgende Resultat. In der folgenden Abbildung sind die Basisklassen
des RIM wiedergegeben. Darunter sind im RIM natürlich noch Spezialisierungen der Klassen zu finden. So
ist z.B. eine Diagnose ein Sonderfall einer Beobachtung und diese wiederum eine Aktivität.
Abbildung 2: HL7 Reference Information Model (RIM)
Eine grössere Version dieser Grafik befindet sich im Anhang „9.5 HL7 Reference Information Model (RIM)“
auf Seite 49.
3.2 VHitG Initiative „Intersektorale Kommunikation“
Die Initiative wurde im Mai 2005 innerhalb des VHitG ins Leben gerufen, um den intersektoralen Austausch
von Nachrichten und strukturierten Dokumenten im medizinischen Kontext zu ermöglichen. Ziel ist, ausgewählte Behandlungsprozesse zu bearbeiten und im Sinne der integrierten Versorgung den Austausch von
Daten und Prozessinformationen sowie deren Weiterverarbeitung zwischen dem ambulanten und dem stationären Sektor zu ermöglichen. Die Ergebnisse sind frei von Lizenzen und Zertifikaten und stehen öffentlich
zur Verfügung.
An der Initiative sind 15 VHitG-Mitgliedsunternehmen aktiv beteiligt: Agfa, All for One, Cymed, DOCexpert,
fliegel data, GSD, Health-Comm, ID Berlin, InterComponentWare, iSOFT, MCS, Medos, RZV, Siemens und
Tietoenator.
Die Initiative arbeitet an folgenden Kernprojekten:
• Elektronischer Arztbrief
• Eindeutige Patientenidentifikation (PID)
• Auftrags- und Terminkoordination
Als Grundlage für das vorliegende Grobkonzept dient das Kernprojekt „Eindeutige Patientenidentifikation
(PID)“, welches im nachfolgenden Unterkapitel genauer erläutert wird.
Seite 8 von 8
3.2.1 VHitG PID Profil: Konzept zur Patientenidentifikation
Im Rahmen der VHitG-Initiative „Intersektorale Kommunikation“ wurde basierend auf dem Integrationsprofil
„Patient Identifier Cross Referencing“ (PIX) der IHE Initiative und HL7 Version 3 ein Konzept zur Patientenidentifikation (VHitG PID Profil) erarbeitet.
Dem VHitG PID Profil liegen 5 Anwendungsfälle zu Grunde:
1. Primärsysteme (KIS, Pat-Admin, …) melden neue, geänderte oder gelöschte Patientennummern
und demographische Daten an den MPI (Master Patient Index). Im MPI werden aufgrund der gemeldeten Daten Patienten neu angelegt, geändert oder storniert.
2. Primärsysteme melden Patientenzusammenführungen an den MPI, der die fehlerhaften Patientenregistrierungen entsprechend storniert.
3. Der MPI meldet neue, geänderte oder stornierte Patientennummern und demographische Daten automatisch an registrierte Systeme, die dadurch über die zusätzlichen Patientennummern informiert
werden.
4. Registrierte Systeme fragen Patientennummern und demographische Daten beim MPI ab, um beispielsweise medizinische Daten an andere Systeme mit den dort bekannten Patientennummern zu
senden.
5. Es wird dem MPI gemeldet, dass zwei Patienten fehlerhaft im MPI verlinkt wurden. Dieser Anwendungsfall kann zunächst nur durch eine organisatorische Lösung unterstützt und nicht über Transaktionen abgebildet werden.
Die Akteure und Transaktionen entsprechen weitgehend dem IHE Integrationsprofil PIX mit zwei Unterschieden:
1. Das VHitG PID Profil basiert auf HL7 Version 3
2. Die Abfrage nach einer Patientenidentifikation kann beim PID Profil auch mit demographischen Patientendaten erfolgen.
Abbildung 3: PID Akteure und Transaktionen
3.3 IHE Initiative
IHE (Integrating the Healthcare Enterprise) ist eine internationale Initiative zur Verbesserung des technischen Datenaustausches von IT-Systemen im Gesundheitswesen [1].
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. In der Schweiz hat sich leider noch keine Interessengruppe gefunden, die die IHE Initiative im schweizerischen Gesundheitswesen bekannt machen würde.
Am Anfang der IHE wurden Anwendungen aus der Radiologie beschrieben. Die Basis bildet das Integrationsprofil Scheduled Workflow. In diesem Szenario geht es um die Beschreibung des elektronischen Datenaustausches um eine radiologische Untersuchung durchführen zu können. Es beginnt mit der Beschreibung
der Patientenadministration über die Auftragserteilung an die Radiologie bis zur Befunderstellung. Später
sind nun Anwendungen aus der allgemeinen Medizininformatik, des Labors und der Kardiologie hinzugekommen.
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
Seite 9 von 9
Referenzmodell) zu fördern. Dazu wurde ein IHE Technical Framework erarbeitet, das beschreibt wie die
existierenden Kommunikationsstandards eingesetzt werden sollen um einen fehlerfreien Datenaustausch zu
ermöglichen. Im IHE Technical Framework werden in Form von Integrationsprofilen Anwendungsszenarien
beschrieben, in denen Interaktionen zwischen mehreren Computersystemen erforderlich sind.
Neben den IHE Technical Frameworks werden auch so genannte Connectathons durchgeführt. Zu diesen
Connectathons können sich Firmen anmelden, welche die Anforderungen der IHE Integrationsprofile abdecken. Um zu den Connectathons zugelassen zu werden, müssen Tests durchgeführt werden. Die IHE stellt
dafür eine 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. Am
Connectathon selber werden die Systeme der verschiedenen Firmen vernetzt und es wird getestet ob der
Datenaustausch reibungslos funktioniert. Die Resultate der Connectathons sind für jeden Interessierten im
Internet (www.ihe-europe.org) abrufbar. Diese Resultate können in Beschaffungsprojekten von Informationssystemen verwendet werden.
Abbildung 4: IHE Konzept
Die IHE hat die Technical Frameworks in einzelne Anwendungsgebiete der Gesundheitsinformatik aufgeteilt.
Momentan sind folgende Technical Frameworks öffentlich zugänglich:

Kardiologie
Ophthalmologie
IT Infrastruktur
Labor
Patient Care Koordination
Patient Care Geräte
Radioonkologie
Radiologie
Innerhalb des Technical Framework der IT Infrastruktur werden die Anwendungsgebiete der allgemeinen
Informatik beschrieben:

Cross-Enterprise Document Sharing (XDS)
Patient Identifier Cross Referencing (PIX)
Patient Demographics Query (PDQ)
Audit trail and Node Authentication (ATNA)
Consistent Time (CT)
Enterprise User Authentication (EUA)
Retrieve Information for Display (RID)
Patient Synchronized Applications (PSA)
Personal White Pages (PWP)
In den folgenden Kapiteln werden die verwendeten IHE Integrationsprofile für das Grobkonzept beschrieben.
Seite 10 von 10
3.3.1 IHE Patient Identity Cross Referencing (PIX)
Das Integrationsprofil PIX beschreibt den Umgang mit Patientenidentifikationen in grossen Gesundheitsinstitutionen. In diesen Gesundheitsinstitutionen besteht die Möglichkeit, dass ein Patient in mehreren Informationssystemen registriert wurde ohne dass ein zentrales System eine eindeutige Patientenidentifikation vergab. So kann es zum Beispiel vorkommen, dass das Informationssystem eine Patientenidentifikation vergibt
bevor die Patientenadministration den Patienten erfassen konnte. Kleinere Spitäler versuchen das zu umgehen indem erst eine Untersuchung beauftragt wird, wenn der Patient im Patientenadministrationssystem
erfasst wurde. Andere Spitäler haben ein 2. Registrationsbüro der Patientenadministration direkt bei der
Notfallpforte eingerichtet. In den meisten Fällen haben aber Informationssysteme die Möglichkeit Patienten
zu eröffnen ohne die Stammdaten der Patientenadministration abzurufen. Das Integrationsprofil PIX beschreibt wie trotz solch unterschiedlicher Patientenidentifikationen keine Behandlungsinformationen verloren
gehen. Dazu wird ein Akteur mit dem Namen „Patient Identifier Cross Reference Manager“ definiert. Mit
diesem neuen Akteur und den bestehenden Informationssystemen sollen die folgenden zwei Interaktionen
ermöglicht werden:

Registration einer neuen Patientenidentifikation: Ein Informationssystem (z.B. das LIS Laborinformationssystem oder ein KIS Krankenhausinformationssystem) hat einen Patienten neu eröffnet.
Die neu erstellten Informationen sollen beim Patient Identifier Cross Reference Manager registriert
werden damit diese Informationen auch anderen Informationssystemen zur Verfügung stehen.

Zur Verfügung stellen von Patientenidentifikationen: Der Patient Identifier Cross Reference Manager stellt die gespeicherten Identifikationen zur Verfügung. Diese Identifikationen können über eine Abfrage oder durch eine Aktualisierung zur Verfügung stehen.
Abbildung 5: Patient Identification Cross Reference Domain
Um das Integrationsprofil PIX erfolgreich umsetzen zu können, müssen die beiden Domänen folgende Eigenschaften aufweisen:
Patient Identifier Domain (PID Domain)
Es gibt nur einen Akteur, der Patientenidentifikationen erzeugt.
Es gibt eine Administration, die die Berechtigung hat mit Hilfe des Akteurs Patientenidentifikationen
zu erstellen.
Es gibt Richtlinien wie die Administration Patientenidentifikationen vergibt.
Es sollte darauf geachtet werden, dass dem gleichen Patienten möglichst nur eine Patientenidentifikation zugeteilt wird.
Die Patient Identifier Domains sollten so gekapselt werden, dass es keine Überschneidungen mit
anderen Domänen gibt.
Akteure innerhalb einer Domäne sollten für die interne Kommunikation sich immer auf die Domain
interne Patientenidentifikation beziehen.
Seite 11 von 11
Patient Identifier Cross Reference Domain (PID CR Domain)
Es bestehen Richtlinien, die beschreiben wie Patientenidentifikationen domänenübergreifend identifiziert werden.
Es bestehen Prozesse, die beschreiben wie diese Richtlinien verwaltet werden.
Es besteht eine klare Verantwortlichkeit für die Prozesse und Richtlinien.
Die detailierten Spezifikationen können hier heruntergeladen werden:
http://www.ihe.net/Technical_Framework/index.cfm#IT
Resultate der Connectathons der letzten Jahre bezüglich PIX können Anhang „9.6 IHE Connectathon Resultate für das Integrationsprofil PIX“ auf Seite 50 entnommen werden.
3.3.2 Beziehung zwischen dem IHE Integrationsprofil PIX und der Verwaltung eines MPI
Im Grundsatz wurde das IHE Integrationsprofil PIX mit dem Fokus der Verwaltung von unterschiedlichen
Patientenidentifikationen innerhalb eines Instituts oder von zwei Instituten beschrieben. Die Anwendung des
IHE Integrationsprofils PIX für einen MPI ist eine spezifische Anwendung in Verbindung mit mehreren Instituten. Dazu beschreibt das Technical Framework zwei mögliche Ansätze.
Abbildung 6: PIX Integrationsprofil in Beziehung zu einem MPI
Einerseits werden die einzelnen Identifikationsdomänen in einer Domäne zusammengefasst, die eine Verwaltung eines MPI ermöglicht. Diese Informationen werden an den Patient Identitiy Cross Reference Manager weitergleitet. Andererseits können unabhängige Identifikationsdomänen definiert werden, die über einen
Cross Reference Manager verbunden werden. Eine der so verbunden Domänen übernimmt die Aufgabe der
Verwaltung eines MPI. In beiden Varianten ist der Cross Reference Manager ausserhalb der einzelnen Identifikationsdomänen.
3.3.3 IHE Consistent Time (CT)
Falls man das IHE Integrationsprofil PIX in der Praxis umsetzen möchte, wird man relativ schnell zeitliche
Abhängigkeiten feststellen. Wenn man bedenkt wie häufig in einem Spital mittlerer Grösse ein neuer Patient
erfasst oder seine Daten verändert werden, so wird einem schnell bewusst, dass beim Cross Reference
Manager sehr viele Nachrichten in kürzester Zeit eintreffen werden. Mit dem IHE Integrationsprofil Consistent Time wird eine mögliche technische Umsetzung beschrieben, wie alle beteiligten Applikationen mit
der gleichen Zeit synchronisiert werden.
Zur Synchronisation der verschiedenen Akteure innerhalb einer Anwendung verwendet das IHE Integrationsprofils CT das Network Time Protokoll (NTP) welches im RFC 1305 definiert ist. Dazu wird im Verbund
von verschiedenen Akteuren ein Time Server platziert, bei dem die Akteure via NTP die Zeit synchronisieren
können.
Seite 12 von 12
3.3.4 IHE Audit Trail and Node Authentication (ATNA)
Wie es der Name schon sagt, geht es in diesem Integrationsprofil darum, die technischen Möglichkeiten so
zu nutzen, dass ein Datenschutzmonitor und eine einheitliche Zugriffskontrolle realisiert werden kann.
Damit können folgende Ziele adressiert werden:
•
Benutzerverantwortung: Mit dem Intergrationsprofil ATNA soll einem Datenschutzbeauftragten die
technische Möglichkeit geschaffen werden, die Umsetzung der Datenschutzrichtlinien zu überprüfen.
•
Zugriffskontrolle: Welche Arbeitsstation hat Zugriff?
•
Zentrales Monitoring: Alle Informationen bezüglich eines Zugriffs- oder einer Zugriffsverweigerung,
werden zentral aufgezeichnet.
•
Nachverfolgung der Patientendaten (PHI*): Von wem und wann wurden die Patientendaten erstellt?
Von wem und wann wurden Daten verändert? Von wem und wann wurden Daten gelöscht oder verschoben?
*Mit PHI (Protected Health Information) werden die Behandlungsdaten eines Patienten bezeichnet.
Um diese 4 Ziele zu erreichen werden im Integrationsprofil ATNA 3 Hauptfunktionen beschrieben:
•
Benutzeridentifizierung: Die eindeutige Benutzeridentifizierung wird von ATNA nicht beschrieben. Es
können dafür zentrale Techniken verwendet werden wie zum Beispiel LDAP (Lightweight Directory
Access Protocol). Die Benutzeridentifikation wird von der IHE im Integrationsprofile EUA (Enterprise
User Authentication, Seite 24 im Dokument [3]) beschrieben.
•
Aufzeichnung von Zugriffen: Das Integrationsprofil verlangt, dass jeder Zugriff auf eine Patienteninformation an einer zentralen Stelle von den jeweiligen Informationssystemen gemeldet wird. Damit
soll die Möglichkeit des zentralen Monitoring geschaffen werden.
•
Identifizierung der Arbeitsstation während eines Datentransfers: Das Integrationsprofil verlangt, dass
sich jede Arbeitsstation identifizieren muss bevor Patientendaten ausgetauscht werden können.
Seite 13 von 13
3.4 Object Identifier (OID)
Beim standardisierten Austausch von Informationen mittels Nachrichten oder Dokumenten geht es auch um
die eindeutige Bezeichnung und Benennung von Objekten und Konzepten. Dies gilt insbesondere bei der
sektorenübergreifenden Kommunikation, in der Sender und Empfänger sich nicht notwendigerweise „kennen“.
Wichtig ist dabei der Unterschied zwischen Identifikationen (IDs) und Codierungen. Eine ID deutet auf eine
Instanz eines Objektes hin, z. B. eine bestimmte Person wie Patient oder Arzt, eine konkrete Laboruntersuchung oder ein Röntgenbild. Eine Codierung hingegen deutet ein Konzept an: Typ des Patienten (z. B. ambulant), Typ des Arztes (z. B. Anästhesist), Typ der Laboruntersuchung (z. B. kleines Blutbild). Bei der Codierung geht es nicht um ein bestimmtes Objekt.
OID sind weltweit eindeutige Kennzeichnungen für Objekte und sind in ISO/IEC 9834/1 normiert. Objekte
sind persistente, wohldefinierte Informationen, Definitionen oder Spezifikationen und werden als Identifikationen (IDs) und Codierungen wiedergegeben.
Abbildung 7: OID Struktur
Nachrichten und Dokumente wie sie zum Beispiel im HL7 V3 Standard definiert sind, nutzen OID um Codierungsschemas und Identifikationsbereiche zu bezeichnen. Dabei wird die Idee verfolgt, dass jede Identifikation bzw. jedes Codierungsschemas Teil des Systems ist, in dem sie definiert wurde. Beispiele sind Patientennummern, die innerhalb eines Krankenhauses ausgegeben werden oder Labor Codes für Untersuchungen als LOINC Codes.
Dabei ist die Kombination aus der eigentlichen Identifikation (Extension) und der ausgegebenen Instanz
(Root OID) zusammen genommen weltweit eindeutig.
OID können von jeder Organisation ausgegeben werden, indem Sie eine eindeutige Wurzel OID verwenden.
Eine Nachricht oder ein Dokument kann OID aus verschiedenen Quellen nutzen, ein einzelnes Schema
kann auch durch mehr als eine OID gekennzeichnet sein (d. h. eine OID von mehr als einer Organisation).
Einmal zugewiesen, wird eine OID niemals zurückgenommen und bleibt ein gültiger Bezeichner für dasselbe
Schema oder Objekt.
Weitere Informationen über HL7 und OID sind auf www.hl7.org/oid oder
www.ringholm.de/docs/00900_en.htm abrufbar (zuletzt besucht am 15.08.2007).
Seite 14 von 14
3.4.1 Beispiel Patientenidentifikation
In den bereits von der ISO anerkannten Datentypen, die innerhalb von HL7 definiert sind, geben so genannte Instance Identifier (II) in der Root OID die ausgebende Instanz/Organisation an, der eigentliche Bezeichner wird im Extension Attribut untergebracht.
Beispiel:
2.16.840.1.113883.2.4.6.2.5432.1 ist die Root OID der Organisation, in welcher der Patient mit der Nummer
67543242 registriert ist. Die Patientennummer wird als Extension der entsprechenden OID Root deklariert.
Damit kann der Stammdatensatz dieses Patienten weltweit eindeutig identifiziert werden.
Eine entsprechende XML Repräsentation ist:
<id extension="67543242" root="2.16.840.1.113883.2.4.6.2.5432.1"/>
Tabelle 1: OID Beispiel Patientenidentifikation
3.4.2 Beispiel Diagnose
Beim Datentyp Concept Descriptor (CD) wird das Codiersystem ebenfalls durch eine OID angegeben, die
tatsächliche Codierung im Code Attribut. Damit kann jeder Code jedes Codesystems – also z.B. auch ICPC
oder der Tessinercode – weltweit eindeutig identifiziert werden.
Beispiel:
2.16.840.1.113883.6.3 ist die OID für das Codiersystem ICD10.
Die Diagnose „Appendizitis“ hat den ICD 10 Code I59.13.
Eine entsprechende XML Repräsentation ist:
<value code="I59.13" codeSystem="2.16.840.1.113883.6.3"/>
Tabelle 2: OID Beispiel Diagnose
3.4.3 HL7 OID in der Schweiz
Die Wurzel OID für HL7 Schweiz lautet:
2.16.840.1.113883.2.5
Tabelle 3: OID Root für HL7 Schweiz
Die HL7 Benutzergruppe Schweiz verfügt über eine Root OID. Die HL7 Benutzergruppe Schweiz verwaltet
die darunterliegenden OIDs selbst und gibt auf Anfrage auch neue OIDs innerhalb der eigenen Domäne
heraus. Weitere OID Registrationsstellen existieren in der Schweiz nicht.
3.5 Routing im Internet
Aufgrund der historisch gewachsenen MPI Domains, welche nun den Drang zur Vernetzung verspüren liegt
der Vergleich mit der Entstehung des Internet nahe, das eigentlich aus derselben Motivation heraus entstanden ist. Aus diesem Grund wird hier ganz kurz aufgezeigt, wie und warum das Internet funktioniert.
Netze von der Grösse des Internet erfordern spezielle Architekturen und Protokolle. Ansonsten würde die
Belastung der Router ins Unermessliche wachsen. Zudem wird die Netzwerkverwaltung immer komplizierter,
je mehr verschiedene Systeme und Software im Netz verwendet werden. Deshalb wurde in den 80er-Jahren
das Internet in eine Anzahl „Autonomer Systeme“ aufgeteilt, die alle mit einem Backbone verbunden sind.
Definition „Autonomes System“ gemäss Wikipedia:
Ein Autonomes System (AS) ist eine Ansammlung von IP-Netzen, welche als Einheit verwaltet werden und
über ein gemeinsames (oder auch mehrere) internes Routing-Protokoll (IGPs) verbunden sind. Dieses Netz
wiederum kann sich aus Teilnetzen zusammensetzen. Ein AS steht unter einer gemeinsamen administrativen Verwaltung, typischerweise von einem Internet Service Provider (ISP), einer internationalen Firma oder
einer Universität. Autonome Systeme sind untereinander verbunden und bilden so das Internet.
Seite 15 von 15
Abbildung 8: Hybrides hierarchisches Feld-Relais-Internetwork (Quelle: www.cisco.com)
Ausgehend vom Routing, ist das Internet in zwei Hierarchien gegliedert: Domains, die eine eigene interne
Routing-Architektur aufweisen (und jeweils unterschiedliche Routing-Protokolle verwenden können) und
autonome Systeme, die eine homogene Routing-Architektur für das Routing zwischen autonomen Systemen
ermöglichen. Domains verwenden ein Routing-Protokoll, das speziell an die Anforderungen für das interne
Routing angepasst ist. Es existieren verschiedene Protokolle für solche Anwendungen, die als Interior Gateway Protocols (IGP) zusammengefasst werden. Sie verwalten eine vollständige Topologie ihrer RoutingDomain und sind in der Lage, optimale Pfade zwischen zwei Punkten innerhalb der Domain zu errechnen.
Zwar ist diese Technik auch für sehr grosse Domains geeignet, allerdings übersteigt die Dimension des Internets die Fähigkeiten solcher Protokolle, so dass für das Routing zwischen autonomen Systemen andere
Technologien zum Einsatz kommen. Bekannte Vertreter der IGPs sind beispielsweise OSPF (Open Shortest
Path First) und IS-IS (Intermediate System to Intermediate System).
Routing zwischen autonomen Systemen wird als Inter-Domain Routing bezeichnet und beschreibt, wie zwischen Domains geroutet werden kann, ohne jedoch Pfade durch autonome Systeme festzulegen. Ein Pfad
zwischen Domains wird durch die Kennungen aller Domains definiert, die zu durchqueren sind, um die ZielDomain mit dem entsprechenden Adresspräfix zu erreichen. Diese Funktionalität übernimmt das in der Version 4 vorliegende Border Gateway Protocol (BGP).
Abbildung 9: Routing zwischen autonomen Systemen (Quelle: www.cisco.com)
Seite 16 von 16
4 Alternative Grundlagen
4.1 ISO/TC 215
Das Technische Komitee 251 (Health Care) des ISO Standardisierungskomitees arbeitet in mehreren Working Groups an verschiedenen Themen:
TC 215/CAG 1 Executive council, harmonization and operations
TC 215/WG 1 Data structure
TC 215/WG 2 Data interchange
TC 215/WG 3 Semantic content
TC 215/WG 4 Security
TC 215/WG 5 Health cards
TC 215/WG 6 Pharmacy and medicines business
TC 215/WG 7 Devices
TC 215/WG 8 Business requirements for Electronic Health Records
ISO Normen sind kostenpflichtig. Die Verfasser verfügen über keine publizierten ISO Normen.
4.2 CEN/TC 251
Das Europäische Komitee für Normung CEN (Comité Européen de Normalisation) ist eine der drei grossen
europäischen technischen Normungsinstitutionen. 30 Nationen sind Mitglieder, alle EU-Staaten und weitere
Europäische Staaten, darunter auch die Schweiz. Das TC 251 behandelt seit den frühen 90er Jahren den
Bereich Medizinische Informatik. Ein Schwerpunkt der Arbeit des „Technical Comitees“ liegt in der Entwicklung von Kommunikationsstandards zwischen medizinischen Informationssystemen.
WG I „Informationsmodelle“
Behandelt die Nutzerbelange bezüglich der Informationsinhalte, die in den verschiedenen Bereichen übermittelt werden müssen. Die Architektur einer elektronischen Patientenakte steht dabei im Mittelpunkt, ergänzt um eine Zahl von spezi schen Nachrichtenmodellen einschliesslich Patientenkarten.
WG II „Konzepte und Terminologie“
De niert Grundregeln zur Errichtung von Konzeptsystemen für Informationssysteme und kooperiert mit bestehenden Expertengruppen für Medizinische Terminologie.
WG III „Sicherheit“
Erarbeitet Leitlinien zum Management des Schutzes der Vertraulichkeit, Integrität, Verfügbarkeit und Verbindlichkeit, liefert detaillierte Vorgaben zum Schutz von Kommunikation, aber auch zur Gewährleistung von
Sicherheit (Savety) und Qualität.
WG IV „Technologie für interoperable Kommunikation“
Beschäftigt sich mit der Standardisierung der Übertragung von EKGs und multimedialer Inhalte, die spezielle
Techniken und Middleware-Konzepte benötigen.
1
Zusammenlegung mit HL7
Im Jahr 2000, insbesondere ausgelöst durch die Gründung der HL7 Gruppe in Grossbritannien wurde zwar
nicht wörtlich formuliert, aber praktisch beschlossen, zukünftige Entwicklungen im Rahmen von HL7 Version
3 durchzuführen. Faktisch wurde damit beschlossen, auf CEN eigene Entwicklungen auf den Gebieten der
Modellierung von Gesundheitsinformationssystemen und der Ableitung von Nachrichten und Strukturen für
Kommunikation und Interoperabilität zukünftig zu verzichten, auch wenn das in den Resolutionen nicht direkt
zu erkennen ist.
Recherchen im Internet zeigen, dass seit dem Jahr 2000 vom CEN/TC 251 keine nennenswerten Publikationen mehr erfolgt sind.
1
Quelle: http://www.hl7.de/hl7ugde/hl7mitteilungen/hl7m062000.pdf, zuletzt besucht am 15.08.2007
Seite 17 von 17
4.3 Schweizerische Normenvereinigung (SNV)
Das schweizerische Normenkomitee [NK 165] unter der Leitung von Florian Mitscherlich kümmert sich um IT
und Qualität im Gesundheitswesen. Darunter fallen Normung von Techniken, Methoden und Terminologien
im Bereich der medizinischen Informatikanwendungen.
Das Komitee lehnt sich an die Standardisierungskomitees ISO/TC 251 und CEN/TC251 an und ist unterteilt
in folgende Unterkomitees:
UK 01 Patienten- Gesundheitskarte
UK 02 Übertragungsprotokolle Kommunikation
UK 03 Patientennummer
UK 04 Digitales Patientendossier
UK 05 Notfallprotokoll für das Rettungswesen
UK 06 Recht Sicherheit Datenschutz
UK 07 HMO-Praxen Netzwerke Einzelpraxen
Auf der aktuellen Webseite des Komitees ist folgende Information zu finden:
„Kein Bericht verfügbar / aucun rapport des travaux disponible / no report available“
Diese Tatsache macht deutlich, dass nach der faktischen Stilllegung des CEN/TC 251 auch das Spiegelgremium in der Schweiz ihre Tätigkeit eingestellt hat.
Seite 18 von 18
5 Blick ins benachbarte Ausland
Der Blick ins benachbarte Ausland zeigt, dass alle umliegenden Länder eine HL7 Benutzergruppe haben.
Deutschland, Frankreich und Italien verfügen gar über eigene IHE Vereinigungen, welche unter einer europäischen Dachorganisation zusammengefasst sind.
Es ist eindeutig feststellbar, dass die herkömmlichen Standardisierungsorganisationen wie CEN und ISO
den Durchbruch bei der Standardisierung der elektronischen Datenübertragungen im Gesundheitswesen
nicht geschafft haben. Sämtliche umliegenden Länder verfolgen Standards auf Basis HL7 und den Integrationsprofilen der IHE. In den meisten Ländern sind darum Interessengemeinschaften entstanden um die IHE
Integrationsprofilen an die jeweiligen länderspezifischen Anforderungen anzupassen.
5.1 Deutschland
Deutschland setzt zurzeit eines der weltweit grössten IT Projekte im Gesundheitswesen um. An dessen Ende steht eine flächendeckende Healthcare Telematik Plattform. Diese wird in Zukunft Ärzte, Krankenhäuser,
Apotheken und Kassen miteinander vernetzen.
An dem Projekt „prospeGKT“ sollen kurzfristig bis zu 20`000 Versicherte, 75 niedergelassene Ärzte sowie
ein Krankenhaus teilnehmen. Ihr gemeinsames Ziel: bereits heute die vom Gesetzgeber in Deutschland
geforderte elektronische Gesundheitskarte in Verbindung mit dem elektronischen Rezept und vor allem die
elektronische Patientenakte einzuführen und zu testen.
Mit der integrierten Versorgung und einer vernetzten Infrastruktur im Gesundheitswesen rückt zwangsläufig
das Thema der Homogenisierung von verschiedenen Patienten IDs in den Vordergrund. Auch wenn in
Deutschland mit der eGK-Einführung ein eindeutiger Identifikationsschlüssel vorgesehen ist, so werden bestehende Anwendungen (Primärsysteme) zunächst mit bisherigen Identifikationen arbeiten müssen. Ferner
müssen Archivdaten und die Einbeziehung von Patienten, die nicht in nationalen Gesundheitsstrukturen
erfasst sind, beachtet werden. Dafür ist ein Master Patient Index (MPI als übergeordnete Pat. ID) erforderlich. Da Deutschland unter der Federführung des Verbands der Hersteller von IT Lösungen für das Gesundheitswesen (VHitG) sehr stark auf HL7 und IHE ausgerichtet ist, ist zu erwarten, dass die Umsetzung des
MPI mit dem VHitG PID Profil realisiert wird.
5.2 Österreich
Im Rahmen einer Machbarkeitsstudie betreffend Einführung der elektronischen Gesundheitsakte (ELGA) im
österreichischen Gesundheitswesen werden sehr ähnliche Resultate dokumentiert. Als Empfehlung wird der
Einsatz von HL7 CDA und IHE XDS angegeben:
Abbildung 10: Empfehlung für ELGA (Österreich)
Gemäss Aussage von T-Systems, welche im Projekt NÖMED WAN (Niederösterreichisches Gesundheitsnetz) federführend ist, soll bis im Herbst 2007 eine MPI Definition auf Basis des IHE PIX Profils verfügbar
sein.
Weitere Informationen: www.arge-elga.at
Seite 19 von 19
5.3 Frankreich
In Frankreich ist die Standardisierungsorganisation HPRIM (Harmonie et PRomotion de l'Informatique Médicale) gleichzeitig das internationale HL7 Affiliate. Frankreich setzt sehr stark auf IHE und damit auch auf
HL7. So ist z.B. der französische „Guide d’implémentation du Volet Médical au format CDA Release 2 –
Niveau 3“ als Grundlage in den deutschen [VHitG Arztbrief] eingeflossen.
Weitere Informationen: www.hprim.org
Frankreich beheimatet ausserdem mit Eric Poiseau den IHE European Technical Manager. Rund um Eric
Poiseau arbeitet ein ganzes Team am Campus universitaire de beaulieu in Rennes Cedex an der IHE Initiative. So wird unter anderem die Webseite der IHE Europe an der Uni Rennes gehostet.
Weitere Informationen: http://www.univ-rennes1.fr; http://ihe.univ-rennes1.fr
5.4 Italien
Italien setzt wie Frankreich auf die IHE Initiative und damit auch auf HL7.
Marzio Della Santa, Projektleiter Rete Sanitaria im Kanton Tessin hat für uns die italienisch sprachigen
Webseiten recherchiert. Hier seine Zusammenfassung:
• Wenn wir uns auf die allgemein verfügbaren Informationen beziehen, wagen wir die Behauptung, HL7
sei der Referenzstandard in Italien. Allerdings konnten auf Staatsebene keine klaren Richtlinien bezüglich Referenzstandard gefunden werden.
• Die Publikationen auf den Webseiten in Italien etwas veraltet (die Webseite der IHE Italien wurde zuletzt
im Jahr 2004 aktualisiert).
• Auf der Webseite von HL7 Italien konnte keine Auflistung der – auf HL7 basierenden – Projekte oder
Initiativen gefunden werden
Massimo Mangia, Präsident der HL7 Benutzergruppe Italien beurteilt die Situation zusammengefasst folgendermassen:
• HL7 V2.3 – V2.5 ist in den Spitälern recht gut verbreitet. Die Hersteller haben in den vergangenen zwei
Jahren ihre Produkte dahingehend angepasst, dass sie diesen Standard unterstützen. Insbesondere in
den Pilotregionen wie z.B. der Lombardei wurden grosse Anstrengungen zur Vernetzung der Systeme
unternommen.
• Aktuell erarbeiten acht Regionen zusammen detaillierte Spezifikationen auf der Basis von HL7 V3 und
CDA (Lazio, Campania, Abruzzo, Molise, Puglia, Sardegna, Sicilia, Calabria).
• Andere Regionen arbeiten derzeit in EPR Projekten, welche auf der Basis von HL7 V2.5 aufbauen (z.B.
Emilia Romagna für das Projekt SOLE)
• Der runde Tisch „Sanità Elettronica“, welchem die Regionen, die unabhängigen Provinzen und das Gesundheitsministerium (welches die Aktivitäten koordiniert) angehören, hat HL7 V3 und CDA als Grundlage für den „Fascicolo Sanitario Elettronico“ (entspricht dem EPR) festgelegt.
• Eine Arbeitsgruppe des Gesundheitsministeriums „Mattoni NSIS“ hat eine Empfehlung zum Einsatz von
HL7 V3/CDA für „neue“ EPR abgegeben.
• Das italienische IHE Komitee arbeitet an den runden Tischen und Arbeitsgruppen eng mit der HL7 benutzergruppe zusammen. Die IHE Profile basieren hauptsächlich auf dem HL7 Standard.
• Was CEN TC 251 und ISO TC 215 anbelangt, kann festgehalten werden, dass diese derzeit in Italien
nicht berücksichtigt werden.
Weitere Informationen: www.hl7italia.it; http://www.rad.unipd.it/ihe/index.html
Seite 20 von 20
5.5 Kanada
Kanada ist zwar kein benachbartes Land der Schweiz. Es lohnt sich aber trotzdem einen Blick nach Kanada
zu werfen. Kanada hat ähnliche politische Strukturen wie die Schweiz. Ausserdem ist es ebenfalls mehrsprachig und setzt seit Jahren auf den HL7 Standard. Kanada verfolgt mit dem e-MS Projekt ähnliche Ziele,
wie sie in der schweizerischen [eHealth Strategie] formuliert sind.
Abbildung 11: e-MS Kanada
e-MS steht für electronic Medical Summary. Diese Zusammenfassung ist eine Teilmenge von Informationen zu einem Patienten, die für Kommunikation unter den medizinischen Leistungserbringern – welche sich
in irgendeiner Form um den Gesundheitszustand eines Patienten kümmern – optimiert ist.
Zusammen mit EMR Verkäufern, technischen Experten und der HL7 Benutzergruppe Kanada wurden in der
Phase 2 zwei Spezifikationen produziert, welche die plattformunabhängige Integration und Interoperabilität
unter verschiedenen EMR Systemen unterstützen:
•
•
e-MS CDA Implementation Guide (e-MSIG)
e-MS Exchange Protocol (e-MSEP)
Im Master Projektplan aus dem Jahr 2005 wird das Health Client Identity Management (HCIM) als Massnahme aufgegriffen. Diese Initiative versucht innerhalb und übergreifend über die Gesundheitsämter eine
genaue, gleichbleibende und eindeutige Kennzeichnung der Klienten (Patienten) mittels Enterprise Master
Patient Index (EMPI) zur Verfügung zu stellen. Dadurch sollen regionale und Kanadaweite EHR gestützt
werden. Ziel dieses Projektes ist es, in Zukunft e-MS mit einem Klienten Verzeichnis auszustatten und mit
relevanten Registern und Datenquellen zu verknüpfen.
Von den Arbeiten, welche in Kanada bereits gemacht wurden, können wir in der Schweiz sehr stark profitieren. Ein Augenschein vor Ort in Kanada würde zahlreiche, für die Schweiz offene Fragen beantworten oder
zumindest eine Richtung für den Lösungsweg aufzeigen.
Weitere Informationen: www.e-ms.ca
Seite 21 von 21
6 Lösungskonzept
6.1 Klinisches Szenario
Herr Alfons Müller wurde erst kürzlich pensioniert. Er lebt mit seiner Frau in einer Mietwohnung in einem
Mehrfamilienhaus in Herisau im 3. Stock. Als er an diesem Morgen die Zeitung aus seinem Briefkasten holen möchte, stürzt er im Treppenhaus und schlägt mit dem Hinterkopf auf einen Treppenabsatz auf. Unglücklicherweise ist seine Frau schon aus dem Haus gegangen um Besorgungen zu erledigen. Eine Nachbarin
findet Alfons Müller im Treppenhaus und alarmiert den Notruf. Als die Sanität nach ca. 15 Minuten eintrifft, ist
Herr Alfons Müller ansprechbar, steht aber unter ziemlichem Schock und ist entsprechend verwirrt. Die
Nachbarin teilt der Sanität mit, dass es sich um Herr Alfons Müller aus dem 3. Stock handelt und dass er erst
kürzlich pensioniert wurde. Was genau passiert ist, kann die Nachbarin leider nicht mitteilen. Die Sanität
bringt Herr Müller zur Notfallaufnahme des Spitals Herisau. Die Sanität wartet die ersten Untersuchungen
ab, da bei einer Kopfverletzung Herr Müller ins Kantonsspital St. Gallen verlegt werden müsste. Da Herr
Müller immer wieder über starke Kopfschmerzen klagt und das Röntgenbild keinen eindeutigen Befund ergibt, wird Herrn Müller ins Kantonsspital St. Gallen überführt. Das Röntgenbild des Schädels wird auf einer
CD mitgegeben. Auf der 20 Minuten dauernden Fahrt bereitet der Rettungssanitäter das Übergabeprotokoll
vor und überprüft den Puls, den Blutdruck und die Körpertemperatur von Herrn Müller. An der ZNA (Zentrale
Notfall Annahme) übergibt der Rettungssanitäter den Patienten mit folgenden Daten:
Patient:
Alfons Müller
Mitteldorfstrasse 6, 3. Stock
9100 Herisau
verheiratet, Ehepartner konnte nicht kontaktiert werden
Laut Aussage der Nachbarin wurde Herr Müller erst kürzlich pensioniert.
Ereignis:
1. Befund:
Vitalwerte:
Sturz im Treppenhaus
Patient klagt über starke Kopfschmerzen
Puls = 96, Blutdruck = 156/104,
Körpertemperatur = 36,4°C
Bei der Anamnese kann nicht festgestellt werden was genau passiert ist. Zudem verliert Herr Alfons Müller
kurzzeitig das Bewusstsein. Die Polizei Herisau wird informiert um Frau Müller ins Spital zu bringen. Falls
Herr Müller Medikamente einnimmt solle Frau Müller diese bitte gleich mitbringen.
Herrn Müller wird Blut genommen um das Kreatinin und den Blutzucker im Labor überprüfen zu lassen.
Gleichzeitig wird Herr Müller für ein Schädel-CT in der Radiologie angemeldet. Während Herr Alfons Müller
im CT untersucht wird, trifft Frau Müller im Notfall ein, wo sie über die Situation ihres Mannes informiert wird.
Frau Müller liefert der Patientenadministration die genauen Personalien und hat 2 Medikamente mitgebracht.
Das 1. Medikament hilft gegen den erhöhten Blutdruck und das 2. Medikament sei gegen eine Allergie, die
aber von Frau Müller nicht genauer beschrieben werden kann. Die Allergie sei vom Hausarzt diagnostiziert
worden. Herr Dr. E. Zurbuchen aus Herisau sei der Hausarzt.
In der Radiologie kann eine 2 cm lange Fraktur des Schädelknochens festgestellt werden. Daraufhin wird
eine MRI-Untersuchung angeordnet um den Schädel auf Blutungen zu untersuchen. Diese Untersuchung
zeigt, dass keine nennenswerten Blutungen auftraten. Der auf dem Notfall diensthabende Oberarzt der Chirurgie beschliesst nach Absprache mit dem Neurochirurgen auf einen Eingriff zu verzichten. Er verschreibt
Herrn Müller Schmerzmedikamente und lässt ihn zur Überwachung auf die Bettenstation verlegen.
Am nächsten Tag wird eine weitere MRI-Untersuchung durchgeführt, die erneut keine nennenswerten Blutungen zeigt.
Am dritten Tag lassen die Kopfschmerzen nach und nach einer erneuten MRI-Untersuchung wird Herr Müller
mit einem Austrittsbericht für den Hausarzt nach Hause entlassen.
6.2 Business Use Cases
Basierend auf dem klinischen Szenario können einzelne Business Use Cases definiert werden. Innerhalb
dieser Business Use Cases wird beschrieben welcher Bezug zur Patientenidentifikation besteht. Dabei werden die Patientenanmeldung und der Abschluss einer Behandlung etwas detaillierter beschrieben.
Seite 22 von 22
6.2.1 Anmeldung einer Untersuchung
Ein Zuweiser meldet einen Patienten zur Untersuchung in einem Spital oder einem Institut an. Es kann aber
auch eine Anmeldung zu einer Laboruntersuchung sein oder zu einer psychologischen Abklärung.
Abbildung 12: Anmeldung einer Untersuchung
Im beschriebenen klinischen Szenario würde der Rettungsdienst als Zuweiser den Patienten im Kantonsspital St. Gallen anmelden. Die ZNA würde die ersten Daten als Administration (Admin) eröffnen. Eine Terminierung mit dem Patienten entfällt im Fall eines Notfalls. Dieser Anwendungsfall kann mit verschiedenen
Akteuren versehen werden. Hier ein paar Beispiele:
Ein Hausarzt (Zuweiser) meldet einen Patienten (Patient) zur orthopädischen Sprechstunde in einem
Spital an. Das Sekretariat der Orthopädie (Admin) koordiniert den Termin der Sprechstunde mit dem
Patienten.
Ein Spital A (Zuweiser) meldet einen Patienten (Patient) zu einer MRI Untersuchung im Spital B an,
da es selbst nicht über ein MRI verfügt. Die Radiologie Anmeldung des Spitals B koordiniert den Untersuchungstermin mit dem Patienten.
Ein Spital A (Zuweiser) meldet einen Patienten (Patient) zu einer Untersuchung im Spital B an, da es
die Untersuchung nicht selbst durchführen kann. Da der Patient nicht gehfähig ist, muss er mit dem
Rettungsdienst zur Untersuchung gebracht werden. Das Sekretariat (Admin) des Spitals B koordiniert den Untersuchungstermin mit dem Sekretariat des Spitals A (Stellvertreter Patient). Das Sekretariat des Spitals A koordiniert den Transport des Patienten mit dem Rettungsdienst.
Ein Hausarzt oder ein Spital (Zuweiser) liefert eine Blutprobe (Patient) ans Labor zur Analyse. Das
Sekretariat des Labors (Admin) terminiert die Analyse.
Ein Patient (Zuweiser) meldet sich (Patient) beim Hausarzt für die Abklärung eines Leidens. Die
Arztgehilfin (Admin) koordiniert den Termin mit dem Patienten.
In jedem dieser Beispiele ist der Zuweiser verpflichtet den Patienten eindeutig zu identifizieren. Diese Informationen werden danach verwendet um den Untersuch zu erfassen mit den eigenen Stammdaten der Patientenadministration. Der Patient muss eindeutig identifiziert werden, so dass beim Durchführen der Untersuchung der Patient der Untersuchung eindeutig zugeordnet werden kann.
Seite 23 von 23
6.2.2 Abklärung der Kostengutsprache
Jedes Institut, das eine Behandlung durchführt, klärt in der Regel zuerst ab, ob die Behandlung durch einen
Kostenträger gedeckt ist. Dazu wird vom behandelnden Institut bei der Versicherung oder bei den kantonalen Behörden eine Anfrage zur Kostengutsprache gestellt.
Abbildung 13: Anfrage einer Kostengutsprache bei z.B. einer Versicherung
In diesem Business Use Case muss die anfragende Stelle in der Lage sein, mindestens zwei verschiedene
Patientenidentifikationen zu verwalten. Es muss die selbst erstellte Patientenidentifikation mit der Patientenidentifikation der Versicherung oder der kantonalen Behörden verknüpfen. Dabei ist zu berücksichtigen, dass
bei ambulanten Patienten verschiedene Versicherungsmodelle (keine interkantonale oder sogar internationale Abdeckung) existieren oder bei stationären Patienten die entsprechende kantonale Behörde kontaktiert
werden muss.
6.2.3 Auskunft zum Krankheitsverlauf
Der behandelnde Health Professional benötigt zusätzliche Informationen zum Krankheitsverlauf eines Patienten. Als Beispiel kann der behandelnde Arzt der Notfallaufnahme des klinischen Szenarios beim Hausarzt
von Herr Müller anrufen, um die erwähnte Allergie abzuklären.
Abbildung 14: Auskunft Krankheitsverlauf
Dieser Business Use Case funktioniert für den Fall, dass ein zuweisender Arzt Fragen zu einer Behandlung
oder einem Austrittsbericht hat auch in umgekehrter Richtung.
Heute erfolgen solche Auskünfte in der Regel via Telefon, wobei der Patient der Auskunftsstelle mittels Name und Geburtsdatum bekannt gemacht wird. Wenn nun diese Abfrage elektronisch erfolgen soll, reicht die
Identifikation des Patienten mittels Name und Geburtsdatum nicht mehr aus.
Seite 24 von 24
6.2.4 Behandlung eines Patienten abschliessen
Abbildung 15: Behandlung eines Patienten abschliessen
Beim Abschluss einer Behandlung werden verschiedene Aktivitäten parallel gestartet. Dabei sind in der Regel mehrere Informationssysteme involviert, die unterschiedliche Patientenidentifikationen des gleichen Patienten zu verwalten haben.
6.3 Abhängigkeiten zur Performance der Systeme
In den vorgenannten Arbeitsabläufen ergeben sich zeitliche Abhängigkeiten, die in bestimmten Situationen
auch einen Einfluss auf die Bildung oder die Verwendung eines MPI haben. Mit den folgenden Unterkapiteln
wird anhand einiger Prozessbeispiele erläutert, mit welchen zeitlichen Abhängigkeiten die Endbenutzer in
den Institutionen konfrontiert werden.
6.3.1 Patientenanmeldung
Die Patientenadministration ist darauf ausgebildet, die anzumeldenden Patienten möglichst eindeutig
(Stammdaten und Kostenträgerdaten) zu erfassen. Dabei sollen Doppel- oder Mehrfacherfassungen verhindert werden um die medizinische Behandlung administrativ zu vereinfachen. Die eindeutige Erfassung hat
aber die höhere Priorität als das Verhindern von Mehrfacherfassungen in einem System. Je einfacher ein
Patient in einem Administrationssystem gesucht und identifiziert werden kann, umso seltener erfolgen Mehrfacherfassungen eines Patienten. In der Regel wird mit dem Geburtsdatum und dem Nachnamen nach dem
Patienten gesucht. Eine MPI-ID des Patienten wird zu diesem Zeitpunkt kaum verfügbar sein.
Wenn aber im Suchresultat einer Suche mit den Stammdaten eines Patienten die MPI-ID zusätzlich vorhanden ist, hat der Benutzer die Möglichkeit Doppel- oder Mehrfacherfassungen optisch zu erkennen.
Dazu ist es notwendig, dass der MPI in den Informationssystemen der Institutionen gespeichert ist, was zur
Folge hat, dass neu erstellte MPIs grundsätzlich an die verschiedenen Patientenadministrationssysteme
weitergeleitet werden müssen.
Falls der MPI nicht in den Informationssystemen gespeichert wird, soll der der Benutzer die Möglichkeit haben den MPI direkt abzufragen. Da die Verwaltung der MPIs institutionsübergreifend erfolgt, muss der Benutzer hier mit Verzögerungen rechnen. Die Patientenadministration ist in diesem Fall nicht verpflichtet auf
Seite 25 von 25
den MPI zu achten, sondern soll ihre Arbeit wie bis anhin erledigen. Bei der Pflege des MPI wird ersichtlich,
wenn Patienten in den Institutionen mehrfach erfasst wurden und es wird eine entsprechende Zusammenführung ausgelöst. Im Falle einer manuellen Bearbeitung durch das Personal beim MPI kann dies auch erst
Tage nach der Erfassung im Informationssystem der Fall sein. Nach der Zusammenführung von Patientenidentifikationen wird nur noch eine gültige Patienten ID unterstützt. Damit müssen sowohl Personal und Informationssysteme umgehen können.
6.3.2 Diagnostik
Während einer Diagnose wird immer versucht auch das Umfeld des Patienten und seine medizinische Vergangenheit mit ein zu beziehen. Dabei ist es wünschenswert möglichst komplette Daten zu erhalten um sich
ein Gesamtbild erarbeiten zu können. Momentan ist man dabei auf die Unterstützung des Patienten und in
vielen Fällen von seinen Angehörigen abhängig.
Mit Hilfe eines MPIs besteht die Möglichkeit sich eine Übersicht zu verschaffen, wo zusätzliche Informationen eines möglichen Krankheitsverlaufes vorhanden sein könnten (klinisches Szenario: Hinweise zur Medikation des Hausarztes).
Der MPI kann die Information liefern, in welchen Partnersystemen derselbe Patient registriert ist. Dabei
muss unbedingt auf die Vorgaben des Datenschutzes geachtet werden. Auch wenn im MPI mehr Informationen verfügbar wären, darf nur das angezeigt werden, was rechtlich legal ist. Wenn mittels MPI die Schnittstelle gar automatisiert wird, steigt zwar Effizienz und Qualität noch einmal massiv an. Das Risiko im Bezug
auf einen Verstoss gegen das DSG nimmt aber gleichermassen zu.
Je nach rechtlichen Grundlagen soll der MPI den direkten Zugriff oder mindestens die Kontaktdaten der gewünschten Information ermöglichen. Mit Hilfe des MPI können die gewünschten Informationen für den behandelnden Arzt beschafft werden.
Falls der MPI nicht verfügbar ist, muss das Sekretariat diesen abfragen können, bevor es die entsprechenden Stellen kontaktiert. Dabei soll nicht nur die MPI-ID des gewünschten Patienten, sondern auch die Patientenidentifikationen im gewünschten Nummernkreis (in der zu kontaktierenden Institution) abgefragt werden können.
Bei der Abfrage über Patientenidentifikationsgrenzen hinweg (zum Beispiel in einem Nachbarkanton), muss
grundsätzlich auch bei elektronisch vernetzten Applikationen mit Antwortverzögerungen im Sekunden- oder
Minutenbereich gerechnet werden. Dies muss sowohl im Arbeitsprozess der Mitarbeiter wie auch bei der
Erweiterung von bestehenden Informationssystemen entsprechend berücksichtigt werden. Dennoch ist damit gegenüber der heutigen Situation eine klare Effizienzsteigerung und auch eine erhebliche Verbessrung
in den Bereichen Behandlungsqualität und Patientensicherheit gegeben.
6.3.3 Zu empfehlende Anforderungen an die Systemlandschaft
Aus den vorgenannten Kapiteln können folgende Empfehlungen bezüglich im Umgang mit einem MPI an die
Institute weitergegeben werden:
• Um die Identifikation eines Patienten zu vereinfachen und Mehrfacherfassungen zu minimieren, sollte
der MPI in den jeweiligen Informationssystemen registriert werden. Dazu müssen die Informationssysteme die Anforderungen des Aktors „Patient Identity Consumer“ des IHE Integrationsprofils PIX erfüllen.
• Falls die jeweiligen Informationssysteme nicht in der Lage sind, den MPI zu verwalten, sollten die Applikationen in der Lage sein, das Abfragetool der MPI Verwaltung direkt aufzurufen (z.B. Öffnen eines
Webbrowserfenster mit einem Direktlink zur MPI Verwaltung). Dazu sollten die Systeme in der Lage
sein, die Authentifizierung nach Vorgaben der MPI Verwaltung durchzuführen. Hier sei das IHE Integrationsprofil ATNA erwähnt.
Seite 26 von 26
6.4 System- und Projektlandschaft des Auftraggebers
Der Bundesrat hat Anfang 2006 das EDI beauftragt eine [eHealth Strategie] zu erarbeiten. Dabei wurde als
Ziel definiert, der Schweizer Bevölkerung den Zugang zu einem bezüglich Qualität, Effizienz und Sicherheit
hoch stehenden und kostengünstigen Gesundheitswesen zu gewährleisten. Bei der eHealth Strategie sollen
nicht technische Möglichkeiten im Vordergrund stehen, sondern die bestehenden Prozesse mit dem Einsatz
der neuen Technologien vereinfacht werden. Der Bundesrat hat nun auf Antrag des Eidg. Departementes
des Innern die „Strategie eHealth Schweiz“ für die Jahre 2007 bis 2015 am 27.06.2007 genehmigt.
In dieser Strategie wurden unter anderem folgenden Ziele formuliert:
• Ziel A1: Bis Ende 2008 sind die Standards definiert für einen elektronischen Auszug behandlungsrelevanter Informationen aus der persönlichen Krankengeschichte. Die für die Einführung notwendigen Voraussetzungen sind beschrieben.
• Ziel A6: Bis Ende 2012 ist die elektronische Übermittlung von medizinischen Daten unter den Teilnehmern im Gesundheitssystem strukturiert, medienbruchfrei und verlustfrei etabliert. Alle akut-somatischen
Spitäler, alle integrierten Versorgungsnetze und die Mehrheit der frei praktizierenden Ärzte verwenden
den elektronischen Auszug behandlungsrelevanter Informationen aus der persönlichen Krankengeschichte.
Seite 27 von 27
Im Text zum Ziel A1 steht unter anderem:
Im Hinblick auf die Einführung eines elektronischen Auszugs aus der Krankengeschichte sind die dafür notwendigen Voraussetzungen zu erheben. Dazu gehört und anderem die Klärung der persönlichen Identifikation (Patientinnen und Patienten und Leistungserbringer) oder die zu verwendenden Standards insbesondere
für Diagnoselisten, Medikamenteninformationen oder Risikofaktoren. Bei der Versichertenkarte gilt die neue
AHV-Nummer als persönlicher Identifikator der Versicherten. Ob – und allenfalls wie – diese Nummer auch
bei der eindeutigen Identifikation der Patientinnen und Patienten verwendet werden kann, muss im Rahmen
dieser Arbeiten geklärt werden.
Mit diesem Hintergrund sind Projekte in verschiedenen Kantonen und auch von der Industrie gestartet worden. In der folgenden Tabelle werden die laufenden Projekte, welche im Zusammenhang mit dem vorliegenden Grobkonzept für den Auftraggeber relevant sind mit den darin involvierten Bereichen und Systemen
aufgeführt.
Organisation
Projekte
Bund
eHealth Strategie
• 2008: Standards
• 2012: elektronisches Patientendossier
eKOGU
• mit den Versicherungen
• unter den Kantonen (Ausbau der eKOGU Projekte aus der GDK Ost)
eKOGU nach KVG 41.3
(Verbindung E-Government / eHealth)
GDK
GDK-Ost
Kanton
SG
Betriebe
Involvierte Systeme
Pandemieregister
PMS
Einführung und Entwicklung eines Patientenmanagementsystems für
die Spitalverbunde des Kantons St. Gallen und das Bürgerspital St.
Gallen
MeDIswiss
Patient Record Summary Austausch zwischen den stationären Einrichtungen des Kantons St. Gallen
Service Center IT (SSC-IT) für folgende Betriebe
KSSG
SRFT
SR Linth
SR RWS
Bürgerspital
Nexus / Medfolio
Labor IKMI/IKCH
KPD Pfäfers/Will, …
Tiani Spirit / TSystems
SAP
Medfolio, ADIR,
SAP, Cloverleaf, …
Tabelle 4: System- und Projektlandschaft des Auftraggebers
6.5 Konzeptvorschlag
Sowohl das IHE Integrationsprofil PIX als auch das VHitG PID-Profil bilden ausgezeichnete Grundlagen für
die Umsetzung domänenübergreifender MPIs. Allerdings fokussieren diese Profile hauptsächlich den innerdomänen bezogenen PID Austausch. Folgende Schwachstellen existieren im Zusammenhang mit dem domänenübergreifenden Austausch:
• Beide Profile beschreiben jeweils nur einen zentralen Aktor, der die verschiedenen Patientenidentifikationen verwaltet
• Der Cross Reference Manager ist per Definition nicht als Datenquelle vorgesehen
• Die MPI Verwaltung wird in beiden Profilen nur als Option beschrieben
Alle genannten Schwachstellen können mittels Spezifikation bereinigt werden, ohne dass die ursprüngliche
Definition des Standards verändert werden muss, da die darunterliegenden HL7 Nachrichten – wie in der
nachfolgenden Tabelle ersichtlich ist – unverändert bleiben.
Seite 28 von 28
Patient Identity Feed
Patient Identity Query
Patient Identity Update
VHitG PID-Profil
(HL7 V3 Ballot 13)
IHE PIX-Profil
(HL7 V2.3.1 und V2.5)
Erläuterung
PRPA_IN201101UV01
ADTÂ01, ADTÂ04,
ADTÂ05
ADTÂ08
Neuer Patient
PRPA_IN201102UV01
PRPA_IN201103UV01
PRPA_IN201104UV01
MCCI_IN002002
QUPA_IN201203
QUPA_IN201203
PRPA_IN201101UV01
PRPA_IN201102UV01
PRPA_IN201103UV01
PRPA_IN201104UV01
MCCI_IN002002
ADTÂ31
Geänderter Patient
Stornierter Patient
Patientenzusammenführung
Empfangsbestätigung
Patientenanfrage
Antwort auf Patientenanfrage
Neuer Patient
ACK
Geänderter Patient
Stornierter Patient
Patientenzusammenführung
Empfangsbestätigung
ADTÂ40
ACK
QBP^Q23
RSP^K23
Tabelle 5: Gegenüberstellung VHitG PID und IHE PIX resp. HL7 V3 und V2.x
Der Konzeptvorschlag lautet nun:
Umsetzen des IHE Integrationsprofil PIX und des VHitG PID Profils als Basis. Die von einem Cross Reference Manager gebildeten Cross Reference Domänen, bilden ihrerseits wieder eine Patient Identifier Domäne
welche via einen übergeordneten Cross Reference Manger zusammengefasst werden können.
Patient Identifier Domain ABCD
Cross Reference
Manager ABCD
Cross Reference
Manager AB
Patient Identifier
Domain A
Patient Identifier
Domain B
Patient Identifier Domain AB
Cross Reference
Manager CD
Patient Identifier
Domain C
Patient Identifier
Domain D
Patient Identifier Domain CD
Abbildung 16: Lösungskonzept mit hierarchischen Cross Reference Managern
Dieses hierarchische Abbilden von verschiedenen Cross Reference Managern kann grundsätzlich beliebig
weitergeführt werden. Das könnte soweit getrieben werden, bis es einen Cross Reference Manager über die
ganze Welt gibt, was doch einer sehr unrealistischen Annahme entsprechen würde. Die gleiche Herausforderung stellte sich beim Erstellen des Internets auf der Basis von IP-Adressen. Wenn man erwarten würde,
dass jeder Router im Internet weiss, wo eine spezifische Adresse ist, hätte jeder Router eine Verwaltung von
Milliarden von Adressen zu führen. Hier wurde ein „Partnerprinzip“ eingeführt. Falls der Router die Zieladresse nicht kennt, gibt er das Nachrichtenpaket an einen „Core-Router“ weiter. Core-Routers sind eigentliche
Gateways zwischen Verbundnetzwerken (siehe auch Kapitel „3.5 Routing im Internet“ auf Seite 15).
Dieses Prinzip kann nun auch bei den Patientenidentifikationen angewendet werden.
Seite 29 von 29
Bezug zum klinischen Szenario:
Herr Müller ist in der Patientenidentifikationsdomäne von Herisau registriert. Die Domäne von Herisau leitet
immer alle registrierten Patienten automatisch durch ein Patient Identity Feed an den Cross Reference Manager des Kantons Appenzell Ausseroden weiter. Beim Eintreffen von Herrn Müller im KSSG erkennt das
Patientenadministrationssystem des KSSG, dass Herr Müller ein ausserkantonaler Patient ist und versucht
über die der Patientenidentifikationsdomäne vom Kanton St. Gallen angeschlossenen Patienten ID Gateways den MPI von Herr Müller herauszufinden.
Diese Patienten ID Gateways tauschen nach bestimmten Zeitfenstern ihre registrierten Tabellen untereinander aus. Solche Patienten ID Gateways könnten selbst wieder in einer Patientenidentifikationsdomäne (z.B.
GDK Ost) zusammengefasst werden.
Münsterlingen
Bregenz (A)
Bülach
Rorschach
Frauenfeld
Wil
Winterthur
St. Gallen
Zürich
Uster
Wattwil Herisau
Rüti
Uznach
Lachen
Altstätten
Appenzell
Feldkirch (A)
Grabs
Vaduz (FL)
Walenstadt
Glarus
Scuol
Chur
Ilanz
Davos
Samedan
Disentis
Spitäler des Kt. St. Gallen
Ausserkantonale Spitäler
Gateway’s zwischen den Kantonen
Abbildung 17: Zusammenfassen von Identifikationsdomänen mit Hilfe von Gateways
Seite 30 von 30
6.6 SWOT des Konzeptvorschlages
Stärken (Strength)
Schwächen (Weakness)
•
•
•
•
•
Basis sind weltweit anerkannte Standards,
deren Umsetzung in den IHE Integrationsprofilen oder dem VHitG PID beschrieben
sind.
Die Anwendung der IHE Integrationsprofile
wird bei den IHE Connectathons getestet.
Resultate der IHE Connectathons sind auf
dem Internet öffentlich einsehbar.
Flexible Gestaltung von PatientenIdentifikationsdomänen.
•
Die IHE Integrationsprofile oder das VHitG PID beschreiben die Cross-referenz Manager nicht als Identifikationsquellen.
Es gibt keine Beschreibung eines Algorithmus zur Bildung des MPI.
Chancen (Opportunities)
SO-Strategie
WO-Strategie
•
•
•
•
Da mehrere Länder im Ausland ebenfalls auf
die IHE Integrationsprofile referenzieren
könnte man von einem Erfahrungsaustausch
profitieren.
Es besteht die Möglichkeit einheitliche Beschaffungsrichtlinien für die Schnittstellen zu
definieren.
•
Zum Erfahrungsaustausch Plattformen bieten für gemeinsame Besuche von Fachmessen
Vorgaben für Beschaffungsprojekte analog
zum IHE Radiology User Handbook erarbeiten
•
Beschreiben von MPI-Service Providern, dazu die Erfahrungen aus dem Ausland beiziehen
Ein MPI-Algorithmus in Zusammenarbeit von Interessensgruppen (HL7, SGMI, …) erarbeiten und für die
Schweiz publizieren
Risiken (Threads)
ST-Strategie
WT-Strategie
•
•
•
•
Durch die Anforderungen der IHE und VHitG
besteht eine eingeschränkte Auswahl von
Produkten auf dem Markt.
IHE und VHitG sind nicht die einzigen Initiativen weltweit und sind in der Schweiz nur
wenig bekannt.
•
Durch die einheitlichen Vorgaben können
andere Anbieter ermutigt werden ebenfalls
an IHE teilzunehmen
Durch die Vereinfachung der Beschaffung,
wird auch der Bekanntheitsgrad der Initiativen von IHE und VHitG zunehmen
•
Der MPI-Algorithmus sollte bis mindestens GDK-Ost in
die Vernehmlassung, um eine möglichst hohe Akzeptanz zu erreichen
Durch Beispiele wie das Projekt MeDIswiss kann die
Praxistauglichkeit erprobt werden.
Tabelle 6: SWOT Lösungskonzept
Seite 31 von 31
7 Umsetzungskonzept
Das Umsetzungskonzept basiert auf technischen und organisatorischen Massanahmen und soll mittels serviceorientierter Architektur (SOA) umgesetzt werden.
7.1 MPI Service Provider
Die verfügbaren Konzepte (IHE und VHitG) unterstützen die MPI Thematik hauptsächlich innerhalb einzelner
Institutionen oder in Verbunden mit Kommunikationsservern. Im Lösungskonzept wurden sogenannte Gateways eingeführt um Patientenidentifikationen über Cross Reference Domänen hinweg auszutauschen. Diese
Gateways sollen in Form von MPI Service Providern organisiert werden.
Abbildung 18: MPI Service Provider
Administrative Aufgaben eines MPI Service
Providers:
Pflege der internen MPI Datenbank wie z.B. Freigabe von neuen Registrationen,
Zusammenführen von Duplikaten, Stornieren von ungültigen Einträgen.
Die manuellen administrativen Arbeiten bei Patientenregistrationen sollen auf unter
10% der Anzahl Registrationen minimiert werden. Deshalb sollen die Patientenregistrationen mittels Zusammenführungsmechanismus möglichst automatisch in der
internen MPI Datenbank gepflegt werden. Ziel ist es, nur die unsicheren Matches
(siehe nachfolgendes Unterkapitel) manuell bearbeiten zu müssen.
Technische Aufgaben
eines MPI Service
Providers:
Bereitstellung von Diensten (z.B. in Form von Webservices), welche eine serviceorientierte Anbindung von Institutionen oder anderen MPI Service Providern erlauben:
• Register Patient (Neue, geänderte und stornierte Patienten)
• Query/Response PID (Angabe der gewünschten Patienten ID gemäss Anfrage)
• Subscript/Publish Changes (Automatisierte Publikation von Änderungen an alle
registrierten Abonnenten)
Hinweis:
Der Abonnent – also der Empfänger einer automatisierten Publikation kann frei
entscheiden, was er mit der automatischen Publikation tut. So könnten z.B.
Neuregistrationen problemlos automatisiert werden. Automatisierte Stornierungen wünschen sich allerdings wahrscheinlich die wenigsten Institutionen und
deshalb könnte dafür zum Beispiel ein Report erstellt werden, der von der Patientenadministration manuell abgearbeitet wird.
Tabelle 7: Aufgaben eines MPI Service Providers
Seite 32 von 32
7.1.1 Organisationsform
Die manuellen Administrationsarbeiten und auch der Betrieb in übergreifenden PID Domains gehören in den
Verantwortungsbereich der MPI Service Provider. Ein MPI Service Provider kann eine eigenständige Organisation oder Unternehmung sein, welche sowohl die administrativen, wie auch die technischen Aufgaben
(Betrieb) übernimmt. Der MPI Service Provider kann aber auch eine virtuelle Organisation sein, in der z.B.
Datatypisten eines Spitals die Administration des MPI übernehmen und ein Service Center den Betrieb sicherstellt.
7.1.2 MPI Datenbank
Nachfolgend wird ein Ansatz einer möglichen MPI Datenbankstruktur inkl. entsprechender Beispieleinträge
aufgezeigt.
Abbildung 19: MPI Datenbank Modellansatz
Abbildung 20: Beispiel OIDs
Seite 33 von 33
Abbildung 21: Beispiel MPI Patienten
Abbildung 22: Beispiel MPI Einträge
Abbildung 23: Beispiel MPI Adressen
Die Beispieldatensätze enthalten auch Einträge, welche den Bezug zum klinischen Szenario aufzeigen.
7.1.3 Automatisierbarer Zusammenführungsmechanismus
Jede neue Patientenregistration wird mit dem Inhalt des zentralen Registers verglichen. Der Vergleich erfolgt
anhand definierter Algorithmen (siehe nachfolgendes Unterkapitel). Zusammen mit einer Feldkalibrierung
wird eine arithmetische Summe berechnet. Die Summe wird mit einem oberen und unteren Schwellenwert
(Matchkalibrierung) verglichen und dadurch in eine der folgenden Kategorien eingeteilt:
•
Sicherer Match Æ der Datensatz wird mit dem zentralen Register zusammengeführt
•
Unsicherer Match Æ der Datensatz wird für die manuelle Bearbeitung gekennzeichnet
•
Kein Match Æ der Datensatz wird als neuer Eintrag im zentralen Register eröffnet
Zentrales Register
Resultat
Geb. Vergleich
1:1 Vergleich
Phon. Vergleich
Datenquelle
Resultat
Resultat
Sicherer Match
Kalibrierung
Recordmatching
Unsicherer Match
Kein Match
Abbildung 24: Mechanismus zum Zusammenführen von Patienten
Seite 34 von 34
Für die Feldvergleiche sollen folgende Algorithmen implementiert werden:
•
Exakter Vergleich
Die beiden zu vergleichenden Felder müssen exakt übereinstimmen
Verwendungszweck: z.B. für Geschlecht
•
Textvergleich
Die beiden zu vergleichenden Felder müssen unabhängig von Leerzeichen und Gross-/Kleinschreibung
übereinstimmen
Verwendungszweck: z.B. für Organisations- oder Diplombezeichnungen
•
Phonetischer Textvergleich
Dazu soll eine, auf unseren Sprachgebrauch adaptierte Variante des Soundex Algorithmus eingesetzt
werden
Verwendungszweck: für alle Textfelder wie Namen, Adressen, Orte
•
Datumsvergleich
Gewichtung in absteigender Reihenfolge: Jahr, Monat, Tag
Verwendungszweck: z.B. für Geburtsdatum
•
Adressvergleich
Alle Adressen von Personen werden historisiert abgelegt. Dadurch muss eine Adresse nicht zwingend
mit genau einer anderen Adresse übereinstimmen. Falls die Adresse in der History gefunden wird, kann
diese Information als Übereinstimmung von Personen bewertet werden
•
Kommunikationsmittelvergleich
Alle Kommunikationsmittel (z.B. Telefonnummern wie Festnetz oder mobile, eMail Adressen) von Personen werden historisiert abgelegt. Dadurch muss ein Kommunikationsmittel nicht zwingend mit genau
dem Anderen übereinstimmen. Falls das Kommunikationsmittel in der History gefunden wird, kann diese
Information als Übereinstimmung von Personen bewertet werden
Seite 35 von 35
7.2 Architektur
Wir unterscheiden folgende Ebenen:
Ebene
Beschreibung
Kommentar
3
Netzübergreifende Domänen
Kantone, Regionen, länderübergreifende Gesundheitsregionen
Netzübergreifende Domänen werden über MPI Service Provider miteinander vernetzt. Dadurch wird auch die Vernetzung mit mehreren Domänen möglich.
2
Netze mit Kommunikationsplattform
z.B. Spitalverbunde
Institutionsübergreifende Patientenidentifikationen werden
nach dem IHE PIX Profil realisiert
1
Innerbetrieblich
z.B. Spitäler
Wie die Patientenidentifikation innerhalb eines Betriebes
sichergestellt wird, ist nicht Gegenstand des vorliegenden
Grobkonzeptes
Tabelle 8: MPI Domain Ebenen
MPI
Service Provider
Verbund 3
(Ebene 2)
Verbund 4
(Ebene 2)
Ebene 3
MPI
Service Provider
MPI
Service Provider
Ebene 3
Ebene 3
Verbund 2
Verbund 1
Verbund 1
Verbund 2
MPI
MPI
Ebene 2
Ebene 2
Krankenhaus 1
MPI
Krankenhaus 2
MPI
MPI
Ebene 1
Krankenhaus 3
Ebene 1
Krankenhaus 4
MPI
Ebene 1
Krankenhaus
5
MPI
Ebene 1
Ebene 1
Abbildung 25: MPI Struktur
Seite 36 von 36
7.3 Organisatorisch
7.3.1 Administration MPI Service Provider
Bei der Verwaltung eines Master Patient Index (MPI) können nicht alle Anfragen automatisch verarbeitet
werden. Es gibt immer wieder Anfragen/Neuregistrationen/Stornos von Patienten deren demografische Information nicht eindeutig mit dem zentralen Datenstamm eines Master Patient Index verifiziert werden kann.
Die dadurch entstehenden manuellen Arbeiten gehören in den Verantwortungsbereich einer MPI Domain.
In den Ebenen 1 und 2 gehört diese Aufgabe in den Verantwortungsbereich der MPI Domain. In der Ebene 3
gehört diese Aufgabe in den Verantwortungsbereich des MPI Service Providers (siehe auch Kapitel „7.1 MPI
Service Provider“ auf Seite 32).
7.3.2 Register und Institutionen
Es gibt in der Schweiz eine Vielzahl an Institutionen und Registern für Personen und Institutionen im Gesundheitswesen (H+, FMH, SSO, SantéSuisse, Chirosuisse, BAG MEDUSE…).
Jede Institution und jedes Register soll eine OID erhalten, damit die Einträge eindeutig identifiziert werden
können. Die OIDs werden durch die HL7 Benutzergruppe Schweiz vergeben.
7.3.3 Datenschutz
Der Datenschutz basiert auf dem Grundrecht der persönlichen Freiheit, auf welches sich alle natürlichen
Personen berufen können. Er zielt auf den Schutz der Würde und Ehre sowie der Privatsphäre. Der Datenschutz regelt die Bearbeitung und die Bekanntgabe gesammelter Personendaten.
Daten zur Gesundheit von Patienten sind gemäss Art. 3 Bst. c lit. 2 DSG besonders schützenswerte Personendaten. Durch diese Klassifizierung wird die Erfassung und vor allem die Weitergabe solcher Daten erschwert.
Bei einem Master Patient Index werden keine Daten zur Gesundheit abgelegt. Es handelt sich um sogenannt „gewöhnliche Personendaten“. Dabei sind folgende Grundsätze zu beachten:
Rechtmässigkeit
Gesetzmässigkeit
Verhältnismässigkeit
Treu und Glauben
Transparenz
Zweckmässigkeit
Richtigkeit
Die Erhebung von Personendaten muss rechtmässig erfolgen
Eine ausreichende Gesetzesgrundlage ist erforderlich
Das verfolgte Interesse bei der Bearbeitung der Personendaten muss im Verhältnis
zu den Datenschutzrechten der Person stehen
Die Bearbeitung muss nach Treu und Glauben erfolgen
Die Datenbearbeitung muss für die betroffene Person transparent sein
Die Daten dürfen nur zum angegebenen Zweck verwendet werden
Die Personendaten müssen richtig sein
Um einen Master Patient Index führen zu können, ist die Ablage demografischer Informationen zu den Personen notwendig. Meistens kann bei Anfragen und Neuregistrationen nur anhand dieser Daten entschieden
werden, ob die Person bereits registriert ist oder nicht. Der MPI Datenbank Modellansatz zeigt auf, welche
demografischen Daten sinnvollerweise erfasst werden.
Die obigen Datenschutz-Grundsätze sind dabei entsprechend zu berücksichtigen. Wie dies erfolgen soll,
wird im Realisierungskonzept erarbeitet (Massnahme M10).
7.3.4 Etappierung
Folgende Meilensteine müssen vor dem ersten Einsatz eines domänenübergreifenden MPIs erreicht werden:
• OID Registration der schweizerischen Institutionen, Register und Codiersysteme (Massnahme M7)
• Definition, wie die Datenschutz Grundsätze (siehe Kapitel „7.3.3 Datenschutz“ auf Seite 37) für MPI Service Provider umgesetzt werden (Massnahme M10).
• Produktevaluation MPI Service Provider (Massnahme M8)
• Aufbau domänenspezifischer MPI Service Provider (Massnahme M9)
Seite 37 von 37
7.3.5 Aufgabenteilung, Kosten und Finanzierung
Die Verfasser schlagen vor, dass der eigentliche Standard inkl. Handbook durch eine Arbeitsgruppe der HL7
Benutzergruppe Schweiz erarbeitet werden soll. Damit kann die Legitimation des Standards sichergestellt
werden. Die HL7 Benutzergruppe Schweiz funktioniert allerdings nach dem Prinzip der Ehrenamtlichkeit. Die
finanziellen Mittel des Vereins beschränken sich mehr oder weniger auf die Mitgliederbeiträge und damit
lassen sich keine Projekte finanzieren. Die Arbeitsgruppe muss deshalb extern finanziert werden (z.B. über
Sponsoring oder Industrie-Initiative).
Die Verfasser schlagen folgende Aufgabenteilung vor. Die nachfolgenden Kostenangaben sind nicht verifiziert und beruhen einzig auf dem Bauchgefühl der Verfasser. Eine präzisere Kostenschätzung lässt sich erst
bei der Ausarbeitung eines Realisierungskonzeptes vornehmen.
Aufgabe
Schätzung Kostenrahmen
Verantwortlich
Kostenträger
OID Registration der schweizerischen
Register und Codiersysteme
Initiale OID Vergabe CHF ~20‘000
Weiterer Betrieb sollte mit Gebühren
selbsttragend sein
Pro Domainübergreifendem MPI:
Umsetzung:
CHF ~150‘000
Jährlich wiederkehrender
Personalaufwand:
1 Vollzeitstelle
Pro Etappe durchschnittlich
CHF ~35‘000
HL7 Benutzergruppe
Schweiz
Sponsor
Versorgungsregionen,
ev. GDK
Versorgungsregionen
HL7 Benutzergruppe
Schweiz
Sponsor
Umsetzung regionaler und nationaler
Master Patient Indizes
Eigentliche MPI Spezifikation
7.4 Technisch
Die Umsetzung von MPIs ist eine der Grundlagen für einen Austausch von Electronic Patient Records (EPR)
in der Schweiz. Der EPR Austausch wird mit grösster Wahrscheinlichkeit mit Nachrichten auf Basis der HL7
Clinical Document Architecture (CDA) realisiert, auf welcher auch der deutsche VHitG Arztbrief basiert. HL7
CDA basiert auf HL7 Version 3 (XML) und aus diesem Grund ist es sehr wichtig, dass die geplanten MPI
Service Provider ebenfalls mit HL7 Version 3 aufgebaut werden. Im heutigen Praxisalltag der Spitäler und
Institutionen ist allerdings hauptsächlich HL7 Version 2.x im Einsatz und deshalb muss die MPI Spezifikation
auch eine Anleitung zum Mapping von HL7 Nachrichten zwischen den Versionen 2.x und 3.0 enthalten
(Massnahme M11). Die relevanten Nachrichten können der Tabelle 5 auf Seite 29 entnommen werden.
Die zu erarbeitende MPI Spezifikation soll auf den folgenden Grundlagen (siehe auch Kapitel „3 Grundlagen
(Basistechnologien)“ auf Seite 7) aufbauen:
• IHE Integrationsprofil „Patient Identity Cross Referencing“ (PIX) – HL7 Version 2.x
• VHitG PID Profil: Konzept zur Patientenidentifikation – HL7 Version 3
Ausserdem soll ein IHE Handbook für Domainübergreifende MPI erstellt werden. Dadurch wird die Verbreitung dieses Konzepts via IHE erreicht und es erlaubt gleichzeitig die Zertifizierung der Hersteller am IHE
Connectathon.
7.4.1 Betrieb MPI Service Provider - Webservices
Es soll eine Service Orientierte Architektur erreicht werden und deshalb werden im Rahmen der MPI Spezifikation nur die Schnittstellen (Services) definiert. Konsument und Anbieter eines Web Service sind lose gekoppelt; beide kommunizieren mittels XML-basierten Nachrichten über definierte Schnittstellen. Dadurch
bleiben Details der Implementierung des Web Service verborgen. Web Services spielen heute als Middleware im Bereich E-Business eine sehr zentrale Rolle. Wie der Betrieb eines MPI Service Providers betriebsintern aufgebaut und gewährleistet wird ist deshalb nicht Gegenstand der MPI Spezifikation.
Diese Schnittstellen sollen als standardisierte Simple Object Access Protocol (SOAP) Web Services über
HTTPS realisiert werden.
Seite 38 von 38
Abbildung 26: Webservices der MPI Service Provider
Die Webservices werden mittels Web Service Definition Language (WSDL – Datei) auf entsprechenden Servern publiziert. Mit Hilfe der WSDL-Datei (Web Services Definition Language) werden Web Services exakt
beschrieben und es wird festgelegt, wie darauf zugegriffen werden kann. Der Transfer der eigentlichen XML
Daten geschieht mittels DIME Attachements über SOAP.
7.4.2 Semantik
Die Semantik wird über die HL7 Nachrichtenauswahl bestimmt. So impliziert z.B. PRPA_IN201101UV01
(HL7 V3) oder ADTÂ01 (HL7 V2.x) die Registration eines neuen Patienten. Vergleiche dazu die Tabelle 5
auf Seite 29. Allfällige zusätzliche semantische Informationen werden in der MPI Spezifikation notiert.
7.4.3 Sicherheit
Die Sicherheit beim Austausch von PID ist von enormer Wichtigkeit. Die Umsetzung von MPIs ist eine der
Grundlagen für einen Austausch von Electronic Patient Records (EPR) in der Schweiz. Aus diesem Grund
soll der Austausch von PID über MPI die gleichen Richtlinien wie beim Austausch von EPR in der Schweiz
erfüllen. Aus diesem Grund werden nachfolgend die Empfehlungen bezüglich Sicherheit an einen EPR Austausch aufgeführt:
Empfehlungen EPR Austausch in der Schweiz (Bereich Sicherheit):
Die Daten sollen während der Übertragung verschlüsselt sein und nur vom gewünschten Empfänger entschlüsselt werden können. Zudem müssen die Daten signiert werden können, damit die Authentizität der
Daten gewährleistet werden kann.
Für die technische Lösung beider Themenbereiche gibt es folgende Schlüsselfaktoren, welche für den Erfolg
der EPR Schnittstelle essentiell sind:
Praxistauglichkeit:
Die eingesetzten Mechanismen müssen auf einfachste Weise eingesetzt werden
können
Kosten:
Die Investitionen auf Seite der Anwender müssen so tief wie möglich sein
Sicherheitsgrad:
Der Sicherheitsgrad muss so hoch wie möglich sein, da es sich gemäss [DSG] um
besonders schützenswerte Daten handelt
Die Verschlüsselung der Datenübertragung soll auf zwei Arten gelöst werden:
• Übertragung der XML Daten im Klartext über eine chiffrierte Verbindung (z.B. ASAS Tunnel)
• Übertragung der chiffrierten XML Daten über eine öffentliche Verbindung (z.B. Internet)
Im Sinne einer grenzüberschreitenden Lösung ist es äusserst wichtig, dass die Verschlüsselung nicht auf
CH proprietären Produkten basiert (kein deutscher Arzt wird je ein ASAS-Abonnement lösen), sondern mit
einem international gängigen Algorithmus realisiert wird.
Zum Beispiel könnte GnuPG eingesetzt werden - ein OpenSource Verschlüsselungssystem, das seit 1999
existiert und für alle gängigen Betriebssysteme (Windows, Linux, Mac) kostenlos erhältlich ist. GnuPG geniesst weltweit einen ausgezeichneten Ruf. Es ist beispielsweise in manchen Ländern verboten, weil es von
Geheimdiensten nicht geknackt werden kann. Für die Schweiz ist den Verfassern kein Verbot bekannt.
Für die Signatur sollen beglaubigte, digitale Identitäten (Zertifikate) von anerkannten Zertifizierungsstellen
eingesetzt werden. Die EPR Spezifikation soll eine abschliessende Liste von vertrauenswürdigen Zertifizierungsstellen (wie z.B. SwissSign, Swisscom, BIT, Quovadis, …) enthalten. Im Sinne einer grenzüberschreitenden Lösung ist es äusserst wichtig, dass international anerkannte Zertifikate ebenfalls eingesetzt werden
können.
Seite 39 von 39
7.5 Gegenüberstellung des Umsetzungskonzepts zum klinischen Szenario
Mit der folgenden Grafik soll veranschaulicht werden, wie das klinische Szenario von Herr Müller nach einer
erfolgreichen Umsetzung ablaufen könnte.
act Notfall von Herr Müller
Herr Müller:Patient
Sanität:Zuweiser
Spital Herisau:Admin
Kantonsspital St. Gallen:Admin
Dr. Zurbuchen:Zuweiser
Patientenzustand
analysieren
MPI-Provider
Patientenstammdaten
Sanität
Sturz im Treppenhaus
Patient transportieren
Erstversorgung
sicherstellen
Patientenstammdaten
Herisau
Patient behandeln
Zusatzinformationen
einholen
Patientenstammdaten
KSSG
Patientendaten
bereitstellen
Patientenstammdaten
Dr. Zurbuchen
Patient entlassen
Fall abgeschlossen
Abbildung 27: Klinisches Szenario mit einem MPI-Provider
Wie in der Abbildung 27: Klinisches Szenario mit einem MPI-Provider ersichtlich ist, liefern alle Systeme
nicht einfach nur eine Nummer eines Patienten, sondern es handelt sich dabei immer um Stammdaten eines
Patienten.
Seite 40 von 40
8 Weiteres Vorgehen
8.1 Bezug zur eHealth Strategie
Im Ziel A1 der [eHealth Strategie] wird gefordert, dass bis Ende 2008 die Standards für einen elektronischen
Auszug behandlungsrelevanter Informationen aus der persönlichen Krankengeschichte definiert sind.
Ein Informationsaustausch der persönlichen Krankengeschichte kann nur über eine entsprechende Verbindung – sprich eine Patientenidentifikation erfolgen. Die Einführung der neuen Sozialversicherungsnummer in
der Schweiz wird diese Problematik nicht lösen können, da mit Sicherheit Personen medizinisch versorgt
werden, die keine Sozialversicherungsnummer haben (Touristen, ausl. Arbeitskräfte, Flüchtlinge, …).
Abbildung 28: Unique Patient Identifier ist unrealistisch
Ein Top-Down Ansatz mit einem Unique Patient Identifier ist deshalb unrealistisch. Wiederum im Vergleich
zum Internet müssen die Patientenidentifikationen in Domänen zusammengefasst und domänenübergreifend ausgetauscht werden können. Mittels eines Bottom-Up Ansatz wird der Patient in den Institutionen, in
welchen er Leistungen bezieht, erfasst und ist anschliessend via MPIs in den entsprechenden Domänen
verfügbar.
Abbildung 29: Master Patient Index CH
Seite 41 von 41
Der Austausch von Patientenidentifikationen mittels MPI soll deshalb in die Umsetzung des eHealth Strategie Ziels A1 einfliessen (Massnahme M2).
8.2 Roadmap
Die GDK Ost, als Bestandteil der Gesundheitsregion Euregio Bodensee eignet sich hervorragend für die
Umsetzung einer MPI Domain. Wenn die Umsetzung des MPI in dieser Region im zweiten Halbjahr 2008
nennenswerte Erfolge vorweisen kann, kann dies als „good practice“ Modell in die nationale Umsetzung des
eHealth Strategie Ziels A1 einfliessen.
Abbildung 30: MPI Roadmap
Gemäss obiger Roadmap könnte ein MPI im zweiten Halbjahr 2008 eingeführt werden.
8.3 Massnahmenkatalog
Finanzierung:
Die Finanzierung der einzelnen Massnahmen muss möglichst im Voraus gesichert
werden (Massnahme M1). Es wäre schade, wenn das Vorhaben auf halbem Weg
aus finanziellen Gründen eingestellt werden müsste. Dieses Szenario wurde in der
Vergangenheit bereits zu oft praktiziert (z.B. eCH Fachgruppe eHealth, Arbeitsgruppe EPRS).
Publicity:
Es ist äusserst wichtig, dass den Entscheidungsträgern im schweizerischen Gesundheitswesen bewusst wird, dass es bereits Standards gibt, die sehr weit fortgeschritten sind. Dazu ist von der HL7 Benutzergruppe im August/September 2007
eine entsprechende Fachtagung geplant (Massnahme M3).
Nach der Publikation der MPI Spezifikation sollen auch entsprechende Schulungen
angeboten werden (Massnahme M4).
Legitimation:
Für die Umsetzung im Kanton St. Gallen ist keine spezielle Legitimation notwendig.
Der Kanton kann die Umsetzung des MPI z.B. in den Leistungsauftrag für die Leistungserbringer aufnehmen (Massnahme M5).
Die Legitimation als national etablierter Standard kann über den Weg der Vernehmlassung oder über den gesetzlichen Weg via GDK erfolgen. Diesbezüglich ist
vom Auftraggeber ein entsprechender Entscheid zu treffen (Massnahme M6).
Infrastruktur:
Folgende Infrastrukturen müssen aufgebaut werden:
1. OID Registration der schweizerischen Register und Codiersysteme (Massnahme M7)
2. Aufbau domänenspezifischer MPI Service Provider (Massnahme M9)
Eigentlicher Standard:
Erstellung einer domänenübergreifenden MPI Spezifikation (Massnahme M12),
eines entsprechenden IHE Handbooks (Massnahme M13) und einer Wegleitung
zur Anwendung von MPIs in der Schweiz (Massnahme M14).
Das IHE Handbook dient der Zertifizierung der Anbieter an IHE Connectathons.
In der Wegleitung wird unter anderem geregelt, wie schweizerische Spezialitäten
umgesetzt werden.
Tabelle 9: Massnahmenkatalog
Seite 42 von 42
8.4 Mögliche Umsetzung der Massnahmen
Bereich
Massnahme
Finanzierung
durch
Umsetzung
durch
M1
Finanzierung
Finanzierung aller einzelnen Massnahmen im Voraus sichern
offen
offen
M2
Publicity
Einflussnahme auf Umsetzung Ziel A1 der Strategie „eHealth“
Schweiz
offen
offen
M3
Fachtagung HL7 zum Thema EPR/MPI/OID
offen
offen
M4
Schulungen zur MPI Spezifikation
offen
offen
Entscheid für Umsetzung im Kanton St. Gallen
offen
offen
Entscheid für Legitimation als national etablierter Standard kann
über den Weg der Vernehmlassung oder über den gesetzlichen
Weg via GDK
offen
offen
Initiale OID Registration der schweizerischen Institutionen, Register und Codiersysteme
offen
offen
M8
Produkt Evaluation MPI Service Provider
offen
offen
M9
Aufbau domänenspezifischer MPI Service Provider
offen
offen
Definition, wie die Datenschutz-Grundsätze für MPI Service Provider umgesetzt werden
offen
offen
M11
Anleitung zum Mapping der relevanten HL7 Nachrichten zwischen
den Versionen 2.x und 3.0
offen
offen
M12
Erstellung einer domänenübergreifenden MPI Spezifikation
offen
offen
M13
IHE Handbook für Anbindung an domänenübergreifende MPI
offen
offen
M14
Wegleitung zum Anwenden von MPI in der Schweiz
offen
offen
M5
Legitimation
M6
M7
M10
Infrastruktur
Standarderarbeitung
Tabelle 10: Umsetzung der Massnahmen
Die Spalten „Finanzierung durch“ und „Umsetzung durch“ sind noch offen und werden im Rahmen des Realisierungskonzeptes geklärt.
Seite 43 von 43
9 Anhang
9.1 Referenzierte Dokumente
Alle nachfolgenden Internet Links wurden zuletzt am 29.06.2007 besucht. Aufgrund der täglichen Veränderungen im Internet, kann keine Garantie für die zukünftige Verfügbarkeit gegeben werden.
[CEN/TC 251]
EU Standardisierungsgremium im Fachbereich Medizinische Informatik
[DSG]
Bundesgesetz vom 19. Juni 1992 über den Datenschutz (DSG)
http://www.admin.ch/ch/d/sr/2/235.1.de.pdf
[eHealth Strategie]
Strategie „eHealth” Schweiz
27.06.2007
http://www.bag.admin.ch/themen/krankenversicherung/00305/03505/index.html?la
ng=de
[ELGA]
Machbarkeitsstudie betreffend Einführung der elektronischen Gesundheitsakte
(ELGA) im österreichischen Gesundheitswesen
Endbericht vom 21. November 2006
Erstellt von IBM Österreich im Auftrag der österreichischen Bundesgesundheitsagentur
www.arge-elga.at/m/Machbarkeitsstudie_ELGA.PDF
[HL7 CDA]
HL7 Clinical Document Architecture, Release 2.0
ANSI/HL7 CDA, R2-2005 4/21/2005
HL7 Version 3 Standard; Last Published: 03/27/2006 3:35 AM
www.hl7.org
[ICW Umsetzung PID]
Erfahrung bei der Umsetzung des VHitG PID-Profils
auf der Basis von HL7 Version 3
Inter Component Ware, Christian Ohr, 26. Oktober 2006
http://www.hl7.de/download/veranstaltungen/jahrestagungen/2006/10ohr.pdf
[ISO 21549-3]
ISO 21549-3:2004
Health informatics – Patient healthcard data – Part 3:
Limited clinical data
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=346
00&ICS1=35&ICS2=240&ICS3=80
[ISO/TC 215]
ISO Standardisierungsgremium im Fachbereich Medizinische Informatik
http://www.iso.org/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.Te
chnicalCommitteeDetail?TC=215
[KVG]
Bundesgesetz vom 18. März 1994 über die Krankenversicherung (KVG)
http://www.admin.ch/ch/d/sr/8/832.10.de.pdf
[MedBG]
Medizinalberufegesetz
http://www.bag.admin.ch/themen/berufe/00993/index.html?lang=de
Das BAG ist aktuell an der Erstellung eines entsprechenden Registers. Der Nutzbetrieb soll ab 2008 möglich sein. Weitere Informationen:
http://www.bag.admin.ch/themen/berufe/00411/index.html?lang=de
Seite 44 von 44
[NK 165]
[prEN 13606]
Schweizerisches Normenkomitee 165
IT und Qualität im Gesundheitswesen: Normung von Techniken, Methoden und
Terminologien im Bereich der medizinischen Informatikanwendungen.
http://www.snvlivelink.ch/snvweb2/controller/tkdetail/?livelinkDataID=224141&XML
QUERY_livelinkDataID=224141&XMLQUERY_tk=NK 165
Europäischer Pre-Standard für „Electronic healthcare record communication“
[VHitG Arztbrief]
VHitG Arztbrief auf der Basis der HL7 Clinical Document Architecture Release 2
für das deutsche Gesundheitswesen
Implementierungsleitfaden
Version 1.50, Stand: 12.05.2006
http://download.vhitg.de/Leitfaden-VHitG-Arztbrief-v150.pdf
[VHitG PID Profil]
VHitG Konzept zur Patientenidentifikation auf Basis HL7 Version 3
Version 0.9, Stand: 31.07.2006
http://download.vhitg.de/Leitfaden_VHitG_PID_v09.pdf
[VHitG AG IS]
VHitG Initiative „Intersektorale Kommunikation“
Zwischenergebnisse und neue Geschäftsvorfälle
Andreas Kassner, 02.06.06
http://www.informatik.fh-mannheim.de/KIS2006/daten/
vortraege_kis2006/KIS2006_WorkshopSKI_Kassner_02062006.pdf
Seite 45 von 45
9.2 Abkürzungen und Glossar
Die nachfolgenden Definitionen stammen aus den referenzierten Dokumenten und aus dem Internet (u.a.
Firmen- und Institutionswebseiten, Wikipedia, Google):
ASAS
HIN – die gesicherte Extranet-Plattform im Schweizer Gesundheitswesen bietet
mit dem ASAS Tunnel eine Streckenverschlüsselung mittels asymmetrischem
Verschlüsselungsverfahren. www.hin.ch
CDA
Clinical Document Architecture.
Speziell für die medizinische Dokumentation und Kommunikation definierte
XML basierte Dokumentenarchitektur zur Ermöglichung der herstellerunabhängigen elektronischen Dokumentation und Kommunikation medizinischer Informationen.
DSG
Datenschutz Gesetz; siehe auch „9.1 Referenzierte Dokumente“ auf Seite 44.
EPR
Ein Electronic Patient Record (EPR) ist eine Beschreibung von medizinischen
Informationen zu einem Patienten. Es existieren unterschiedliche Auffassungen
über den Inhalt und den Verwendungszweck (z.B. Summary, komplette Akte,
Notfalldatensatz). Dieselbe Datensammlung wird oft auch als Electronic Medical Record (EMR) oder Electronic Health Record (EHR) bezeichnet.
GalDat
Medikamentendatenbank „GalDat“. In ihr ist jeder Artikel für die Schweiz mit
einem eindeutigen Pharmacode einheitlich identifiziert.
Die GalDat Datenbank wird von der Firma e-mediat gepflegt und vertrieben.
GnuPG
GnuPG oder GPG (GNU Privacy Guard, englisch für GNUPrivatsphärenschutz) ist ein freies Kryptographiesystem, d. h. es dient zum Verund Entschlüsseln von Daten sowie zum Erzeugen und Prüfen elektronischer
Signaturen. Das Programm implementiert den OpenPGP-Standard nach RFC
2440 und wurde als Ersatz für PGP entwickelt. Versionen ab 2.0 implementieren auch den S/MIME-Standard. GnuPG benutzt standardmässig nur patentfreie Algorithmen und wird unter der GNU-GPL vertrieben. Es kann unter Linux,
Mac OS X und diversen anderen Unix-Varianten sowie unter Microsoft Windows betrieben werden.
www.gnupg.org
HL7
Health Level 7. Kommunikationsstandard für medizinische Informationssysteme
mit umfangreichen Definitionen zu Nachrichtentypen und Triggerevents, die
Nachrichtenübermittlungen auslösen.
www.hl7.org, www.hl7.de, www.hl7.ch
IHE
IHE (Integrating the Healthcare Enterprise) ist eine Initiative zur Verbesserung
des technischen Datenaustauschs von IT Systemen im Gesundheitswesen. Die
Initiative, die im Jahr 1998 vom amerikanischen Radiologenverband RSNA
(Radiological Society of North America) und der Vereinigung der Anbieter von
medizinischen Informationssystemen HIMSS (Healthcare Information and Management Systems Society) in den USA gegründet wurde, wird getragen von
medizinischen Anwendern, Fachgesellschaften, Verwaltungs- und IT Fachleuten sowie der medizintechnischen Industrie. Im Laufe der Zeit hat sich IHE zu
einer internationalen Bewegung entwickelt, die jetzt auch die speziellen Anforderungen der Gesundheitswesen in Europa und Japan in Betracht zieht. Der
europäische Zweig der Initiative arbeitet dabei eng mit der internationalen Initiative zusammen und hilft, die besonderen europäischen und nationalen Bedingungen in den internationalen Konzepten zu verankern.
www.ihe.org, www.ihe-europe.org
KVG
Krankenversicherungsgesetz; siehe auch „9.1 Referenzierte Dokumente“ auf
Seite 44.
Seite 46 von 46
PACS
Ein Picture Archiving and Communication System (PACS) ist in der Medizin ein
Bildarchivierungs- und Kommunikationssystem auf der Basis digitaler Rechner
und Netzwerke.
PACS Systeme erfassen digitale Bilddaten aller Modalitäten in der Radiologie
und der Nuklearmedizin. Grundsätzlich kommen auch Bilder aus anderen bildgebenden Verfahren, etwa aus Endoskopie, Kardiologie, Pathologie und Mikrobiologie, für die PACS Verarbeitung in Frage.
PID Domain
Systemübergreifender Bereich, in dem es einen eindeutigen Master Patient
Index gibt.
Primärsystem
Grundsätzlich bezeichnet man in der Informatik damit das aktive System in
einem Aktiv/Passiv Cluster bzw. in einer hot oder warm Standby Lösung.
Im vorliegenden Kontext werden diejenigen Systeme verstanden, in welche
aktiv Daten (z.B. Patientenstammdaten, Krankengeschichte) erfasst werden.
Damit sind also die heute vor allem die produktiven Krankenhaus- und Arztpraxisinformationssysteme gemeint. Passive Systeme, sind diejenigen, welche
Daten von Primärsystemen via Schnittstellen beziehen.
OSI
Das OSI Modell (Open Systems Interconnection) beschreibt modellhaft eine Art
der Datenübertragung für die Kommunikation offener, informationsverarbeitender Systeme (etwa zwischen Computern im Internet).
Es handelt sich um vereinheitlichte Verfahren und Regeln für den Austausch
von Daten in Form eines Schichtenmodells mit sieben Schichten: Bitübertragungs-, Sicherungs-, Vermittlungs-, Transport-, Sitzungs-, Darstellungs- und
Anwendungsschicht.
Das OSI Modell wird seit 1979 entwickelt und wurde 1983 von der ISO standardisiert. Das OSI Modell dient heute als die Grundlage für eine Reihe von
herstellerunabhängigen Netzprotokollen.
RIM
Reference Information Model
Generisches Klassenmodell für medizinische Informationssysteme, das als
Ausgangsbasis zur Definition von Nachrichtentypen für den HL7 Standard Version 3 dient.
Sciphox
Deutsche Arbeitsgemeinschaft Sciphox GbR mbH
Erstellt Dokumentenspezifikationen aus der Reihe der HL7 Standards und Clinical Document Architecture CDA für deutsche Anwendungsszenarien.
http://www.sciphox.de/ueber_uns/flyerallgemein.pdf
SOA
Der Begriff „serviceorientierte Architektur“ (SOA) oder englisch „Service Oriented Architecture“, auch dienstorientierte Architektur, ist ein Managementkonzept
und setzt erst in zweiter Linie ein Systemarchitekturkonzept voraus:
Das Managementkonzept strebt eine an den gewünschten Geschäftsprozessen
ausgerichtete Infrastruktur an, die schnell auf veränderte Anforderungen im
Geschäftsumfeld reagieren kann. Das Systemarchitekturkonzept sieht die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services vor.
Ein Service ist in diesem Kontext als eine Funktionalität definiert, die über eine
standardisierte Schnittstelle in Anspruch genommen werden kann. Er ist damit
eine spezielle Ausprägung des bekannten Konzepts der Softwarekomponente.
Soundex
Soundex ist ein phonetischer Algorithmus zur Indizierung von Wörtern und
Phrasen nach ihrem Klang in der englischen Sprache. Gleichklingende Wörter
sollen dabei zu einer identischen Zeichenfolge kodiert werden.
UDDI
UDDI (Universal Description, Discovery and Integration) ist ein Begriff aus der
Computertechnik und bezeichnet einen Verzeichnisdienst, der die zentrale Rolle in einem Umfeld von dynamischen Web Services spielen soll.
http://de.wikipedia.org/wiki/UDDI
VHitG
Verband der Hersteller von IT Lösungen für das Gesundheitswesen. Veröffentlichung des Implementierungsleitfadens für den deutschen elektronischen Arztbrief. www.vhitg.de
Seite 47 von 47
9.3 Abbildungsverzeichnis
Abbildung 1: Geschichte von HL7 ......................................................................................................................7 Abbildung 2: HL7 Reference Information Model (RIM) ......................................................................................8 Abbildung 3: PID Akteure und Transaktionen ....................................................................................................9 Abbildung 4: IHE Konzept ................................................................................................................................10 Abbildung 5: Patient Identification Cross Reference Domain ..........................................................................11 Abbildung 6: PIX Integrationsprofil in Beziehung zu einem MPI ......................................................................12 Abbildung 7: OID Struktur.................................................................................................................................14 Abbildung 8: Hybrides hierarchisches Feld-Relais-Internetwork (Quelle: www.cisco.com) .............................16 Abbildung 9: Routing zwischen autonomen Systemen (Quelle: www.cisco.com) ...........................................16 Abbildung 10: Empfehlung für ELGA (Österreich) ...........................................................................................19 Abbildung 11: e-MS Kanada ............................................................................................................................21 Abbildung 12: Anmeldung einer Untersuchung ................................................................................................23 Abbildung 13: Anfrage einer Kostengutsprache bei z.B. einer Versicherung ..................................................24 Abbildung 14: Auskunft Krankheitsverlauf........................................................................................................24 Abbildung 15: Behandlung eines Patienten abschliessen ...............................................................................25 Abbildung 16: Lösungskonzept mit hierarchischen Cross Reference Managern ............................................29 Abbildung 17: Zusammenfassen von Identifikationsdomänen mit Hilfe von Gateways ...................................30 Abbildung 18: MPI Service Provider.................................................................................................................32 Abbildung 19: MPI Datenbank Modellansatz ...................................................................................................33 Abbildung 20: Beispiel OIDs .............................................................................................................................33 Abbildung 21: Beispiel MPI Patienten ..............................................................................................................34 Abbildung 22: Beispiel MPI Einträge ................................................................................................................34 Abbildung 23: Beispiel MPI Adressen ..............................................................................................................34 Abbildung 24: Mechanismus zum Zusammenführen von Patienten ................................................................34 Abbildung 25: MPI Struktur...............................................................................................................................36 Abbildung 26: Webservices der MPI Service Provider .....................................................................................39 Abbildung 27: Klinisches Szenario mit einem MPI-Provider ............................................................................40 Abbildung 28: Unique Patient Identifier ist unrealistisch ..................................................................................41 Abbildung 29: Master Patient Index CH ...........................................................................................................41 Abbildung 30: MPI Roadmap ...........................................................................................................................42 Abbildung 31: HL7 RIM 2.11 19.09.2005 .........................................................................................................49 9.4 Tabellenverzeichnis
Tabelle 1: OID Beispiel Patientenidentifikation ................................................................................................15 Tabelle 2: OID Beispiel Diagnose ....................................................................................................................15 Tabelle 3: OID Root für HL7 Schweiz ..............................................................................................................15 Tabelle 4: System- und Projektlandschaft des Auftraggebers .........................................................................28 Tabelle 5: Gegenüberstellung VHitG PID und IHE PIX resp. HL7 V3 und V2.x ..............................................29 Tabelle 6: SWOT Lösungskonzept...................................................................................................................31 Tabelle 7: Aufgaben eines MPI Service Providers ...........................................................................................32 Tabelle 8: MPI Domain Ebenen .......................................................................................................................36 Tabelle 9: Massnahmenkatalog .......................................................................................................................42 Tabelle 10: Umsetzung der Massnahmen........................................................................................................43 Tabelle 11: IHE Connectathon Resultate für das Integrationsprofil PIX ..........................................................50 07. September 2007, Version 1.2 (freigegeben)
Seite 48 von 48
9.5 HL7 Reference Information Model (RIM)
Abbildung 31: HL7 RIM 2.11 19.09.2005
Seite 49 von 49
9.6 IHE Connectathon Resultate für das Integrationsprofil PIX
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
0
0
0
1
9 North-America 2007
1 Europe 2007
3 Europe 2006
5 Europe 2005
6 Europe 2004
Nennungen
0
0
1
2
1
0
0
2
1
0
1
1
2
3
0
1
0
0
0
1
0
0
2
0
0
0
0
1
1
0
0
1
0
4
0
1
1
1
1
0
0
1
*
*
0
0
0
2
0
0
0
1
2
1
1
1
2
3
1
2
0
0
1
0
1
0
0
0
0
0
1
0
0
1
0
1
1
0
0
1
0
1
1
5
3
0
*
*
1
*
*
0
*
*
4 Europe 2007
*
*
*
6 Europe 2006
*
*
*
*
*
Patient Identity Source
0
0
1
0
*
*
6 Europe 2005
*
*
Nennungen
North-America 2004:
IHE-HL7 connectathon
2
6 Europe 2007
*
*
3
1
1
1
2
2
2
1
7
1
1
1
1
2
0
0
1
1
1
0
1
1
1
2
1
1
1
0
1
1
0
2
0
0
3
2
1
1
0
1
5
3
0
2
2
0
1
7 Europe 2006
9 Europe 2005
Nennungen
6 Europe 2004
TOTAL Nennungen
TOTAL Nennungen
AGFA Healthcare 2
Allscripts Healthcare Solutions 2
Axolotl Corp. 1
BlueWare, Inc. 2
Carestream Health
4
(formely known as Kodak)
Caribel Programmazione S.r.l. 1
CGI-AMS 1
CPSI 2
Data Processing S.p.A. 6
Eclipsys Corporation 3
EDL 2
ETIAM 1
GE Healthcare 10
GIE Convergence-Profils 4
Hx Technologies 2
IASI Srl 3
IdeoPass 3
INFINITT 6
Initiate Systems, Inc. 6
InterComponentWare AG 1
International Business Machines 4
Lincoln 1
McKesson Information Solutions 1
MedicalCommunications 1
MEDIWARE 2
MEDOS AG 2
MedQuist 1
Misys 4
MNI Medicos Na Internet, 1
NextGen 1
NIST 1
Novell, Inc. 1
POLYMEDIS SA 2
Practice Partner 2
QuadraMed 1
Quovadx 2
Sago spa 2
SeeBeyond Technology Corporation 1
SIEMENS Medical Solutions 7
Softmedical 2
SQLI 3
St. Jude Medical AB 2
Symphonie On Line 2
Synapsis 3
Tiani-Spirit Gmbh 10
T-Systems Austria GesmbH 6
WebMD Practice Services 1
4 Europe 2004
Patient Identity Cross-reference
Manager
Patient Identity Consumer
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Tabelle 11: IHE Connectathon Resultate für das Integrationsprofil PIX
Seite 50 von 50
9.6.1 Aufbau der Tabelle
Die obenstehende Tabelle beschreibt das Resultat sämtlicher Connectathons bezüglich des IHE Integrationsprofils PIX. Sie entstand von einem Export der Connectathon Resultate von der IHE Europe Webpage
und wurde mit der Anzahl Nennungen ergänzt.
Produkte, welche für die Implementation eines Consumers, eines Cross Reference Managers oder einer
Source eingesetzt werden können, müssen unter der Spalte „Patient Identity Cross Reference Manager“
aufgeführt sein.
In der ersten Spalte sind alle beteiligten Firmen aufgeführt, deren Systeme die Tests am Connectathon erfolgreich bestanden haben.
Leider sind keine Produkte resp. Systemnamen aufgeführt. Das führt dazu, dass in aufwendiger Kleinarbeit
in den IHE Integrationsprofilen nach den Systemen gesucht werden muss, welche genau die Anforderungen
des entsprechenden Akteurs eines Integrationsprofils erfüllen. So erhält man bei der Firma GE Healthcare
den Eindruck, dass ihre Systeme sehr gut den Akteur Patient Identity Consumer erfüllen, da in sämtlichen
Jahren die erforderlichen Funktionalitäten erfolgreich getestet werden konnten. Bei der Recherche in den
Integration Statements der GE ist dann aber ersichtlich, dass es sich dabei um das Produkt Centricity Enterprise Archive handelt, welches von GE Healthcare als Langzeitarchiv für die eigene PACS Lösung verkauft
wird.
9.6.2 Interpretationen der Resultate
Im Allgemeinen fällt auf, dass es einige Systeme hat, die als Patient Identity Consumer agieren können. Es
ist auch auffallend, dass gerade am Connectathon USA 2007 einige Systeme hinzugekommen sind. Das
könnte die Vermutung stärken, dass in den USA mit dem Aufbau von so genannten RHIOs (Regional Health
Information Organisations) die einheitliche Patientenidentifikation eine immer grösser werdende Herausforderung darstellt.
Die Auswahl an Firmen die Produkte für einen Cross Reference Manager zur Verfügung stellen, ist hingegen
ziemlich gering. Einzig Tiani Spirit GmbH scheint ein Produkt liefern zu können, das schon an mehreren
Connectathons getestet wurde.
Auffallend ist auch, dass am europäischen Connectathon 2007 nur eine einzige Firma (Carestream ehemals
Kodak) ein System für den Akteur Patient Identity Source getestet hat. In den USA waren es doch immerhin
9 Firmen, wobei einzig Siemens ein Patienteninformationssystem (Clinicom) getestet hat, welches auch in
Europa verfügbar ist.
9.6.3 Mögliche Rückschlüsse für den Kanton St. Gallen
Wenn man diejenigen Systeme analysiert, welche von der Gruppe Service Center IT (SSC-IT) und des Kantons St. Gallen betrieben werden, stellt man fest, dass für die Umsetzung des Integrationsprofils PIX noch
einige Lücken bestehen. Im Pilotprojekt MeDIswiss ist mit Tiani Spirit GmbH eine Firma vertreten, die schon
jahrelange Erfahrungen mit IHE und dem Integrationsprofil PIX mitbringt und unter anderem im österreichischen Projekt Nömed WAN eingesetzt wird. Das Produkt Cloverleaf von Quovadx kann die Schnittstelle für
einen Patient Identity Consumer abbilden. Was fehlt ist ein System, das die Patientenidentifikationen registriert.
Konkret kann mit dem Produkt EPA (XDS) von Tiani Spirit GmbH die Funktionalität des Cross Reference
Managers erstellt werden. Es müsste noch abgeklärt werden, wie weit die zusätzlichen Funktionalitäten für
einen MPI verfügbar sind. MedFolio von Nexus und auch SAP können via die Datendrehscheibe Cloverleaf
die Patientenidentifikationen empfangen. Hingegen hat weder Nexus noch SAP die Funktionalität des Akteurs Patient Identity Source getestet. Dieses Manko könnte höchstwahrscheinlich ebenfalls via die Datendrehscheibe Cloverleaf von Quovadx gelöst werden, da diese Nachrichten auf dem HL7 Standard aufbauen.
Zusammen mit dem Realisierungskonzept soll deshalb auch eine entsprechende Produktevaluation durchgeführt werden (siehe Massnahme M8).
Seite 51 von 51

grobkonzept - Portal Kanton St.Gallen

Transcription

Similar documents

- E-HEALTH-COM

PDF - Psychiatrie

ELGA- Gesamtarchitektur

PDF-Download - HL7 Deutschland eV

CartaServizi_2012_Deu 1 MB

Martin Ulrich - TAXI Magazin

Ryder Cup