PIX

Aus Hl7wiki
(Teildokument von IHE Cookbook)
Wechseln zu: Navigation, Suche
Dieses Material ist Teil des Leitfadens IHE Cookbook.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .


IHE Patient Identifier Cross-referencing (PIX)

Das IHE-Profil Patient Identifier Cross-referencing (PIX) ermöglicht die Verknüpfung von Patientenkennungen in einem Netzwerk von Einrichtungen, die für einen Patienten jeweils eigene Kennungen vergeben. Dafür werden dem sogenannten Patient Identifier Cross-reference Manager (PIX Manager) demographische Patientendaten und IDs übergeben. Der PIX Manager verlinkt dann die Einträge für gleiche Patienten aus unterschiedlichen Einrichtungen. Ein System, welches als Patient Identifier Cross-reference Consumer agiert, kann sich die Verknüpfungen entweder beim PIX Manager mit Hilfe einer bekannten ID aktiv anfragen oder (optional) sich darüber informieren lassen. Das PIX-Profil stellt damit eine Grundlage für den einrichtungsübergreifenden Dokumenten- und Bildaustausch auf Basis von XDS.b und XDS-I.b dar, da über dieses Profil die Daten aus unterschiedlichen Einrichtungen mit unterschiedlichen IDs für einen Patienten zusammengeführt werden können.

IHE cookbook pix.png

In der Praxis fungiert der PIX Manager in der Regel als Master Patient Index und stellt eine in der XDS Affinity Domain eindeutige Master Patient ID, die sogenannte XAD-Pid zu Verfügung. Durch diese Verbindung von PIX Manager und XDS.b Patient Identity Source wird die Zuordnung lokal verwendeter Patientenkennungen zur einrichtungsübergreifend eindeutigen Master Patient ID möglich. Diese Master Patient ID kann in weiterer Folge zu Suche und Abruf von Dokumenten und radiologischen Bildern, sowie zur domänenweiten Protokollierung verwendet werden (siehe auch XDS.b).

Der PIX Manager erlaubt somit die Verwendung einer lokalen, in einer Einrichtung verwendeten Patienten-ID sowohl

  1. zum Abruf der Master Patient ID, als auch
  2. zum Abruf der in den anderen Einrichtungen verwendeten lokalen Patienten-IDs
  3. zum Abruf der in den anderen Affinity Domains verwendeten XAD-PIDs

Jeder Patient wird im PIX Manager als eine Patientenidentität gespeichert, die demographische Daten des Patienten, die Master Patient ID, sowie dessen lokale IDs enthält. Der PIX Manager verknüpft mehrere lokale Patienten IDs, die von unterschiedlichen Einrichtungen zu einer Patientenidentität gemeldet wurden miteinander und bildet somit zusammen mit der Master Patient ID eine Linkgruppe. Die Bildung der Linkgruppe (die Erkennung, dass es sich bei den gemeldeten lokalen Patientenidentitäten um denselben physischen Patienten handelt) erfolgt anhand der demographischen Daten wie z.B. Vorname, Nachname, Versicherungsnummer, Geburtsdatum und Geschlecht.

Die vom PIX-Manager erzeugte XAD-PID kann in den Szenarien verwendet werden, wenn die beteiligten Einrichtungen Zugriff auf denselben PIX-Manager haben.

Die IHE bietet 2 Versionen des PIX Profiles an, die sich auf die Schnittstellen beziehen. PIX ohne Versionszusatz bezeichnet HL7v2 Schnittstellen, PIXv3 bezeichnet HL7v3 Schnittstellen. Für die Transaktion Patient Identity Feed lauten die Transaktionskennungen ITI-8 (HL7v2) und ITI-44 (HL7v3). Für die PIX Query lauten die Transaktionskennungen ITI-9 (HL7v2) und ITI-45 (HL7v3). Für die Auswahl des entsprechenden Profils (HL7v2 oder HL7v3) im Rahmen der Umsetzung sollten folgende Aspekte berücksichtigt werden. Für die einrichtungsinterne Kommunikation (Patient Identity Source – Document Source / Document Consumer) können die heute von vielen Systemen unterstützten HL7v2-Schnittstellen eingesetzt werden. Für die einrichtungsübergreifende Kommunikation (Patient Identity Source / Document Source / Document Consumer – PIX Manager) sollten die auf Webservices basierenden HL7v3 Schnittstellen eingesetzt werden, was folgende Vorteile bringt:

  • Netzwerk und Firewall: Webservices verwenden Standard HTTP(s) Ports und keine TCP Socket Verbindungen wie bei HL7v2
  • Die Verschlüsselung über HTTP(s) ist einfacher umzusetzen als für HL7v2 Nachrichten (wird von gängigen Applicationservern unterstützt).
  • Security Token für das Berechtigungssystem können im Soap Header der Webservice Nachricht integriert werden. Für HL7v2 stehen diese Möglichkeiten nicht zur Verfügung.