GROBKONZEPT. Master Patient Index. 07. September 2007, Version 1.2 (freigegeben) medshare GmbH Speckhubel Höfen b. Thun

Transkript

1 GROBKONZEPT Master Patient Index 07. September 2007, Version 1.2 (freigegeben) medshare GmbH Speckhubel Höfen b. Thun Switzerland phone: fax:

2 Dokumentinformationen Auftraggeber Kontaktperson des Auftraggebers Gesundheitsdepartement St. Gallen Moosbruggstrasse 11, 9001 St. Gallen Hansjörg Looser Telefon: Autoren / Ansprechpartner medshare GmbH Tony Schaller Telefon: tony.schaller@medshare.net Christoph Knoepfel Telefon: christoph.knoepfel@medshare.net Datum 07. September 2007 Version Version 1.2 (freigegeben) Dokumentgeschichte Version 1.2 freigegeben am 07. September 2007 durch Hansjörg Looser Seite 2 von 2

3 Inhalt Dokumentinformationen... 2 Inhalt Management Summary Ausgangslage Zielsetzung Abgrenzung Grundlagen (Basistechnologien) HL Reference Information Model (RIM) VHitG Initiative Intersektorale Kommunikation VHitG PID Profil: Konzept zur Patientenidentifikation IHE Initiative IHE Patient Identity Cross Referencing (PIX) Beziehung zwischen dem IHE Integrationsprofil PIX und der Verwaltung eines MPI IHE Consistent Time (CT) IHE Audit Trail and Node Authentication (ATNA) Object Identifier (OID) Beispiel Patientenidentifikation Beispiel Diagnose HL7 OID in der Schweiz Routing im Internet Alternative Grundlagen ISO/TC CEN/TC Schweizerische Normenvereinigung (SNV) Blick ins benachbarte Ausland Deutschland Österreich Frankreich Italien Kanada Lösungskonzept Klinisches Szenario Business Use Cases Anmeldung einer Untersuchung Abklärung der Kostengutsprache Auskunft zum Krankheitsverlauf Behandlung eines Patienten abschliessen Abhängigkeiten zur Performance der Systeme Patientenanmeldung Diagnostik Zu empfehlende Anforderungen an die Systemlandschaft System- und Projektlandschaft des Auftraggebers Konzeptvorschlag SWOT des Konzeptvorschlages Umsetzungskonzept MPI Service Provider Organisationsform MPI Datenbank Automatisierbarer Zusammenführungsmechanismus Architektur Organisatorisch Administration MPI Service Provider Register und Institutionen Datenschutz Etappierung Seite 3 von 3

4 7.3.5 Aufgabenteilung, Kosten und Finanzierung Technisch Betrieb MPI Service Provider - Webservices Semantik Sicherheit Gegenüberstellung des Umsetzungskonzepts zum klinischen Szenario Weiteres Vorgehen Bezug zur ehealth Strategie Roadmap Massnahmenkatalog Mögliche Umsetzung der Massnahmen Anhang Referenzierte Dokumente Abkürzungen und Glossar Abbildungsverzeichnis Tabellenverzeichnis HL7 Reference Information Model (RIM) IHE Connectathon Resultate für das Integrationsprofil PIX Aufbau der Tabelle Interpretationen der Resultate Mögliche Rückschlüsse für den Kanton St. Gallen Seite 4 von 4

5 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

6 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

7 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: 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

8 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 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

9 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. 3.3 IHE Initiative Abbildung 3: PID Akteure und Transaktionen 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

10 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 ( 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

11 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

12 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: 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 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 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

13 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

14 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 oder abrufbar (zuletzt besucht am ). Seite 14 von 14

15 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: ist die Root OID der Organisation, in welcher der Patient mit der Nummer 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=" " root=" "/> Beispiel Diagnose Tabelle 1: OID Beispiel Patientenidentifikation 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: ist die OID für das Codiersystem ICD10. Die Diagnose Appendizitis hat den ICD 10 Code I Eine entsprechende XML Repräsentation ist: <value code="i59.13" codesystem=" "/> HL7 OID in der Schweiz Die Wurzel OID für HL7 Schweiz lautet: Tabelle 2: OID Beispiel Diagnose 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

16 Abbildung 8: Hybrides hierarchisches Feld-Relais-Internetwork (Quelle: 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 Routing- Domain 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 Ziel- Domain 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: Seite 16 von 16

17 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 spezischen Nachrichtenmodellen einschliesslich Patientenkarten. WG II Konzepte und Terminologie Deniert 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. Zusammenlegung mit HL7 1 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: zuletzt besucht am Seite 17 von 17

18 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

19 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: Seite 19 von 19

20 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: 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: 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: Seite 20 von 20

21 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: Seite 21 von 21

22 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: Sturz im Treppenhaus 1. Befund: Patient klagt über starke Kopfschmerzen Vitalwerte: 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

23 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