1 / 11

Extended Master Patient Index

Extended Master Patient Index. KOMPASS. Konzept für einen systemübergreifenden Datenaustauch. Definition MPI.

nassor
Download Presentation

Extended Master Patient Index

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extended Master Patient Index KOMPASS Konzept für einen systemübergreifenden Datenaustauch

  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 einIndex 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)

  3. MPI (Master-Patient-Index) • Basis des MPI ist eine SQL Datenbank (Open Source PostgreSQL) • Unterstützung verschiedener IHE (IntegratingtheHealthcareEnterprise) Standards- PIX = Patient Identifier Cross-Reference- PDQ = Patient DemographicsQuery • Finden von Patientenidentitäten durch definierbare Übereinstimmungskriterien • Nutzung vorhandener Schnittstellen (HL7, GDT, DICOM, etc.)

  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.

  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

  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

  7. 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) Zugriffs-mö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.

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

  9. „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.)

  10. Mac Software Design GmbH Zum Erlenbusch 16 148167 Münster Tel.: 0251 – 626712 Fax: 0251 – 61338 URL: www.msdesign.de E-Mail: info@msdesign.de

More Related