MPI/Kommunikationsserver
Werbung
Slide 1
Extended
Master Patient Index
KOMPASS
Konzept für einen systemübergreifenden Datenaustauch
Slide 2
Definition MPI
Der Master Patient Index (MPI) ist ein Konzept zur
Überwindung der Schranken zwischen IT-Lösungen
verschiedener Hersteller oder Generationen ohne
Gefährdung des Patienten. Dazu wird ein Index verwaltet,
welcher möglichst alle bekannten und vergebenen
Identitäten eines Patienten aus verschiedenen Bereichen
(Krankenhäusern, Abteilungen eines Krankenhauses,
Arztpraxen etc.) referieren soll. Ein MPI dient dazu, die
Information aus den verschiedenen Quellen unter einer
gemeinsamen Identität (einem Index) auch übergreifend
über aufeinanderfolgende Fälle desselben Patienten
aufzufinden. (Quelle Wikipedia.de)
Slide 3
MPI (Master-Patient-Index)
• Basis des MPI ist eine SQL Datenbank (Open
Source PostgreSQL)
• Unterstützung verschiedener IHE (Integrating the
Healthcare Enterprise) Standards
- PIX = Patient Identifier Cross-Reference
- PDQ = Patient Demographics Query
• Finden von Patientenidentitäten durch
definierbare Übereinstimmungskriterien
• Nutzung vorhandener Schnittstellen (HL7, GDT,
DICOM, etc.)
Slide 4
Funktionalität des MPI
• Der MPI importiert initial einen möglichst umfassenden
Datenbestand der Patientendaten aller Subsysteme, die eine
eigene Patienten-ID generieren
• Alle neuen und geänderten Patientendaten müssen nun
redundant durch den MPI verarbeitet werden. Dabei kann
jedes Subsystem seine eigenen Patientenkennungen weiter
verwenden. Der Patient erhält im MPI eine übergeordnete ID.
• Durch entsprechende Algorithmen werden Patientendaten
abgeglichen und zugeordnet. Nicht zuzuordnende Daten
müssen manuell bearbeitet werden.
Slide 5
Schnittstellen des MPI
• Verwendung von allgemeingültigen Standards
aus dem medizinischen, bzw. Internet Umfeld
- HL7, GDT, BDT, LDT, DICOM, XML, JSON, REST
• Zusätzlich wird eine Datenbankschnittstelle
zur Verfügung gestellt, auf die per ODBC oder
JDBC ausschließlich lesend zugegriffen werden
kann. Die Zugriffsrechte dazu sind
rollenbasiert fein justierbar
Slide 6
Verwaltung des MPI
• Der MPI verwaltet sich größtenteils selbst ;-)
• Ein Wartungsaufwand fällt durch nicht
automatisch zugeordnete Patientendaten an.
Der Anwender sollte die Zuordnungen
möglichst innerhalb einer Weboberfläche
erledigen können
• Ebenso sollte das Zusammenlegen von
verschiedenen Patientenidentitäten nur
manuell erfolgen können
Slide 7
Slide 8
Notwendigkeit eines Kom-Servers
• Das Vorhandensein eines MPI ist lediglich eine zwingende
Voraussetzung für die mögliche Kommunikation der
Subsysteme untereinander.
• Gewünscht wird aber in der Regel eine (begrenzte) Zugriffsmöglichkeit auf die in den jeweils anderen Subsystemen
enthaltenen Daten.
• Dafür wird eine zentrale Software benötigt, die diesen Zugriff
steuert. Alle angeschlossenen Systeme sollen dafür möglichst
wenig individuellen Aufwand treiben müssen und damit auch
keine Blockade oder Verzögerung erreichen können.
Slide 9
Möglichkeiten des Kom-Servers
• Alle angeschlossenen Systeme können über eine entsprechend
formulierte Anfrage alle (autorisierten und publizierten) Daten ihres
Patienten erhalten. Die Anfrage kann aus dem jeweiligen System heraus
oder durch eine vorbereitete Webseite erfolgen. Das Ergebnis der Anfrage
kann in jedem gewünschten Format zurückgeliefert werden (siehe Demo).
• Standardmäßig sollte jedes System eine Webseite oder eine PDF-Datei
darstellen können.
• Ergebnisseiten können aber auch Links auf andere Inhalte (z.B. im DMS)
enthalten, inklusive spezieller Programmaufrufe (z.B. für das PACS)
• Neue Funktionalität, bzw. neue Systeme können mit geringem Aufwand
integriert werden (z.B. Nachverfolgung vom aktuellen Standort von
Patientenakten, etc.)
Slide 10
„Grenzen“ des Kom-Servers
• Da der Kom-Server nicht alle Daten aller Systeme redundant importiert,
kann er auf Anfragen primär nur die Daten liefern, die er bereits selbst
verwaltet.
• Zusätzlich kann er aber auch zentrale Konvertierungen anbieten, die
ansonsten jedes System umsetzen müsste. Somit könnte z.B. aus der
Nexus Umgebung heraus auf alle ambulanten Befunde eines Patienten
zugegriffen werden, den es bereits in MacDoc gibt (Zuordnung der
Identitäten durch den MPI -> SQL-Anfrage an MacDoc ob es Befunde gibt
-> Erzeugung einer Ergebnisliste mit anklickbaren Links auf ins RTF- oder
HTML-Format gewandelten Befunden). Umgekehrt stehen aufgrund aller
empfangenen und gespeicherten HL7 Nachrichten viele stationäre
Informationen allen anderen Systemen zur Verfügung (stationäre
Aufenthalte, ICDs, ICPMs, AccessionNumbers von Untersuchungen im
PACS, die von Nexus erzeugt worden sind, etc.)
Slide 11
Mac Software Design GmbH
Zum Erlenbusch 16
148167 Münster
Tel.: 0251 – 626712
Fax: 0251 – 61338
URL: www.msdesign.de
E-Mail: [email protected]
Extended
Master Patient Index
KOMPASS
Konzept für einen systemübergreifenden Datenaustauch
Slide 2
Definition MPI
Der Master Patient Index (MPI) ist ein Konzept zur
Überwindung der Schranken zwischen IT-Lösungen
verschiedener Hersteller oder Generationen ohne
Gefährdung des Patienten. Dazu wird ein Index verwaltet,
welcher möglichst alle bekannten und vergebenen
Identitäten eines Patienten aus verschiedenen Bereichen
(Krankenhäusern, Abteilungen eines Krankenhauses,
Arztpraxen etc.) referieren soll. Ein MPI dient dazu, die
Information aus den verschiedenen Quellen unter einer
gemeinsamen Identität (einem Index) auch übergreifend
über aufeinanderfolgende Fälle desselben Patienten
aufzufinden. (Quelle Wikipedia.de)
Slide 3
MPI (Master-Patient-Index)
• Basis des MPI ist eine SQL Datenbank (Open
Source PostgreSQL)
• Unterstützung verschiedener IHE (Integrating the
Healthcare Enterprise) Standards
- PIX = Patient Identifier Cross-Reference
- PDQ = Patient Demographics Query
• Finden von Patientenidentitäten durch
definierbare Übereinstimmungskriterien
• Nutzung vorhandener Schnittstellen (HL7, GDT,
DICOM, etc.)
Slide 4
Funktionalität des MPI
• Der MPI importiert initial einen möglichst umfassenden
Datenbestand der Patientendaten aller Subsysteme, die eine
eigene Patienten-ID generieren
• Alle neuen und geänderten Patientendaten müssen nun
redundant durch den MPI verarbeitet werden. Dabei kann
jedes Subsystem seine eigenen Patientenkennungen weiter
verwenden. Der Patient erhält im MPI eine übergeordnete ID.
• Durch entsprechende Algorithmen werden Patientendaten
abgeglichen und zugeordnet. Nicht zuzuordnende Daten
müssen manuell bearbeitet werden.
Slide 5
Schnittstellen des MPI
• Verwendung von allgemeingültigen Standards
aus dem medizinischen, bzw. Internet Umfeld
- HL7, GDT, BDT, LDT, DICOM, XML, JSON, REST
• Zusätzlich wird eine Datenbankschnittstelle
zur Verfügung gestellt, auf die per ODBC oder
JDBC ausschließlich lesend zugegriffen werden
kann. Die Zugriffsrechte dazu sind
rollenbasiert fein justierbar
Slide 6
Verwaltung des MPI
• Der MPI verwaltet sich größtenteils selbst ;-)
• Ein Wartungsaufwand fällt durch nicht
automatisch zugeordnete Patientendaten an.
Der Anwender sollte die Zuordnungen
möglichst innerhalb einer Weboberfläche
erledigen können
• Ebenso sollte das Zusammenlegen von
verschiedenen Patientenidentitäten nur
manuell erfolgen können
Slide 7
Slide 8
Notwendigkeit eines Kom-Servers
• Das Vorhandensein eines MPI ist lediglich eine zwingende
Voraussetzung für die mögliche Kommunikation der
Subsysteme untereinander.
• Gewünscht wird aber in der Regel eine (begrenzte) Zugriffsmöglichkeit auf die in den jeweils anderen Subsystemen
enthaltenen Daten.
• Dafür wird eine zentrale Software benötigt, die diesen Zugriff
steuert. Alle angeschlossenen Systeme sollen dafür möglichst
wenig individuellen Aufwand treiben müssen und damit auch
keine Blockade oder Verzögerung erreichen können.
Slide 9
Möglichkeiten des Kom-Servers
• Alle angeschlossenen Systeme können über eine entsprechend
formulierte Anfrage alle (autorisierten und publizierten) Daten ihres
Patienten erhalten. Die Anfrage kann aus dem jeweiligen System heraus
oder durch eine vorbereitete Webseite erfolgen. Das Ergebnis der Anfrage
kann in jedem gewünschten Format zurückgeliefert werden (siehe Demo).
• Standardmäßig sollte jedes System eine Webseite oder eine PDF-Datei
darstellen können.
• Ergebnisseiten können aber auch Links auf andere Inhalte (z.B. im DMS)
enthalten, inklusive spezieller Programmaufrufe (z.B. für das PACS)
• Neue Funktionalität, bzw. neue Systeme können mit geringem Aufwand
integriert werden (z.B. Nachverfolgung vom aktuellen Standort von
Patientenakten, etc.)
Slide 10
„Grenzen“ des Kom-Servers
• Da der Kom-Server nicht alle Daten aller Systeme redundant importiert,
kann er auf Anfragen primär nur die Daten liefern, die er bereits selbst
verwaltet.
• Zusätzlich kann er aber auch zentrale Konvertierungen anbieten, die
ansonsten jedes System umsetzen müsste. Somit könnte z.B. aus der
Nexus Umgebung heraus auf alle ambulanten Befunde eines Patienten
zugegriffen werden, den es bereits in MacDoc gibt (Zuordnung der
Identitäten durch den MPI -> SQL-Anfrage an MacDoc ob es Befunde gibt
-> Erzeugung einer Ergebnisliste mit anklickbaren Links auf ins RTF- oder
HTML-Format gewandelten Befunden). Umgekehrt stehen aufgrund aller
empfangenen und gespeicherten HL7 Nachrichten viele stationäre
Informationen allen anderen Systemen zur Verfügung (stationäre
Aufenthalte, ICDs, ICPMs, AccessionNumbers von Untersuchungen im
PACS, die von Nexus erzeugt worden sind, etc.)
Slide 11
Mac Software Design GmbH
Zum Erlenbusch 16
148167 Münster
Tel.: 0251 – 626712
Fax: 0251 – 61338
URL: www.msdesign.de
E-Mail: [email protected]
