DE112022003325T5 - Schnittstelle zwischen einer herzpumpen-controller-datenbank und einem krankenhaus - Google Patents

Schnittstelle zwischen einer herzpumpen-controller-datenbank und einem krankenhaus Download PDF

Info

Publication number
DE112022003325T5
DE112022003325T5 DE112022003325.8T DE112022003325T DE112022003325T5 DE 112022003325 T5 DE112022003325 T5 DE 112022003325T5 DE 112022003325 T DE112022003325 T DE 112022003325T DE 112022003325 T5 DE112022003325 T5 DE 112022003325T5
Authority
DE
Germany
Prior art keywords
data
heart pump
identifier
cloud
emr
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112022003325.8T
Other languages
English (en)
Inventor
Dawn Bardot
Ahmad El Katerji
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Abiomed Inc
Original Assignee
Abiomed Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Abiomed Inc filed Critical Abiomed Inc
Publication of DE112022003325T5 publication Critical patent/DE112022003325T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M1/00—Suction or pumping devices for medical purposes; Devices for carrying-off, for treatment of, or for carrying-over, body-liquids; Drainage systems
    • A61M1/36—Other treatment of blood in a by-pass of the natural circulatory system, e.g. temperature adaptation, irradiation ; Extra-corporeal blood circuits
    • A61M1/3621—Extra-corporeal blood circuits
    • A61M1/3666—Cardiac or cardiopulmonary bypass, e.g. heart-lung machines
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/40—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to mechanical, radiation or invasive therapies, e.g. surgery, laser therapy, dialysis or acupuncture
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Cardiology (AREA)
  • Vascular Medicine (AREA)
  • Hematology (AREA)
  • Pulmonology (AREA)
  • Anesthesiology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Urology & Nephrology (AREA)
  • Surgery (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • External Artificial Organs (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Eine elektronische Schnittstelle erleichtert die automatische Übertragung von Daten aus einer Herzpumpen-Controller-Datenbank an ein EMR-System, wodurch die Notwendigkeit für das Pflegepersonal, die Betriebsdaten der Herzpumpe manuell vom Bildschirm eines Herzpumpen-Controllers in das EMR-System zu übertragen, verringert oder beseitigt wird. Einige Ausführungsformen verringern oder beseitigen die Notwendigkeit, einen Patienten regelmäßig zu besuchen, um die Betriebsdaten aufzuzeichnen. Stattdessen kann die Schnittstelle, sobald sie programmiert ist, die Betriebsdaten automatisch und regelmäßig an das EMR-System senden.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Diese Anmeldung beansprucht den Nutzen und die Priorität der vorläufigen US-Anmeldung Nr. 63/216,931 , die am 30. Juni 2021 beim US-Patentamt eingereicht wurde und durch Bezugnahme hierin aufgenommen ist.
  • TECHNISCHER BEREICH
  • Die vorliegende Erfindung bezieht sich auf eine elektronische Schnittstelle zwischen verschiedenen medizinischen Systemen und insbesondere auf eine elektronische Schnittstelle zwischen einer Datenbank des Herzpumpen-Controllers und einem elektronischen medizinischen Aufzeichnungssystem (EMR), wobei die Schnittstelle automatisch die Übertragung von Daten von der Datenbank des Herzpumpen-Controllers zum EMR-System erleichtert.
  • HINTERGRUND DER ERFINDUNG
  • Eine intravaskuläre Blutpumpe ist eine Pumpe, die durch das Blutkreislaufsystem eines Patienten, d. h. durch Venen und/oder Arterien, zu einer Stelle im Herzen des Patienten oder an einer anderen Stelle im Kreislaufsystem des Patienten vorgeschoben werden kann. So kann beispielsweise eine intravaskuläre Blutpumpe über einen Katheter eingeführt und so positioniert werden, dass sie eine Herzklappe überspannt. Die intravaskuläre Blutpumpe befindet sich in der Regel am Ende des Katheters. Sobald sie in Position ist, kann die Pumpe dazu verwendet werden, Blut durch das Kreislaufsystem zu pumpen und so die Arbeitsbelastung des Herzens des Patienten vorübergehend zu verringern, beispielsweise um dem Herzen zu ermöglichen, sich nach einem Herzinfarkt zu erholen. Eine beispielhafte intravaskuläre Blutpumpe ist von Abiomed, Inc. in Danvers, MA, unter dem Markennamen Impella® Herzpumpe erhältlich.
  • Jede intravaskuläre Blutpumpe ist in der Regel mit einem entsprechenden externen Herzpumpen-Controller verbunden, der die Herzpumpe steuert, z. B. die Motordrehzahl, und der Betriebsdaten über die Blutpumpe sammelt und anzeigt, z. B. Herzsignalpegel, Batterietemperatur, Blutflussrate und Leitungsintegrität. Ein beispielhafter Herzpumpen-Controller ist von Abiomed, Inc. unter dem Handelsnamen Automated Impella Controller® erhältlich. Der Controller löst Alarm aus, wenn die Betriebsdatenwerte vorgegebene Werte oder Bereiche überschreiten, z. B. wenn ein Leck oder ein Saugverlust erkannt wird. Der Controller verfügt über einen Videobildschirm als menschliche Benutzerschnittstelle, auf dem die Betriebsdaten und/oder Alarme angezeigt werden.
  • Ein elektronisches medizinisches Aufzeichnungssystem (EMR) speichert und erleichtert die Eingabe von Informationen über Patienten, in der Regel über einen Computerterminal. Im Wesentlichen ist ein EMR-System ein elektronisches Äquivalent zu Papierakten, Krankenblättern, Notizen des Arztes usw. In einem EMR-System werden in der Regel allgemeine Informationen über den Patienten gespeichert, z. B. nächster Angehöriger, Name des Arztes, verschriebene Medikamente und andere aktuelle Behandlungen sowie die Krankengeschichte, einschließlich der Ergebnisse diagnostischer Tests wie Blutdruck, Pulsfrequenz und Labortests. EMR-Daten werden im Laufe der Zeit eingegeben, da diese Informationen von den einzelnen Ärzten gesammelt werden. Die Informationen in einem EMR-System sind für die Ärzte hilfreich, manchmal sogar lebenswichtig, um den Fortschritt eines Patienten zu überprüfen und seine Behandlung zu planen.
  • Ein Patient mit einer intravaskulären Blutpumpe befindet sich in der Regel in einem kritischen Zustand und muss daher häufig überwacht werden, da sich der Zustand des Patienten (z. B. Puls, Blutdruck usw.) sehr schnell, manchmal innerhalb weniger Minuten, dramatisch verändern kann. Änderungen im Zustand des Patienten können Änderungen der Betriebsparameter der Blutpumpe, Änderungen der Medikation usw. erforderlich machen. Da sich die Ärzte auf die im EMR gespeicherten Informationen über den Patienten verlassen, sollte das EMR zeitnah und häufig aktualisiert werden.
  • Um das EMR auf dem neuesten Stand zu halten, ist jedoch üblicherweise ein arbeitsintensiver und ungenauer manueller Prozess erforderlich. Um das EMR des Patienten auf dem neuesten Stand zu halten, besucht eine Krankenschwester oder ein Techniker regelmäßig das Krankenzimmer des Patienten, zeichnet die auf dem Bildschirm des Herzpumpen-Controllers angezeigten Betriebsdaten auf Papier auf und geht dann zu einem Computerterminal, in der Regel auf einer Pflegestation, und gibt die gesammelten Betriebsdaten in das EMR-System ein.
  • Die Krankenschwestern und die Techniker sind jedoch zunehmend mit der Betreuung anderer Patienten beschäftigt. Daher ist es schwierig, in regelmäßigen Intervallen in das Zimmer des Herzpumpen-Patienten zurückzukehren, um die Betriebsdaten zu erfassen. Außerdem befindet sich der Herzpumpen-Patient, wie bereits erwähnt, in einem kritischen Zustand und braucht daher Ruhe. Häufige Besucher im Patientenzimmer stören die Ruhe des Patienten. Außerdem ist die manuelle Aufzeichnung der Betriebsdaten auf dem Bildschirm und die anschließende manuelle Eingabe der erfassten Betriebsdaten in das EMR-System fehleranfällig.
  • Darüber hinaus werden Daten, die manuell in ein EMR-System eingegeben werden, in der Regel als unstrukturierte (Freitext-)Daten gespeichert, die von anderen Systemen nicht gelesen werden können, manchmal sogar von Systemen, die hochentwickelte natürliche Sprachprozessoren enthalten. Beispielsweise sind unstrukturierte Patientendaten in einem Krankenhaus-EMR-System wahrscheinlich nur von begrenztem Nutzen, wenn der Patient in ein anderes Krankenhaus verlegt oder später aufgenommen wird.
  • Andererseits folgen strukturierte Daten einem vorgeschriebenen Datenmodell und Wertesatz, wodurch die Benutzer beispielsweise gezwungen sind, nur vorher festgelegte Werte oder Werttypen oder ein kontrolliertes Vokabular einzugeben oder auszuwählen. Ein Stück strukturierter Daten besteht aus zwei Teilen: einem variablen Namen und einem Wert, z. B. „Höhe: 71“. Strukturierte Daten können von mehreren Systemen verwendet werden, z. B. von Datenbanken in mehreren Krankenhäusern und Arztpraxen. Die korrekte manuelle Eingabe strukturierter Daten in ein EMR-System ist nicht immer möglich und auf jeden Fall viel schwieriger als die Eingabe unstrukturierter Daten.
  • Dennoch sind die Ärzte des Patienten auf rechtzeitige und vollständige Informationen im EMR-System angewiesen, um den Patienten zu überwachen und Entscheidungen über die Anpassung der Behandlung des Patienten zu informieren. Leider hindert der Stand der Technik die Ärzte weitgehend daran, die benötigten zeitnahen und genauen Informationen zu erhalten. Ein technisches Problem des Stands der Technik ist daher die zeitnahe und idealerweise automatische Erfassung von Informationen über Herzpumpen-Patienten und Herzpumpen und die Speicherung der erfassten Informationen als strukturierte Daten in einem EMR.
  • KURZE ZUSAMMENFASSUNG DER ERFINDUNG
  • Ein Aspekt der vorliegenden Offenbarung bezieht sich auf einen Herzpumpen-Datensynchronisierer für zeitkorrelierte Daten. Der Herzpumpen-Datensynchronisierer kann einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und ein Ausgabeportal umfassen, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines elektronischen medizinischen Aufzeichnungssystems (EMR) konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert. Der Herzpumpen-Identifikator kann eine erste Benutzerschnittstelle umfassen, die so konfiguriert ist, dass sie einem Benutzer eine erste Aufforderung zur Eingabe eines lokal eingegebenen Identifikators einer Herzpumpe und/oder eines Patienten mit einer implantierten Herzpumpe anzeigt. Die Netzwerkschnittstelle kann so konfiguriert sein, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen. Der Datenelement-Identifikator kann eine zweite Benutzerschnittstelle enthalten, die so konfiguriert ist, dass sie dem Benutzer eine zweite Aufforderung zur Eingabe einer Zeit und einer Identifikation mindestens eines Datentyps aus der Vielzahl von Datentypen anzeigt, wobei die Zeit und die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden sind. Der Controller kann kommunikativ mit dem Herzpumpen-Identifikator, der Netzwerkschnittstelle und dem Datenelement-Identifikator gekoppelt und so konfiguriert sein, dass er als Reaktion auf den Empfang des lokal eingegebenen Identifikators, der Zeit und der mindestens einen Datentyp-Identifikation den lokal eingegebenen Identifikator, die Zeit, die mindestens eine Datentyp-Identifikation und eine entsprechende Datenanforderung über die Netzwerkschnittstelle an den Cloud-basierten Server sendet. Der Monitor kann kommunikativ mit der Netzwerkschnittstelle gekoppelt und so konfiguriert sein, dass er über die Netzwerkschnittstelle von dem Cloud-basierten Server entsprechende Daten empfängt, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen wurden. Das Ausgabeportal kann kommunikativ mit dem Monitor gekoppelt und so konfiguriert sein, dass es die entsprechenden Daten, die vom Cloud-basierten Server empfangen wurden, dem Benutzer anzeigt.
  • In einigen Implementierungen kann der Herzpumpen-Datensynchronisierer auch einen Datenauswahleinrichtung und einen EMR-Datenaktualisierer umfassen, die beide für die Hinzufügung und den Betrieb innerhalb des EMR-Systems konfiguriert sind. Die Datenauswahleinrichtung kann eine dritte Benutzerschnittstelle enthalten, die so konfiguriert ist, dass sie dem Benutzer eine dritte Aufforderung zur Auswahl mindestens eines Teils der entsprechenden Daten anzeigt, die dem Benutzer angezeigt werden. Der EMR-Datenaktualisierer kann so konfiguriert sein, dass er den ausgewählten mindestens einen Teil der entsprechenden Daten, die dem Benutzer angezeigt werden, als strukturierte Daten im EMR-System in Verbindung mit einem Patienten-Identifikator speichert. In einigen Implementierungen kann der Monitor so konfiguriert sein, dass er über die Netzwerkschnittstelle vom Cloud-basierten Server einen Patienten-Identifikator empfängt, der den Daten entspricht, die vom Cloud-basierten Server als Reaktion auf die Anforderung übertragen wurden, und der EMR-Datenaktualisierer kann so konfiguriert sein, dass er den ausgewählten zumindest einen Teil der entsprechenden Daten im EMR-System in Verbindung mit dem vom Monitor empfangenen Patienten-Identifikator speichert. In einigen Implementierungen kann der lokal eingegebene Identifikator einen Patienten-Identifikator enthalten, und der EMR-Datenaktualisierer kann so konfiguriert sein, dass er den ausgewählten zumindest einen Teil der entsprechenden Daten im EMR-System in Verbindung mit dem lokal eingegebenen Identifikator speichert.
  • In einigen Implementierungen kann jede implantierte Herzpumpe mechanisch mit einem entsprechenden Herzpumpen-Controller gekoppelt sein, der einen Bildschirm umfasst, auf dem Betriebsdaten der implantierten Herzpumpe angezeigt werden, und jeder Herzpumpen-Controller kann so konfiguriert sein, dass er einen jeweiligen Videostrom, der den Inhalt des Bildschirms darstellt, an den Cloud-basierten Server sendet. In einigen Implementierungen werden die historischen zeitkorrelierten Betriebsdaten, die von dem Cloud-basierten Server gespeichert werden, zumindest teilweise von dem Cloud-basierten Server aus den jeweiligen Videoströmen von den jeweiligen Herzpumpen-Controllern abgeleitet. In einigen Implementierungen können die entsprechenden Daten, die der Monitor von dem Cloud-basierten Server empfängt, Nicht-Videodaten sein. In einigen Implementierungen umfasst das Ausgabeportal einen Videosignal-Synthesizer, der so konfiguriert ist, dass er aus den entsprechenden Daten zumindest teilweise einen Videostrom wiederherstellt, um dadurch die entsprechenden Daten dem Benutzer anzuzeigen.
  • In einigen Fällen kann der lokal eingegebene Identifikator eine Seriennummer einer jeweiligen implantierten Herzpumpe enthalten. In einigen Implementierungen kann der lokal eingegebene Identifikator einen Patienten-Identifikator enthalten. In einigen Implementierungen können die historischen Betriebsdaten mindestens eines der folgenden Elemente enthalten: einen von einer Blutpumpe gemessenen Blutdruck, eine Blutpumpen-Motordrehzahl, einen Blutpumpen-Motorstrom, eine Heparin-Infusionsrate durch eine Blutpumpe oder Blutpumpen-Spülinformationen. In einigen Implementierungen kann die Netzwerkschnittstelle so konfiguriert sein, dass sie mit dem Cloud-basierten Server über eine Anwendungsprogrammierschnittstelle (API) kommuniziert, die von dem Cloud-basierten Server bereitgestellt wird.
  • In einigen Implementierungen kann der Herzpumpen-Datensynchronisierer auch einen Scanner enthalten, der so konfiguriert ist, dass er einen Strichcode liest, der einen Herzpumpen-Identifikator darstellt, und den Herzpumpen-Identifikator als lokal eingegebenen Identifikator bereitstellt. In einigen Implementierungen ist der Scanner drahtlos mit dem Herzpumpen-Identifikator gekoppelt. In einigen Ausführungsformen kann der Herzpumpen-Datensynchronisierer auch eine Kamera enthalten, die so konfiguriert ist, dass sie Zeichen liest, die einen Herzpumpen-Identifikator darstellen, und den Herzpumpen-Identifikator als lokal eingegebenen Identifikator bereitstellt. In einigen Implementierungen ist die Kamera drahtlos mit dem Herzpumpen-Identifikator verbunden.
  • Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf einen Herzpumpen-Datensynchronisierer für zeitkorrelierte Daten. Der Herzpumpen-Datensynchronisierer kann einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und einen Datenaktualisierer für elektronische medizinische Aufzeichnungen (EMR) umfassen, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines EMR-Systems konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert. Der Herzpumpen-Identifikator kann eine Benutzerschnittstelle umfassen, die so konfiguriert ist, dass sie einem Benutzer eine erste Aufforderung zur Eingabe eines lokal eingegebenen Identifikators einer Herzpumpe und/oder eines Patienten mit einer implantierten Herzpumpe anzeigt. Die Netzwerkschnittstelle kann so konfiguriert sein, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen. Der Datenelement-Identifikator kann eine Benutzerschnittstelle enthalten, die so konfiguriert ist, dass sie dem Benutzer eine zweite Aufforderung zur Identifizierung mindestens eines Datentyps aus der Vielzahl von Datentypen anzeigt, wobei die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden ist. Der Controller kann kommunikativ mit dem Herzpumpen-Identifikator, der Netzwerkschnittstelle und dem Datenelement-Identifikator gekoppelt und so konfiguriert sein, dass er als Reaktion auf den Empfang des lokal eingegebenen Identifikators und der mindestens einen Datentyp-Identifikation über die Netzwerkschnittstelle den lokal eingegebenen Identifikator, der mindestens eine Datentyp-Identifikation und eine entsprechende Datenanforderung an den Cloud-basierten Server sendet. Der Monitor kann kommunikativ mit der Netzwerkschnittstelle gekoppelt und so konfiguriert sein, dass er über die Netzwerkschnittstelle von dem Cloud-basierten Server entsprechende Daten empfängt, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen wurden. Der EMR-Datenaktualisierer kann so konfiguriert sein, dass er die vom Monitor empfangenen entsprechenden Daten automatisch als strukturierte Daten im EMR-System speichert, und zwar in Verbindung mit einem Patienten, der dem lokal eingegebenen Identifikator zugeordnet ist.
  • In einigen Implementierungen kann die Vielzahl der Datentypen mindestens zwei der Folgendes umfassen: einen von einer Blutpumpe gemessenen Blutdruck, eine Blutpumpen-Motordrehzahl, einen Blutpumpen-Motorstrom, eine Heparin-Infusionsrate durch eine Blutpumpe oder Blutpumpen-Spülinformationen. In einigen Implementierungen ist die Benutzerschnittstelle des Datenelement-Identifikators ferner so konfiguriert, dass der Benutzer in Verbindung mit der Identifikation des mindestens einen Datentyps ein Aktualisierungsintervall eingibt. In einigen Implementierungen ist der Controller ferner so konfiguriert, dass er als Reaktion auf den Empfang des Aktualisierungsintervalls automatisch aktualisierte entsprechende Daten über die Netzwerkschnittstelle von dem Cloud-basierten Server in dem Aktualisierungsintervall anfordert. In einigen Implementierungen ist der EMR-Datenaktualisierer ferner so konfiguriert, dass er die vom Monitor empfangenen aktualisierten entsprechenden Daten in Verbindung mit dem Patienten automatisch als strukturierte Daten im EMR-System speichert.
  • Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein Verfahren zur Steuerung eines Herzpumpen-Datensynchronisierers. Der Herzpumpen-Datensynchronisierer kann einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und ein Ausgabeportal umfassen, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines elektronischen medizinischen Aufzeichnungssystems (EMR) konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert. Die Netzwerkschnittstelle kann so konfiguriert sein, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen. Das Verfahren kann umfassen: Anzeigen, mit einer ersten Benutzerschnittstelle des Herzpumpen-Identifikators, einer ersten Aufforderung an einen Benutzer für einen lokal eingegebenen Identifikator von einer Herzpumpe und/oder einem Patienten mit einer implantierten Herzpumpe; Anzeigen, mit einer zweiten Benutzerschnittstelle des Datenelement-Identifikators, einer zweiten Aufforderung an den Benutzer für eine Zeit und eine Identifikation von mindestens einem Datentyp der Vielzahl von Datentypen, wobei die Zeit und die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden sind; Senden des lokal eingegebenen Identifikators, der Zeit, der mindestens einen Datentyp-Identifikation und einer Anforderung entsprechender Daten an den Cloud-basierten Server mit dem Controller über die Netzwerkschnittstelle; Empfangen entsprechender Daten, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen werden, mit dem Monitor über die Netzwerkschnittstelle; und Anzeigen der entsprechenden Daten für den Benutzer über das Ausgabeportal. In einigen Implementierungen umfasst der Herzpumpen-Datensynchronisierer auch einen EMR-Datenaktualisierer, der für die Hinzufügung zu und den Betrieb innerhalb des EMR-Systems konfiguriert ist, und das Verfahren umfasst auch das Speichern, mit dem EMR-Datenaktualisierer, als strukturierte Daten, in Verbindung mit dem lokal eingegebenen Identifikator, von mindestens einem Teil der entsprechenden Daten, die dem Benutzer angezeigt werden.
  • Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein nichttransitorisches computerlesbares Speichermedium mit darauf gespeicherten Anweisungen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, einen Herzpumpen-Datensynchronisierer zu steuern. Der Herzpumpen-Datensynchronisierer kann einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und ein Ausgabeportal umfassen, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines elektronischen medizinischen Aufzeichnungssystems (EMR) konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und das Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert. Die Netzwerkschnittstelle kann so konfiguriert sein, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen. Die Steuerung des Herzpumpen-Datensynchronisierers kann Folgendes umfassen: Steuern einer ersten Benutzerschnittstelle des Herzpumpen-Identifikators, um einem Benutzer eine erste Aufforderung für einen lokal eingegebenen Identifikator von (a) einer Herzpumpe und/oder (b) einem Patienten mit einer implantierten Herzpumpe anzuzeigen; Steuern einer zweiten Benutzerschnittstelle des Datenelement-Identifikators, um dem Benutzer eine zweite Aufforderung für eine Zeit und eine Identifikation von mindestens einem Datentyp der Vielzahl von Datentypen anzuzeigen, wobei die Zeit und die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden sind; Senden des lokal eingegebenen Identifikators, der Zeit, der mindestens einen Datentyp-Identifikation und einer Anforderung entsprechender Daten über die Netzwerkschnittstelle an den Cloud-basierten Server; und Steuern des Ausgabeportals, um entsprechende Daten anzuzeigen, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen und von dem Monitor über die Netzwerkschnittstelle empfangen wurden. In einigen Implementierungen umfasst der Herzpumpen-Datensynchronisierer auch einen EMR-Datenaktualisierer, der für die Hinzufügung zu und den Betrieb innerhalb des EMR-Systems konfiguriert ist, und die Steuerung des Herzpumpen-Datensynchronisierers umfasst auch das Speichern, mit dem EMR-Datenaktualisierer, als strukturierte Daten, in Verbindung mit dem lokal eingegebenen Identifikator, von mindestens einem Teil der entsprechenden Daten, die dem Benutzer angezeigt werden.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Zum besseren Verständnis der Erfindung wird auf die folgende detaillierte Beschreibung bestimmter Ausführungsformen in Verbindung mit den Zeichnungen verwiesen:
    • 1 ist eine Frontansicht eines Herzpumpen-Controllers nach dem Stand der Technik.
    • 2 ist ein schematisches Blockdiagramm eines Cloud-basierten Systems zur Erfassung von Betriebsdaten von Herzpumpen-Controllern, wie in 1, zur Speicherung der Daten in einem Datenspeicher und zur Bereitstellung der Daten an Überwachungsstationen, wie im Stand der Technik beschrieben.
    • 3 ist eine beispielhafte hypothetische Anzeige, die von einer Überwachungsstation nach 2 gemäß dem Stand der Technik bereitgestellt wird.
    • 4 ist ein schematisches Blockdiagramm eines beispielhaften Herzpumpen-Datensynchronisierers gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 5 zeigt eine Benutzerschnittstelle des Herzpumpen-Datensynchronisierers aus 4 gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 6 zeigt eine Benutzerschnittstelle des Herzpumpen-Datensynchronisierers aus 4 gemäß einer anderen Ausführungsform der vorliegenden Erfindung.
    • 7 ist ein Flussdiagramm, das schematisch die von einem Herzpumpen-Identifikator des Herzpumpen-Datensynchronisierers von 4 durchgeführten Vorgänge gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
    • 8 ist ein Flussdiagramm, das schematisch die von einer Netzwerkschnittstelle des Herzpumpen-Datensynchronisierers aus 4 durchgeführten Vorgänge gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
    • 9 ist ein Flussdiagramm, das schematisch Vorgänge veranschaulicht, die von einem Datenelement-Identifikator des Herzpumpen-Datensynchronisierers von 4 gemäß Ausführungsformen der vorliegenden Erfindung durchgeführt werden.
    • 10 ist ein Flussdiagramm, das schematisch die von einem Controller des Herzpumpen-Datensynchronisierers von 4 durchgeführten Vorgänge gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
    • 11 ist ein Flussdiagramm, das schematisch die von einem Monitor des Herzpumpen-Datensynchronisierers von 4 durchgeführten Vorgänge gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
    • 12 ist ein Flussdiagramm, das schematisch die von einem Ausgangsportal des Herzpumpen-Datensynchronisierers von 4 durchgeführten Vorgänge gemäß Ausführungsformen der vorliegenden Erfindung zeigt.
    • 13 ist ein Flussdiagramm, das schematisch die Vorgänge veranschaulicht, die von einer Datenauswahleinrichtung des Herzpumpen-Datensynchronisierers von 4 gemäß einer Ausführungsform der vorliegenden Erfindung durchgeführt werden.
    • 14 ist ein Flussdiagramm, das schematisch die von einem EMR-Datenaktualisierer des Herzpumpen-Datensynchronisierers von 4 durchgeführten Vorgänge gemäß Ausführungsformen der vorliegenden Erfindung veranschaulicht.
  • DETAILLIERTE BESCHREIBUNG
  • Zu den Ausführungsformen der vorliegenden Erfindung gehören elektronische Schnittstellen zwischen Herzpumpen-Controller-Datenbanken und EMR-Systemen. Jede Herzpumpen-Controller-Datenbank speichert automatisch zeitkorrelierte Informationen von einer Vielzahl möglicherweise geografisch verteilter Herzpumpen-Controller über Computernetzwerkverbindungen. Beispielsweise können die Herzpumpen-Controller auf eine Vielzahl von nicht angeschlossenen Krankenhäusern verteilt sein.
  • Die Herzpumpen-Controller-Datenbank speichert die Informationen im Laufe der Zeit. So speichert die Herzpumpen-Controller-Datenbank historische und aktuelle Informationen über jede Herzpumpe und der zugehörige Controller. Die Herzpumpen-Controller-Datenbank ist in der Regel von einem Krankenhaus oder einer anderen klinischen Einrichtung, in der sich die Herzpumpen und ihre jeweiligen Controller befinden, entfernt. Häufig wird die Herzpumpen-Controller-Datenbank von einem Herzpumpen-Hersteller betrieben und befindet sich in dessen Räumlichkeiten.
  • Ausführungsformen der vorliegenden Erfindung erleichtern die halbmanuelle oder automatische Übertragung von Daten aus den Herzpumpen-Controller-Datenbanken an die EMR-Systeme, wodurch die Notwendigkeit für eine Krankenschwester oder einen Techniker, die Betriebsdaten der Herzpumpe manuell vom Herzpumpen-Controller-Bildschirm in das EMR-System zu übertragen, verringert oder beseitigt wird. Einige Ausführungsformen reduzieren oder eliminieren die Notwendigkeit, den Patienten regelmäßig zu besuchen, um die Betriebsdaten zu erfassen. Da die Herzpumpen-Controller-Datenbank historische Informationen speichert, erleichtert eine Ausführungsform der Schnittstelle das Erhalten früherer Informationen aus der Herzpumpen-Controller-Datenbank und die halbmanuelle Übertragung der früheren Informationen in das EMR-System, wodurch die Notwendigkeit entfällt, jeden Herzpumpen-Controller rechtzeitig aufzusuchen, um die Informationen aufzuzeichnen. Eine andere Ausführungsform holt, sobald sie programmiert ist, automatisch in regelmäßigen Abständen die Betriebsdaten aus der Herzpumpen-Controller-Datenbank ab und sendet sie an das EMR-System, wodurch die Notwendigkeit entfällt, jeden Herzpumpen-Controller regelmäßig aufzusuchen oder sogar auf frühere Daten zuzugreifen, um die Informationen im EMR-System aufzuzeichnen.
  • Jede Ausführungsform kann als Softwareanwendung implementiert werden, die eine oder mehrere von mehreren Möglichkeiten bietet. Die Anwendung kann innerhalb des EMR-Systems ausgeführt werden und daher über Computerterminals außerhalb des Patientenzimmers zugänglich sein, z. B. am Arbeitsplatz eines Klinikers, wodurch die Notwendigkeit entfällt, jedes Patientenzimmer aufzusuchen, um die Informationen aufzuzeichnen und den Patienten folglich zu stören. Die Anwendung greift aus der Ferne auf die Herzpumpen-Controller-Datenbank zu und kann historische Daten über eine vom Benutzer ausgewählte Herzpumpe anzeigen.
  • Eine Ausführungsform ist als Viewer implementiert, der eine Webseite anzeigt, auf der die historischen Daten angezeigt werden. Der Viewer greift auf die Herzpumpen-Controller-Datenbank zu und zeigt die vom Benutzer ausgewählten Daten an, die von dort abgeholt werden. In dieser Ausführungsform kann der Benutzer also Daten zu einem bestimmten Zeitpunkt in der Vergangenheit abrufen, die vom Viewer angezeigten Daten lesen und dann diese Daten manuell in das EMR-System eingeben, ohne den Herzpumpen-Controller aufsuchen zu müssen, um die Informationen zu bestimmten Zeiten oder in bestimmten Intervallen zu erfassen.
  • Eine andere Ausführungsform ermöglicht dem Benutzer im Wesentlichen das „Kopieren und Einfügen“ von Daten, die wie oben beschrieben von einem Viewer angezeigt werden, aus dem Herzpumpen-Controller-Datenbank-Datenspeicher in das EMR-System, ohne dass der Benutzer die Daten manuell eingeben muss. Da diese Ausführungsform spezifische Felder bereitstellt, aus denen der Benutzer die Daten kopieren kann, kann jedes Feld mit einem bestimmten Datenelementtyp verknüpft werden. Auf diese Weise verleiht die Ausführungsform den eingefügten Daten eine Struktur, und die eingefügten Daten können im EMR als strukturierte Daten gespeichert werden.
  • In einer anderen Ausführungsform werden nach der Programmierung regelmäßig automatisch Daten von dem Herzpumpen-Controller und/oder die in der Herzpumpen-Controller-Datenbank gespeicherten historischen Informationen abgerufen, die Daten nach Bedarf neu formatiert und im EMR-System gespeichert. Die Neuformatierung kann eine optische Zeichenerkennung (OCR) der Echtzeit- oder historischen Daten vor der Speicherung der Daten im EMR-System umfassen. Diese Ausführungsform verleiht den eingefügten Daten eine Struktur, und die Daten können im EMR als strukturierte Daten gespeichert werden.
  • 1 zeigt einen beispielhaften Herzpumpen-Controller 100, in diesem Fall einen Abiomed Automated Impella Controller, einschließlich beispielhafter Betriebsdaten 102, die auf einem Bildschirm 104 angezeigt werden. Wie in 2 gezeigt, kann zur Erleichterung der Fernüberwachung von Herzpumpen-Patienten, z. B. Patienten 200, 202 und 204, durch medizinisches Personal, z. B. Personal 206 und 208, um die Wirksamkeit und Sicherheit der Patienten zu gewährleisten, ein Herzpumpen-Controller, z. B. Controller 210, 212 und 214, über ein Computernetzwerk 216 mit einem oder mehreren zentralen Servern, z. B. Server 218, verbunden werden. Jeder Server 218 kann sich bei dem Hersteller der Herzpumpen und/oder dem Hersteller der Herzpumpen-Controller 210-214 befinden und/oder von diesem betrieben werden.
  • Die Herzpumpen-Controller 210-214 senden die Betriebsdaten 102 (1) über das Netzwerk 216 an den Server 218, der die Daten in einem zeitkorrelierten Datenspeicher 220 speichert. Das heißt, jedes Datum wird mit einer Zeitangabe gespeichert, die angibt, wann das Datum erfasst wurde, oder das Datum wird so gespeichert, dass der Zeitpunkt der Erfassung berechnet werden kann. In einigen Fällen holt der Server 218 die Betriebsdaten 102 über das Netzwerk 216 von den Herzpumpen-Controllern 210-214 ab, anstatt dass die Herzpumpen-Controller 210-214 die Daten 102 sua sponte senden, d. h. nicht als Reaktion auf individuelle Anforderungen des Servers 218, oder zusätzlich dazu. In jedem Fall speichert der Datenspeicher 220 historische Daten über die Herzpumpen-Controller 210-214 und, zumindest implizit, über die Patienten 200-204, denen die Herzpumpen implantiert sind.
  • In Tabelle 1 sind beispielhafte Arten von Informationen 102 aufgeführt, die in dem Datenspeicher 220 des Servers 218 gespeichert werden können und auf die daher bei Ausführungsformen der vorliegenden Erfindung zugegriffen werden kann. Ein bestimmter Datenspeicher 220 muss nicht unbedingt alle in Tabelle 1 aufgeführten Datentypen speichern, und einige Datenspeicher 220 können zusätzliche, nicht in Tabelle 1 aufgeführte Datentypen speichern. Tabelle 1: Beispielhafte Informationen vom Herzpumpen-Controller
    Seriennummer des Controllers
    Software-Versionsnummer des Controllers
    Firmware-Versionsnummer des Controllers
    Hardware-Versionsnummer des Controllers
    Seriennummer der Pumpe
    Modellnummer der Pumpe
    Name des Patienten
    Patienten-Identifikationsnummer (kann alphabetisch oder alphanumerisch sein)
    Ladezustand der Batterie
    Stromquelle (Netz oder Batterie)
    Mittlerer arterieller Druck (vom Bediener eingegeben)
    Herzleistung
    Nativ-Herzzeitvolumen
    Traubenzucker-Infusion
    Traubenzucker-Konzentration (%)
    Heparin-Infusion
    Heparin-Konzentration (IU/ml)
    Aortendruck (AOP)
    Mittlerer AOP
    Linksventrikulärer enddiastolischer Druck (LVEDP)
    Linksventrikulärer Druck (LVP)
    Spülstrom
    Spüldruck
    Pumpenstrom (unverzögert)
    Pumpenstrom (Durchschnitt)
    Pumpenstrom (Minimum)
    Pumpenstrom (maximal)
    Platzierungssignal
    Platzierungssignal-Zeitplan
    Platzierungssignal-Anzeigebereich minimal
    Platzierungssignal-Anzeigebereich maximal
    Motorstrom
    Motorstrom-Zeitplan
    Motorstrom-Anzeigebereich minimal
    Motorstrom-Anzeigebereich maximal
    Motordrehzahl
    Pumpenlaufzeit
    Mittlerer AOP-Zeitplan
    Mittlerer AOP-Anzeigebereich minimal
    Mittlerer AOP-Anzeigebereich maximal
    Zeitplan für Herzzeitvolumen, Fluss und Nativ-Herzzeitvolumen
    Minimaler Anzeigebereich für Herzzeitvolumen, Fluss und Nativ-Herzzeitvolumen
    Maximaler Anzeigebereich für Herzzeitvolumen, Fluss und Nativ-Herzzeitvolumen
    Spülstrom-Zeitplan
    Spülstrom-Anzeigebereich minimal
    Spülstrom-Anzeigebereich maximal
    Spüldruck-Zeitplan
    Spüldruck-Anzeigebereich minimal
    Spüldruck-Anzeigebereich maximal
  • Der Server 218 ist über das Netzwerk 216 für Überwachungsstationen zugänglich, z. B. für die Überwachungsstationen 222 und 224 (2). Jede Überwachungsstation 222-244 kann ein Personal Computer (PC) sein. Ein optionaler Webserver 226 kann den Zugriff der Überwachungsstationen 222-224 auf den zentralen Server 218 erleichtern. Die Überwachungsstationen 222-224 können auf diese Weise Daten aus dem Datenspeicher 220 abholen und Echtzeit- und/oder historische Betriebsdaten und/oder Alarme auf Bildschirmen zur Ansicht durch das medizinische Personal 206-208 anzeigen. Der zentrale Server 218 kann eine Anwendungsprogrammierschnittstelle (API) enthalten (nicht dargestellt), um das Abrufen von Daten aus dem Datenspeicher 220 zu erleichtern.
  • 3 ist eine beispielhafte hypothetische Anzeige 300, die von einer Überwachungsstation 222-224 aus 2 bereitgestellt wird. So stellt der Server 218 ein Cloud-basiertes System 228 (2) bereit, mit dem das medizinische Personal 206-208 die Patienten 200-204 überwachen kann. Einige Aspekte des Cloud-basierten Systems 228 sind in U.S. Pat. Publ. No. 2020/0098473 und U.S. Pat. Appl. Nr. 16/370,951 , 16/365,293 , 16/360,270 und 16/458,093 beschrieben, deren gesamter Inhalt hiermit für alle Zwecke durch Bezugnahme hierin aufgenommen wird. Ein geeignetes Cloud-basiertes System 228 ist von Abiomed, Inc. unter dem Handelsnamen Impella Connect® Remote Heart Pump Management System erhältlich.
  • Ausführungsform I
  • Eine Ausführungsform der vorliegenden Erfindung stellt einen Herzpumpen-Datensynchronisierer bereit, der die Identifikation mindestens eines Datentyps und einer Zeit oder eines Zeitbereichs der im Datenspeicher 220 (2) gespeicherten Daten durch einen menschlichen Benutzer erleichtert. Diese Ausführungsform erhält die identifizierten Daten aus dem Datenspeicher 220 und zeigt die Daten auf einem Ausgabeportal an. Eine Krankenschwester oder ein Techniker (ein „Benutzer“) kann die auf dem Ausgabeportal angezeigten Daten beobachten und die Daten in ein mit einem EMR-System gekoppeltes Computerterminal eingeben. Vorteilhaft ist, dass der Benutzer den Patienten 200-204 nicht besuchen muss, um die Daten zu erhalten. Ein Ausgabeportal kann beispielsweise so konfiguriert sein, dass es auf einem Computerterminal auf einer Pflegestation funktioniert. Vorteilhafterweise kann der Benutzer Daten für einen früheren Zeitraum erhalten. Der Benutzer muss also nicht unbedingt in regelmäßigen oder zeitlichen Abständen auf das Ausgabeportal zugreifen. Stattdessen kann der Benutzer auf das Ausgabeportal zugreifen, wenn er nicht anderweitig beschäftigt ist, und dennoch hat der Benutzer Zugriff auf Daten, die in vorgeschriebenen Intervallen oder zu bestimmten Zeiten erfasst wurden.
  • 4 ist ein schematisches Blockdiagramm eines beispielhaften Herzpumpen-Datensynchronisierers 400, gemäß einer Ausführungsform der vorliegenden Erfindung. Ein oder mehrere Teile des Herzpumpen-Datensynchronisierers 400 können so konfiguriert sein, dass sie zu einem EMR-System 402 hinzugefügt werden können und darin betrieben werden können. Der Herzpumpen-Datensynchronisierer 400 bietet dem Benutzer Zugang zu den zeitkorrelierten Daten, die in dem Datenspeicher 220 (2) gespeichert sind, und erleichtert dem Benutzer die Eingabe von benutzerspezifischen Datenelementen in das EMR-System 402.
  • Viele EMR-Systeme bieten dokumentierte Anwendungsprogrammierschnittstellen (API), um die Integration von Anwendungen („Add-ons“) in die EMR-Systeme zu erleichtern, so dass die Add-on-Anwendungen innerhalb des EMR-Systems ausgeführt werden. Eine solche Add-on-Anwendung wird hier als für die Hinzufügung zu einem EMR-System und den Betrieb darin konfiguriert bezeichnet. In ähnlicher Weise stellen viele EMR-Systeme APIs bereit, um Add-on-Anwendungen das Abrufen und Speichern von Daten im EMR in Bezug auf identifizierte Patienten zu erleichtern. Einige EMR-Systeme bieten Schnittstellen, die einem oder mehreren bekannten Interoperabilitätsstandards entsprechen, wie Consolidated CDA (C-CDA), Health Level Seven International (HL7) und Fast Healthcare Interoperability Resources (FHIR). FHIR ist ein Standard für den elektronischen Austausch von Gesundheitsinformationen.
  • Ein Herzpumpen-Identifikator 404 ist so konfiguriert, dass er dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Das EMR-System 402 speichert Informationen über eine Vielzahl von Herzpumpen-Patienten 200-204 und eine Vielzahl von Nicht-Herzpumpen-Patienten, z. B. die Nicht-Herzpumpen-Patienten 230 und 232 (2). Der Herzpumpen-Identifikator 404 umfasst eine erste Benutzerschnittstelle 406. In 5 ist die erste Benutzerschnittstelle 406 gemäß einer Ausführungsform dargestellt. Die erste Benutzerschnittstelle 406 ist so konfiguriert, dass sie einem Benutzer eine erste Aufforderung 500 anzeigt und einen lokal eingegebenen Identifikator, z. B. einen Herzpumpen-Identifikator oder einen Patienten-Identifikator, in ein Eingabefeld 502 eingibt. Der Herzpumpen-Identifikator kann beispielsweise die Modellnummer oder den Namen, die Seriennummer und/oder den Namen des Herstellers usw. einer Herzpumpe umfassen. In einigen Ausführungsformen ist der lokal eingegebene Identifikator ein Patienten-Identifikator, z. B. eine Patienten-Identifikationsnummer, und die erste Aufforderung 500 wird in geeigneter Weise geändert. Wie hierin verwendet, bedeutet „lokal eingegeben“, dass der Identifikator auf einer Eingabevorrichtung, wie z. B. einer Tastatur, einem Touchscreen oder ähnlichem, in der Nähe der Anzeigevorrichtung, die die erste Aufforderung 500 anzeigt, und durch den Benutzer, der die erste Benutzerschnittstelle 406 und die erste Aufforderung 500 beobachtet, eingegeben wird.
  • Zurück zu 4: Eine Netzwerkschnittstelle 408 ist so konfiguriert, dass sie dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Die Netzwerkschnittstelle 408 ist so konfiguriert, dass sie über ein Weitverkehrs-Computernetzwerk, z. B. das Netzwerk 216 ( ), mit einem Cloud-basierten Server, wie dem Server 218 des Cloud-basierten Systems 228, kommuniziert. Typischerweise ist der Cloud-basierte Server 218 von dem EMR-System 402 getrennt und hat ansonsten keine Kommunikationsverbindung mit ihm. Die Netzwerkschnittstelle 408 kann mit dem Cloud-basierten Server 218 über eine Anwendungsprogrammierschnittstelle (API) 409 kommunizieren, die von dem Cloud-basierten Server 218 bereitgestellt wird.
  • Wie in 2 beschrieben, speichert der Cloud-basierte Server 218 historische, zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen 210-214. Zeitkorreliert bedeutet, dass die Zeit, zu der die Daten gesammelt wurden, in Verbindung mit den Daten gespeichert ist oder dass die Zeit berechnet werden kann. Folglich können Daten für einen Zeitpunkt oder eine Zeitspanne innerhalb des Cloud-basierten Servers 218 ausgewählt werden.
  • Die historischen Betriebsdaten umfassen eine Vielzahl von Datentypen für jede implantierte Herzpumpe 210-214. Beispiele für die Datentypen sind in den 1 und 3 dargestellt, darunter Pumpentyp, Blutflussrate, minimale Blutflussrate, maximale Blutflussrate, Heparinflussrate, Blutdruck und Krankenhausname. Andere Datentypen, die in 1 und 3 nicht dargestellt sind, können ebenfalls verwendet werden. Beispiele für solche Daten werden in Tabelle 1 beschrieben.
  • Zurück zu 4: Ein Datenelement-Identifikator 410 ist so konfiguriert, dass er zum EMR-System 402 hinzugefügt und darin betrieben werden kann. Der Datenelement-Identifikator 410 umfasst eine zweite Benutzerschnittstelle 412. 5 zeigt die zweite Benutzerschnittstelle 412 gemäß einer Ausführungsform. Die zweite Benutzerschnittstelle 412 ist so konfiguriert, dass sie dem Benutzer eine zweite Aufforderung 503 anzeigt. Die zweite Benutzerschnittstelle 412 ist weiter so konfiguriert, dass sie vom Benutzer in Verbindung mit dem lokal eingegebenen Identifikator 502 einen Identifikator mindestens eines Datentyps 504 aus der Vielzahl von Datentypen eingibt, die auf dem Cloud-basierten Server 218 gespeichert und dort verfügbar sind. Die zweite Benutzerschnittstelle 412 ist weiter so konfiguriert, dass sie vom Benutzer eine Zeit 506 eingibt (z. B. wie durch ein Startdatum/eine Startzeit 508 und ein Enddatum/eine Endzeit 510 angegeben). Wenn der Benutzer nur ein einziges Datum/eine einzige Zeit eingibt oder auswählt, wird die Zeit 506 als ein einziger Zeitpunkt betrachtet.
  • Der Datentyp 504 und Aspekte der Start- und Endzeiten 508-510 können vom Benutzer mit Pull-Down-Listen abgefragt und eingegeben werden, wie durch die nach unten gerichteten Dreiecke in 5 angedeutet. Die Pull-Down-Liste kann auf der Grundlage von Datentypen gefüllt werden, die auf dem Cloud-basierten Server 218 verfügbar sind. In einigen Ausführungsformen fragt der Datenelement-Identifikator 410 den Cloud-basierten Server 218 nach einer Liste von Datentypen ab, die vom Cloud-basierten Server 218 angefordert werden können. Jedes andere geeignete grafische oder textuelle Steuerelement der Benutzeroberfläche oder eine Kombination von Elementen, wie z. B. Textfelder, Kalender, Schieberegler und/oder Spinner, kann verwendet werden.
  • 5 zeigt eine Datentyp-Aufforderung 503 und eine Pull-Down-Liste 504 zur Auswahl eines Datentyps. Andere Ausführungsformen (nicht dargestellt) der zweiten Benutzerschnittstelle 412 umfassen mehrere Pull-Down-Listen oder andere geeignete grafische oder textuelle Steuerelemente der Benutzerschnittstelle oder Kombinationen davon, um dem Benutzer die Auswahl mehrerer Datentypen zu erleichtern. Alternativ kann die zweite Benutzerschnittstelle 412 eine einzige Pull-Down-Liste 504 oder eine andere Benutzerschnittstellensteuerung verwenden, um den Benutzer wiederholt zur Eingabe von Datentypen abzufragen, bis der Benutzer anzeigt, dass er die Eingabe der Datentypen abgeschlossen hat, z. B. durch Anklicken einer Schaltfläche „OK“ (nicht dargestellt).
  • Bei der Verwendung greift ein Arzt auf die erste Benutzerschnittstelle 406 des Herzpumpen-Identifikators zu. Der Arzt gibt einen Herzpumpen-Identifikator, wie z. B. eine Seriennummer der Herzpumpe, oder einen Patienten-Identifikator, wie z. B. eine Patienten-Identifikationsnummer, in die erste Benutzerschnittstelle 406 ein. Der Arzt gibt einen oder mehrere Datentypen 504 und eine Zeit 506 ein oder wählt sie aus. Durch diese Eingaben gibt der Arzt an, welche Herzpumpe oder welcher Patient von Interesse ist. Diese Eingaben geben auch an, welche(r) Datentyp(en), der/die von dem Herzpumpen-Controller 210-214, die mit der Herzpumpe oder dem Patienten von Interesse 200-204 verbunden ist, erfasst wurde(n), von Interesse ist/sind. Diese Eingaben geben auch einen einzelnen Zeitpunkt 506 oder eine Zeitspanne 506 an, in der die Daten von Interesse sind. Diese Eingaben weisen den Herzpumpen-Datensynchronisierer 400 an, die Daten von Interesse vom Server 218 abzuholen.
  • Ein Controller 414 (4) ist mit dem Herzpumpen-Identifikator 404, der Netzwerkschnittstelle 408 und dem Datenelement-Identifikator 410 verbunden. Der Controller 414 ist so konfiguriert, dass er dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Der Controller 414 ist ferner so konfiguriert, dass er als Reaktion auf den Empfang des lokal eingegebenen Identifikators 502, der mindestens einen Datentyp-Identifikation 504 und der Zeit 506 über die Netzwerkschnittstelle 408 den lokal eingegebenen Identifikator 502, die mindestens eine Datentyp-Identifikation 504, die Zeit 506 und eine Anforderung 416 nach Daten, die dem lokal eingegebenen Identifikator 502 (einem Herzpumpen-Identifikator oder einem Patienten-Identifikator), der/den Datentyp-Identifikation(en) 504 und der Zeit 506 entsprechen, an den Cloud-basierten Server 218 sendet. Wie hierin verwendet, bedeutet „entsprechende Daten“ oder „die entsprechenden Daten dazu“ Daten über den Patienten und/oder die Herzpumpe, die durch den lokal eingegebenen Identifikator 502 identifiziert werden, wobei die Daten von einem Typ bzw. Typen sind, der/die durch den/die Datentyp-Identifikator(en) 504 identifiziert wird/werden, und die Daten während der gesamten oder eines Teils der Zeit 506 gesammelt wurden.
  • Ein Monitor 418 ist mit der Netzwerkschnittstelle 406 verbunden. Der Monitor 418 ist so konfiguriert, dass er dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Der Monitor 418 ist so konfiguriert, dass er über die Netzwerkschnittstelle 408 von dem Cloud-basierten Server 218 die entsprechenden Daten 420 empfängt, die von dem Cloud-basierten Server 218 als Reaktion auf die Anforderung 416 übertragen wurden.
  • Ein Ausgabeportal 422 ist mit dem Monitor 418 verbunden. Das Ausgabeportal 422 ist so konfiguriert, dass es dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Das Ausgabeportal 422 ist so konfiguriert, dass es dem Benutzer die entsprechenden Daten 420 anzeigt, z. B. auf einem Anzeigebildschirm. Beispielsweise kann das Ausgabeportal 422 als Webseiten-Viewer implementiert werden, und der Cloud-basierte Server 218 kann so konfiguriert sein, dass er eine HTMI,-formatierte Webseite bereitstellt, die die angeforderten Daten 420 enthält.
  • Sobald die Daten 420 dem Benutzer angezeigt werden, kann dieser die Daten manuell in das EMR-System eingeben, indem er eine herkömmliche EMR-Benutzeroberfläche verwendet, oder die Daten für einen anderen Zweck verwenden. Wie bereits erwähnt, handelt es sich bei den manuell in ein EMR-System eingegebenen Daten jedoch häufig um unstrukturierte Daten, die daher für automatisierte Systeme nur von begrenztem Wert sind. Nichtsdestotrotz ermöglicht diese Ausführungsform den Ärzten die Eingabe von Herzpumpen-Daten aus der Vergangenheit in das EMR-System und die Eingabe dieser Daten, ohne die Patienten zu besuchen und somit zu stören.
  • 7 ist ein Flussdiagramm, das schematisch die von dem Herzpumpen-Identifikator 404 durchgeführten Vorgänge veranschaulicht. Bei 700 zeigt der Herzpumpen-Identifikator 404 dem Benutzer die erste Aufforderung 500 an. Bei 702 gibt der Herzpumpen-Identifikator 404 den lokal eingegebenen Identifikator 502 ein. Wie bereits erwähnt, kann der lokal eingegebene Identifikator 502 ein Herzpumpen-Identifikator oder ein Identifikator eines Patienten 200-204 mit einer implantierten Herzpumpe sein.
  • 8 ist ein Flussdiagramm, das schematisch die von der Netzwerkschnittstelle 408 durchgeführten Vorgänge veranschaulicht. Bei 800 kommuniziert die Netzwerkschnittstelle 408 über das Weitverkehrs-Computernetzwerk 216 mit dem Cloud-basierten Server 218.
  • 9 ist ein Flussdiagramm, das schematisch die von dem Datenelement-Identifikator 404 durchgeführten Vorgänge veranschaulicht. Optional fragt der Datenelement-Identifikator 404 bei 900 den Cloud-basierten Server 218 nach einer Liste der verfügbaren Datentypen ab. Diese Informationen können verwendet werden, um die zweite Aufforderung 503 zu erzeugen. Bei 902 zeigt der Datenelement-Identifikator 404 dem Benutzer die zweite Aufforderung 503 an. Bei 904 gibt der Datenelement-Identifikator 404 eine Zeit 506 und eine Identifikation 504 von mindestens einem Datentyp aus der Vielzahl der Datentypen ein. Da die erste und die zweite Aufforderung 500 und 503 auf derselben Vorrichtung zur gleichen oder nahezu gleichen Zeit angezeigt werden und der Benutzer den lokal eingegebenen Identifikator 502, die Zeit 506 und die Identifikation 504 des mindestens einen Datentyps auf derselben Vorrichtung und nahezu zur gleichen Zeit eingibt, werden die Zeit 506 und die Identifikation 504 des mindestens einen Datentyps hier als „in Verbindung mit“ dem lokal eingegebenen Identifikator 502 eingegeben bezeichnet.
  • 10 ist ein Flussdiagramm, das schematisch die von dem Controller 414 durchgeführten Vorgänge veranschaulicht. Bei 1000 wartet der Controller 414 auf den Empfang des lokal eingegebenen Identifikators 502, des Datenelement-Identifikators 410 der mindestens einen Datentyp-Identifikation 504 und der Zeit 506. Bei 1002 sendet der Controller 414 als Reaktion auf den Empfang dieser Elemente den lokal eingegebenen Identifikator 502, die mindestens eine Datentyp-Identifikation 504 und die Zeit 506 an den Cloud-basierten Server 218. Bei 1004 sendet der Controller 414 die Anforderung 416 für die entsprechenden Daten an den Cloud-basierten Server 218.
  • 11 ist ein Flussdiagramm, das schematisch die vom Monitor 418 durchgeführten Vorgänge veranschaulicht. Bei 1100 empfängt der Monitor 418 die entsprechenden Daten 420, die vom Cloud-basierten Server 218 als Reaktion auf die Anforderung 416 übertragen wurden. Weitere Vorgänge des Monitors 418 werden hier beschrieben.
  • 12 ist ein Flussdiagramm, das schematisch die vom Ausgabeportal 422 durchgeführten Vorgänge veranschaulicht. Bei 1200 zeigt das Ausgabeportal 422 dem Benutzer die entsprechenden Daten 420 an, die er von dem Cloud-basierten Server 218 erhalten hat.
  • Ausführungsform II
  • In einer anderen Ausführungsform ermöglicht eine grafische Benutzeroberfläche (GUI) dem Benutzer die grafische Identifizierung von Daten, die von Interesse sind, z. B. durch Ziehen eines Mauszeigers durch die angezeigten Daten, und das System holt die identifizierten Daten aus dem Datenspeicher 220 und speichert dann die ausgewählten Daten im EMR-System 402. Im Wesentlichen ermöglicht diese Ausführungsform dem Benutzer das „Kopieren und Einfügen“ von Daten aus dem Datenspeicher 220 in das EMR-System 402, ohne dass der Benutzer die Daten manuell eingeben muss. In einigen Ausführungsformen werden die Daten als strukturierte Daten im EMR-System 402 gespeichert.
  • In einer solchen Ausführungsform umfasst der Herzpumpen-Datensynchronisierer 400 (4) eine Datenauswahleinrichtung 424. Die Datenauswahleinrichtung 424 ist so konfiguriert, dass sie dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Die Datenauswahleinrichtung 424 umfasst eine dritte Benutzerschnittstelle 426, die so konfiguriert ist, dass sie dem Benutzer eine dritte Aufforderung anzeigt. Die Datenauswahleinrichtung 424 ist auch so konfiguriert, dass sie vom Benutzer eine Angabe eingibt, die zumindest einen Teil der entsprechenden Daten identifiziert, die dem Benutzer angezeigt werden. Wie in Bezug auf die Benutzerschnittstelle 504 erörtert, kann jedes geeignete grafische Steuerelement der Benutzerschnittstelle oder eine Kombination von Elementen verwendet werden.
  • 5 zeigt eine Ausführungsform der dritten Benutzeroberfläche 426 und der dritten Aufforderung 512 der Datenauswahleinrichtung 424. In dieser Ausführungsform ermöglicht ein Kontrollkästchen 426 oder ein anderes geeignetes grafisches oder textliches Element dem Benutzer, den über den Datentyp-Auswahleinrichtungen 504 angezeigten oder ausgewählten Datentyp auszuwählen. Bei einer Ausführungsform mit mehreren Datentyp-Auswahleinrichtungen 504 kann die Anzahl der Kontrollkästchen 426 gleich der Anzahl der Datentyp-Auswahleinrichtungen 504 sein.
  • 6 zeigt eine weitere Ausführungsform der dritten Benutzerschnittstelle 426. In dieser Ausführungsform zeigt die Datenauswahleinrichtung 424, nachdem der Benutzer die Datentyp(en) unter Verwendung der zweiten Benutzerschnittstelle 412 ausgewählt hat, beispielsweise wie in 5 beschrieben, die dritte Aufforderung 512 und die vom Cloud-basierten Server 218 zurückgegebenen Daten an, beispielsweise ein Datentyp pro Zeile, wie in 6 gezeigt. Kontrollkästchen, dargestellt durch die Kontrollkästchen 600 und 602, ermöglichen es dem Benutzer, einzelne Datenelemente auszuwählen.
  • Alternativ dazu zeigt die Datenauswahleinrichtung 424 in einigen Ausführungsformen einen Cursor (nicht dargestellt) an, und der Benutzer zieht den Cursor durch die angezeigten Datenelemente, um die Identifikation mindestens eines Teils der entsprechenden Daten anzuzeigen. Die Datenauswahleinrichtung 424 kann bewirken, dass die durchgezogenen Daten in einer anderen Farbe angezeigt werden, um die Auswahl hervorzuheben.
  • Der Herzpumpen-Datensynchronisierer 400 kann auch einen EMR-Datenaktualisierer 428 enthalten (4). Der EMR-Datenaktualisierer 428 kann so konfiguriert sein, dass er dem EMR-System 402 hinzugefügt und darin betrieben werden kann. Der EMR-Datenaktualisierer 428 kann so konfiguriert sein, dass er im EMR-System 402 zumindest einen Teil der entsprechenden Daten speichert, die dem Benutzer angezeigt oder von ihm ausgewählt wurden. Mit anderen Worten kann der EMR-Datenaktualisierer 428 so konfiguriert sein, dass er im EMR-System 402 die vom Benutzer ausgewählten Daten speichert.
  • Da die vom Cloud-basierten Server 218 zurückgegebenen Datenelemente jeweils aus benannten Feldern im Datenspeicher 220 stammen, können die Feldnamen zur Identifizierung des Typs der im EMR-System gespeicherten Daten verwendet werden, wenn einer der angezeigten Datentypen vom Benutzer ausgewählt wird. Das heißt, die Daten können im EMR-System als strukturierte Daten gespeichert werden.
  • In jedem Fall werden die vom Benutzer ausgewählten Daten im EMR-System in Verbindung mit einem Patienten-Identifikator gespeichert. Wenn der lokal eingegebene Identifikator 502 ein Patienten-Identifikator ist, kann der EMR-Datenaktualisierer 428 den lokal eingegebenen Identifikator 502 als Schlüssel verwenden, um die Aufzeichnung des Patienten im EMR-System 402 zu spezifizieren, so dass die vom EMR-Datenaktualisierer 428 gespeicherten Daten im EMR-System 402 in Verbindung mit einem Patienten-Identifikator gespeichert werden.
  • Die im EMR-System 402 gespeicherten Daten werden mit den Patienten korreliert. Um den Benutzer von der Eingabe eines Patienten-Identifikators zu entlasten, kann die Herzpumpen-Identifikation verwendet werden, um auf die Patienten-Identifikation zu schließen. Häufig enthalten die Daten im historischen Datenspeicher 220 die Herzpumpen-Identifikationsinformation, wie z. B. die Modellidentifikation und die Seriennummer. Darüber hinaus speichert der historische Datenspeicher 220 häufig einen Patienten-Namen oder einen anderen Patienten-Identifikator in Verbindung mit implantierten Herzpumpen. Daher kann der Herzpumpen-Datensynchronisierer 400 den lokal eingegebenen Herzpumpen-Identifikator 502 (5) verwenden, um die Identifikation des mit dieser Herzpumpe verbundenen Patienten nachzuschlagen. Der Herzpumpen-Datensynchronisierer 400 kann dann den abgeleiteten Patienten-Identifikator verwenden, um die Daten im EMR-System in Verbindung mit dem richtigen Patienten zu speichern. Automatisch abgeleitete Herzpumpen-Identifikatoren, wie z. B. solche, die durch Scannen oder Fotografieren der Herzpumpe ermittelt werden, können in ähnlicher Weise verwendet werden.
  • Das heißt, wenn der lokal eingegebene Identifikator 502 ein Herzpumpen-Identifikator ist, können die vom Cloud-basierten Server 218 gespeicherten Daten einen Patienten-Identifikator für jeden Herzpumpen-Identifikator enthalten. In diesem Fall sendet der Cloud-basierte Server 218 den Patienten-Identifikator zusammen mit den angeforderten Datenelementen, und der EMR-Datenaktualisierer 428 kann den vom Cloud-basierten Server 218 gesendeten Patienten-Identifikator als Schlüssel verwenden, um die Aufzeichnung des Patienten im EMR-System 402 zu spezifizieren, sodass die vom EMR-Datenaktualisierer 428 gespeicherten Daten im EMR-System 402 in Verbindung mit einem Patienten-Identifikator gespeichert werden.
  • Optional kann jede implantierte Herzpumpe mechanisch mit einem entsprechenden Herzpumpen-Controller 200-204 gekoppelt sein, der einen Anzeigebildschirm 104 umfasst ( 1). Die Betriebsdaten 102 der implantierten Herzpumpe können auf dem Anzeigebildschirm 104 angezeigt werden. Jeder Herzpumpen-Controller 200-204 kann so konfiguriert sein, dass er einen jeweiligen Videostrom, der den Inhalt des Anzeigebildschirms 104 darstellt, an den Cloud-basierten Server 218 sendet.
  • Die historischen zeitkorrelierten Betriebsdaten, die von dem Cloud-basierten Server 218 gespeichert werden, können zumindest teilweise von dem Cloud-basierten Server 218 aus den jeweiligen Videoströmen der jeweiligen Herzpumpen-Controller 200-204 abgeleitet werden. Beispielsweise kann jeder Videostrom den Inhalt des Bildschirms 104 eines Herzpumpen-Controllers 200-204 darstellen. Die entsprechenden Daten 420, die der Monitor 418 vom Cloud-basierten Server 218 empfängt, können Nicht-Videodaten sein. Beispielsweise können die entsprechenden Daten 420 in Form von Netzwerkpaketen vorliegen, die Zahlen enthalten, die die entsprechenden Daten 420 direkt darstellen, wie etwa den Blutdruck.
  • Das Ausgangsportal 422 kann einen Videosignal-Synthesizer 430 enthalten, der so konfiguriert ist, dass er aus den entsprechenden Daten 420 zumindest teilweise einen Videostrom neu erzeugt, um dem Benutzer die entsprechenden Daten 420 anzuzeigen. Im Wesentlichen erzeugt der Videosignal-Synthesizer 430 ein Duplikat von zumindest einem Teil des Anzeigebildschirms 104 des Herzpumpen-Controllers 200-204. Durch diesen Mechanismus kann der Benutzer den Anzeigebildschirm 102 oder zumindest einen Teil des Anzeigebildschirms 102 eines Herzpumpen-Controllers 200-204 im Wesentlichen in nahezu Echtzeit sehen, ohne das Zimmer des Patienten zu betreten.
  • Der lokal eingegebene Herzpumpen-Identifikator 502 kann eine Seriennummer einer jeweiligen implantierten Herzpumpe enthalten. Der Herzpumpen-Datensynchronisierer 400 kann auch einen Scanner 432 enthalten, der so konfiguriert ist, dass er einen Strichcode liest, der den Herzpumpen-Identifikator darstellt und dadurch den lokal eingegebenen Herzpumpen-Identifikator 502 bereitstellt. Ein Strichcode, einschließlich eines QR-Codes (Quick Response), ist ein maschinenlesbares optisches Etikett, das Informationen über den Gegenstand enthält, an dem es angebracht ist. Bei solchen Ausführungen muss der Benutzer den Herzpumpen-Identifikator nicht manuell eingeben. Da diese Identifikatoren lang und/oder willkürlich sein können, verringert sich die Fehlerwahrscheinlichkeit, wenn ein Mensch den Identifikator nicht manuell eingeben muss. Der Scanner 432 kann drahtlos mit dem Herzpumpen-Identifikator 404 verbunden sein.
  • Der Herzpumpen-Datensynchronisierer 400 kann eine Kamera 434 enthalten, die so konfiguriert ist, dass sie den Herzpumpen-Identifikator liest und dadurch den lokal eingegebenen Herzpumpen-Identifikator bereitstellt. Das Zeichen kann aus Text oder einem Strichcode bestehen. Bei der Kamera 434 kann es sich um eine Kamera eines Mobiltelefons handeln. Software zur optischen Zeichenerkennung (OCR) kann verwendet werden, um ein von der Kamera 434 erzeugtes Bild zu verarbeiten, um den lokal eingegebenen Herzpumpen-Identifikator abzuleiten. Die Kamera 434 kann die Wahrscheinlichkeit eines menschlichen Fehlers bei der Eingabe des lokal eingegebenen Herzpumpen-Identifikators verringern. Die Kamera 434 kann drahtlos mit dem Herzpumpen-Identifikator 404 verbunden sein.
  • Die Netzwerkschnittstelle 408 kann so konfiguriert sein, dass sie mit dem Cloud-basierten Server 218 über eine Anwendungsprogrammierschnittstelle (API) kommuniziert, die vom Cloud-basierten Server 218 bereitgestellt wird. Wie in Wikipedia erwähnt, ist eine Anwendungsprogrammierschnittstelle (API) eine Computerschnittstelle zu einer Softwarekomponente oder einem System, die definiert, wie andere Komponenten oder Systeme sie nutzen können. Eine API definiert die Arten von Aufrufen oder Anforderungen, die gemacht werden können, wie sie gemacht werden, die zu verwendenden Datenformate, die zu befolgenden Konventionen usw. Einige APIs müssen dokumentiert werden, während andere so konzipiert sind, dass sie „abgefragt“ werden können, um die unterstützte Funktionalität zu bestimmen. Da andere Komponenten/Systeme nur auf die API angewiesen sind, kann das System, das die API bereitstellt, (idealerweise) seine internen Details „hinter“ der API ändern, ohne dass die Benutzer davon betroffen sind.
  • 13 ist ein Flussdiagramm, das schematisch die von der Datenauswahleinrichtung 424 durchgeführten Vorgänge veranschaulicht. Bei 1300 zeigt die Datenauswahleinrichtung 424 dem Benutzer die dritte Aufforderung 512 an. Bei 1302 gibt die Datenauswahleinrichtung 424 die Angabe 426 oder 600 ein, mit der zumindest ein Teil der entsprechenden Daten ausgewählt wird, die dem Benutzer angezeigt werden.
  • 14 ist ein Flussdiagramm, das schematisch die vom EMR-Datenaktualisierer 428 durchgeführten Vorgänge veranschaulicht. Bei 1400, wenn der lokal eingegebene Identifikator 502 ein Patienten-Identifikator ist, geht die Steuerung zu 1402 über, wo der lokal eingegebene Identifikator 502/Patienten-Identifikator als Schlüssel zum Indexieren in das EMR-System 402 verwendet wird. Wenn es sich bei dem lokal eingegebenen Identifikator 502 um einen Herzpumpen-Identifikator handelt, geht die Steuerung optional zu 1404 über. In 1404 wird der lokal eingegebene Identifikator 502 / Pumpen-Identifikator verwendet, um einen entsprechenden Patienten-Identifikator im Cloud-basierten Server 218 nachzuschlagen. Beispielsweise kann der EMR-Datenaktualisierer 428 den Herzpumpen-Identifikator an den Cloud-basierten Server 218 senden und eine Identifikation eines Patienten anfordern, die in dem Datenspeicher 220 mit dem Herzpumpen-Identifikator verknüpft ist. Alternativ ist der Monitor 418 so konfiguriert, dass er über die Netzwerkschnittstelle 408 von dem Cloud-basierten Server 218 einen Patienten-Identifikator empfängt, die den Daten entspricht, die von dem Cloud-basierten Server 218 als Reaktion auf die Anforderung übertragen wurden, wie hierin beschrieben.
  • Bei 1406 speichert der EMR-Datenaktualisierer 428 die ausgewählten Daten im EMR-System 402. In einigen Ausführungsformen werden die ausgewählten Daten, wie in 1408 angegeben, im EMR-System 402 als strukturierte Daten gespeichert. In jedem Fall werden die ausgewählten Daten im EMR-System 402 in Verbindung mit dem Patienten-Identifikator gespeichert, wie in 1402 oder 1404 bestimmt.
  • Wie bereits erwähnt, ist 11 ein Flussdiagramm, das schematisch die vom Monitor 418 durchgeführten Vorgänge veranschaulicht. Optional empfängt der Monitor 418 bei 1102 von dem Cloud-basierten Server 218 einen Patienten-Identifikator, der den Daten 420 entspricht, die von dem Cloud-basierten Server 218 als Reaktion auf die Anforderung 416 übertragen wurden. Dieser Patienten-Identifikator kann von dem EMR-Datenaktualisierer 428 als Schlüssel zum EMR-System 402 verwendet werden.
  • Wie bereits erwähnt, ist 12 ein Flussdiagramm, das schematisch die vom Ausgangsportal 422 durchgeführten Vorgänge veranschaulicht. Jede implantierte Herzpumpe ist mechanisch mit einem entsprechenden Herzpumpen-Controller 210-214 gekoppelt, der einen Bildschirm umfasst, auf dem Betriebsdaten der implantierten Herzpumpe angezeigt werden. Jeder Herzpumpen-Controller 210-214 kann so konfiguriert sein, dass er einen jeweiligen Videostrom, der den Inhalt des Bildschirms darstellt, an den Cloud-basierten Server 218 sendet. Die historischen, zeitkorrelierten Betriebsdaten, die von dem Cloud-basierten Server 218 gespeichert werden, können zumindest teilweise von dem Cloud-basierten Server 218 aus den jeweiligen Videoströmen von den jeweiligen Herzpumpen-Controllern 210-214 abgeleitet werden. Die entsprechenden Daten 420, die der Monitor 418 vom Cloud-basierten Server 218 empfängt, können Nicht-Videodaten sein. Optional kann der Videosignal-Synthesizer 430 bei 1202 aus den entsprechenden Daten 420 zumindest teilweise einen Videostrom neu erzeugen, um dadurch die entsprechenden Daten 420 für den Benutzer anzuzeigen.
  • Ausführungsform III
  • Nach der Programmierung holt die dritte Ausführungsform in regelmäßigen Abständen automatisch Daten von dem Herzpumpen-Controller 200-204 und/oder der historischen Datenbank 220 ab, formatiert die Daten nach Bedarf neu und speichert sie im EMR-System 402. Die Neuformatierung kann eine optische Zeichenerkennung (OCR) der Echtzeitdaten von den Herzpumpen-Controllern 210-214 oder der historischen Daten aus dem Datenspeicher 220 vor dem Speichern der Daten im EMR-System 402 umfassen. Die Daten können im EMR-System 402 als strukturierte Daten gespeichert werden.
  • Eine Benutzerschnittstelle, ähnlich der hier beschriebenen Startzeit 508 und Endzeit 510 (5), kann verwendet werden, um von einem Benutzer einen Zeitrahmen abzufragen und zu akzeptieren, in dem das System periodisch automatisch Daten von dem Herzpumpen-Controller 200-204 oder dem Datenspeicher 220 abholen und die Daten automatisch im EMR-System 402 speichern soll. Eine ähnliche Benutzerschnittstelle kann verwendet werden, um eine Häufigkeit, mit der die Daten abgeholt werden sollen, oder einen Zeitraum zwischen aufeinanderfolgenden Abholen abzufragen und zu akzeptieren. Die abzuholenden und zu speichernden Datentypen können mit einer Benutzerschnittstelle abgefragt und akzeptiert werden, die den hier beschriebenen Benutzerschnittstellen 504 und 426 ähnlich ist, in Bezug auf 4, 5 und 6.
  • Diese Ausführungsform umfasst einen Herzpumpen-Identifikator 404, eine Netzwerkschnittstelle 408, einen Datenelement-Identifikator 410, einen Controller 414, einen Monitor 418 und einen EMR-Datenaktualisierer 428, wie hier beschrieben.
  • Die Benutzerschnittstelle 412 des Datenelement-Identifikators 410 ist jedoch ferner so konfiguriert, dass der Benutzer in Verbindung mit der Identifikation des mindestens einen Datentyps ein Aktualisierungsintervall eingeben kann. 5 zeigt eine beispielhafte Aufforderung und ein Eingabefeld 514 zum Empfangen einer Benutzer-Eingabe eines Aktualisierungsintervalls. Der Controller 414 ist ferner so konfiguriert, dass er als Reaktion auf den Empfang des Aktualisierungsintervalls 514 automatisch aktualisierte entsprechende Daten über die Netzwerkschnittstelle von dem Cloud-basierten Server 218 im Aktualisierungsintervall anfordert. Der EMR-Datenaktualisierer 428 ist ferner so konfiguriert, dass er die vom Monitor 418 empfangenen aktualisierten entsprechenden Daten 420 automatisch als strukturierte Daten im EMR-System 402 in Verbindung mit dem Patienten speichert.
  • Wie bereits erwähnt, ist 9 ein Flussdiagramm, das schematisch die von dem Datenelement-Identifikator 410 durchgeführten Vorgänge veranschaulicht. Bei 906 gibt der Datenelement-Identifikator 410 das Aktualisierungsintervall 514 ein.
  • Wie bereits erwähnt, ist 10 ein Flussdiagramm, das schematisch die vom Controller 414 durchgeführten Vorgänge darstellt. Der gestrichelte Pfeil 1006 stellt Vorgänge dar, die von anderen Komponenten wie dem Monitor 418 und dem EMR-Datenaktualisierer 428 durchgeführt werden. Bei 1008, nachdem das Aktualisierungsintervall abgelaufen ist, kehrt die Steuerung zu 1004 zurück, und der Controller 414 fordert wiederholt automatisch aktualisierte entsprechende Daten über die Netzwerkschnittstelle vom Cloud-basierten Server 218 an. Wie durch den gestrichelten Pfeil 1006 angedeutet, empfängt der Monitor 418 (Vorgang 1100, 11) die entsprechenden Daten 420, die von dem Cloud-basierten Server 218 als Reaktion auf die Anforderung 416 übertragen wurden, und der EMR-Datenaktualisierer 428 speichert automatisch (Vorgang 1406, 14) die aktualisierten entsprechenden Daten 420 im EMR-System 402.
  • Während die Erfindung anhand der oben beschriebenen beispielhaften Ausführungsformen beschrieben wird, können Modifikationen und Variationen der dargestellten Ausführungsformen vorgenommen werden, ohne von den hier offengelegten erfinderischen Konzepten abzuweichen. Zum Beispiel können, obwohl spezifische Parameterwerte in Bezug auf offengelegte Ausführungsformen genannt werden, im Rahmen der Erfindung die Werte aller Parameter über weite Bereiche variieren, um verschiedenen Anwendungen gerecht zu werden. Sofern im Kontext nichts anderes angegeben ist oder von einem Fachmann verstanden wird, bedeuten Begriffe wie „etwa“ innerhalb von ±20 %.
  • Wie hierin, einschließlich in den Ansprüchen, verwendet, bedeutet der Begriff „und/oder“ in Verbindung mit einer Liste von Gegenständen einen oder mehrere der Gegenstände in der Liste, d. h. mindestens einen der Gegenstände in der Liste, aber nicht unbedingt alle Gegenstände in der Liste. Wie hierin und in den Ansprüchen verwendet, bedeutet der Begriff „oder“ in Verbindung mit einer Liste von Gegenständen einen oder mehrere der Gegenstände in der Liste, d. h. mindestens einen der Gegenstände in der Liste, aber nicht notwendigerweise alle Gegenstände in der Liste. „Oder“ bedeutet nicht „ausschließlich oder“.
  • Obwohl Aspekte von Ausführungsformen unter Bezugnahme auf Flussdiagramme und/oder Blockdiagramme beschrieben werden können, können Funktionen, Vorgänge, Entscheidungen usw. aller oder eines Teils der einzelnen Blöcke oder einer Kombination von Blöcken kombiniert, in separate Vorgänge aufgeteilt oder in anderer Reihenfolge ausgeführt werden. Verweise auf ein „Modul“ oder einen „Schritt“ dienen der Vereinfachung und sollen die Umsetzung nicht einschränken. Alle oder ein Teil der einzelnen Blöcke, Module oder Kombinationen davon können als Computerprogrammanweisungen (z. B. Software), Hardware (z. B. kombinatorische Logik, anwendungsspezifische integrierte Schaltkreise (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), Prozessoren oder andere Hardware), Firmware oder Kombinationen davon implementiert werden.
  • Der Herzpumpen-Datensynchronisierer 400 oder Teile davon können von einem oder mehreren Prozessoren implementiert werden, die in einem Speicher gespeicherte Anweisungen ausführen oder von diesen gesteuert werden. Jeder Prozessor kann ein Allzweckprozessor sein, wie z. B. eine Zentraleinheit (CPU), eine Grafikverarbeitungseinheit (GPU), ein digitaler Signalprozessor (DSP), ein Spezialprozessor usw., oder eine Kombination davon.
  • Bei dem Speicher kann es sich um einen Speicher mit wahlfreiem Zugriff (RAM), einen Festwertspeicher (ROM), einen Flash-Speicher oder einen anderen Speicher oder eine Kombination davon handeln, der für die Speicherung von Steuersoftware oder anderen Anweisungen und Daten geeignet ist. Anweisungen, die die Funktionen der vorliegenden Erfindung definieren, können einem Prozessor in vielen Formen zugeführt werden, einschließlich, aber nicht beschränkt auf Informationen, die dauerhaft auf greifbaren, nicht übertragbaren, nicht beschreibbaren Speichermedien gespeichert sind (z. B., (z. B. Festwertspeichergeräte in einem Computer, wie ROM, oder Geräte, die von einem Computer-E/A-Zusatzgerät gelesen werden können, wie CD-ROM- oder DVD-Disks), Informationen, die veränderbar auf greifbaren, nicht transitorischen, beschreibbaren Speichermedien (z. B. Disketten, entfernbare Flash-Speicher und Festplatten) gespeichert sind, oder Informationen, die über ein Kommunikationsmedium, einschließlich verdrahteter oder drahtloser Computernetze, an einen Computer übermittelt werden. Auch wenn Ausführungsformen in Verbindung mit verschiedenen illustrativen Datenstrukturen beschrieben werden, können Systeme unter Verwendung einer Vielzahl von Datenstrukturen realisiert werden.
  • Offengelegte Aspekte oder Teile davon können in einer Weise kombiniert werden, die oben nicht aufgeführt und/oder nicht ausdrücklich beansprucht wird. Darüber hinaus können die hierin offenbarten Ausführungsformen in geeigneter Weise ohne jedes Element, das hierin nicht ausdrücklich offenbart ist, ausgeführt werden. Dementsprechend sollte die Erfindung nicht als auf die offengelegten Ausführungsformen beschränkt angesehen werden.
  • Die hier verwendeten numerischen Begriffe wie „erster“, „zweiter“ und „dritter“ dienen zur Unterscheidung der jeweiligen Aufforderungen voneinander und sollen nicht unbedingt eine bestimmte Reihenfolge oder Gesamtzahl von Aufforderungen in einer bestimmten Ausführungsform angeben. So kann eine bestimmte Ausführungsform zum Beispiel nur eine zweite Aufforderung und eine dritte Aufforderung enthalten.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 63216931 [0001]
    • US 2020/0098473 [0033]
    • US 16/370951 [0033]
    • US 16/365293 [0033]
    • US 16/360270 [0033]
    • US 16/458093 [0033]

Claims (20)

  1. Herzpumpen-Datensynchronisierer für zeitkorrelierte Daten, wobei der Synchronisierer umfasst: einen Herzpumpen-Identifikator, der so konfiguriert ist, dass er zu einem elektronischen medizinischen Aufzeichnungssystem (EMR) hinzugefügt und darin betrieben werden kann, auf das gemäß Patienten-Identifikatoren zugegriffen werden kann und das Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert, wobei der Herzpumpen-Identifikator eine erste Benutzerschnittstelle enthält, die so konfiguriert ist, dass sie einem Benutzer eine erste Aufforderung zur Eingabe eines lokal eingegebenen Identifikators von (a) einer Herzpumpe und/oder (b) einem Patienten mit einer implantierten Herzpumpe anzeigt; eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie zu dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann und über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommunizieren kann, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat, wobei der Cloud-basierte Server historische zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen; einen Datenelement-Identifikator, der so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann, wobei der Datenelement-Identifikator eine zweite Benutzerschnittstelle enthält, die so konfiguriert ist, dass sie dem Benutzer eine zweite Aufforderung zur Eingabe einer Zeit und einer Identifikation mindestens eines Datentyps aus der Vielzahl der Datentypen anzeigt, wobei die Zeit und die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden sind; einen Controller, der kommunikativ mit dem Herzpumpen-Identifikator, der Netzwerkschnittstelle und dem Datenelement-Identifikator gekoppelt ist, wobei der Controller so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann, wobei der Controller weiter so konfiguriert ist, dass er als Reaktion auf den Empfang des lokal eingegebenen Identifikators, der Zeit und des mindestens einen Datentyp-Identifikators über die Netzwerkschnittstelle den lokal eingegebenen Identifikator, die Zeit, den mindestens einen Datentyp-Identifikator und eine entsprechende Datenanforderung an den Cloud-basierten Server sendet; einen Monitor, der kommunikativ mit der Netzwerkschnittstelle gekoppelt und so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann, wobei der Monitor so konfiguriert ist, dass er über die Netzwerkschnittstelle von dem Cloud-basierten Server entsprechende Daten empfängt, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen werden; und ein Ausgabeportal, das kommunikativ mit dem Monitor gekoppelt ist und so konfiguriert ist, dass es zu dem EMR-System hinzugefügt und in diesem betrieben werden kann, wobei das Ausgabeportal so konfiguriert ist, dass es die entsprechenden Daten, die von dem Cloud-basierten Server empfangen wurden, dem Benutzer anzeigt.
  2. Herzpumpen-Datensynchronisierer nach Anspruch 1, wobei der Herzpumpen-Datensynchronisierer weiter umfasst: eine Datenauswahleinrichtung, die so konfiguriert ist, dass sie zu dem EMR-System hinzugefügt und in diesem betrieben werden kann, wobei die Datenauswahleinrichtung eine dritte Benutzerschnittstelle enthält, die so konfiguriert ist, dass sie dem Benutzer eine dritte Aufforderung zur Auswahl mindestens eines Teils der entsprechenden Daten anzeigt, die dem Benutzer angezeigt werden; und einen EMR-Datenaktualisierer, der so konfiguriert ist, dass er zu dem EMR-System hinzugefügt und darin betrieben werden kann, und dass er in dem EMR-System als strukturierte Daten in Verbindung mit einem Patienten-Identifikator den ausgewählten mindestens einen Teil der entsprechenden Daten, die dem Benutzer angezeigt werden, speichert.
  3. Herzpumpen-Datensynchronisierer nach Anspruch 2, wobei: der Monitor so konfiguriert ist, dass er über die Netzwerkschnittstelle von dem Cloud-basierten Server einen Patienten-Identifikator empfängt, der den von dem Cloud-basierten Server als Reaktion auf die Anfrage übertragenen Daten entspricht; und der EMR-Datenaktualisierer so konfiguriert ist, dass er den ausgewählten mindestens einen Teil der entsprechenden Daten im EMR-System in Verbindung mit dem vom Monitor empfangenen Patienten-Identifikator speichert.
  4. Herzpumpen-Datensynchronisierer nach Anspruch 2, wobei: der lokal eingegebene Identifikator einen Patienten-Identifikator umfasst; und der EMR-Datenaktualisierer so konfiguriert ist, dass er den ausgewählten mindestens einen Teil der entsprechenden Daten in dem EMR-System in Verbindung mit dem lokal eingegebenen Identifikator speichert.
  5. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 4, wobei: jede implantierte Herzpumpe mechanisch mit einer jeweiligen Herzpumpensteuerung gekoppelt ist, die einen Anzeigebildschirm umfasst, auf dem Betriebsdaten der implantierten Herzpumpe angezeigt werden, und jede Herzpumpensteuerung so konfiguriert ist, dass sie einen jeweiligen Videostrom, der den Inhalt des Anzeigebildschirms darstellt, an den Cloud-basierten Server sendet; die historischen zeitkorrelierten Betriebsdaten, die von dem Cloud-basierten Server gespeichert werden, zumindest teilweise von dem Cloud-basierten Server aus den jeweiligen Videoströmen von den jeweiligen Herzpumpensteuergeräten abgeleitet werden; die entsprechenden Daten, die von dem Monitor von dem Cloud-basierten Server empfangen werden, Nicht-Videodaten sind; und das Ausgangsportal einen Videosignal-Synthesizer umfasst, der so konfiguriert ist, dass er aus den entsprechenden Daten zumindest teilweise einen Videostrom wiederherstellt, um dadurch die entsprechenden Daten dem Benutzer anzuzeigen.
  6. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 5, wobei der lokal eingegebene Identifikator eine Seriennummer einer jeweiligen implantierten Herzpumpe umfasst.
  7. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 6, wobei der lokal eingegebene Identifikator einen Patienten-Identifikator umfasst.
  8. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 7, das weiter einen Scanner umfasst, der so konfiguriert ist, dass er einen Strichcode liest, der einen Herzpumpen-Identifikator darstellt, und den Herzpumpen-Identifikator als den lokal eingegebenen Identifikator bereitstellt.
  9. Herzpumpen-Datensynchronisierer nach Anspruch 8, wobei der Scanner drahtlos mit dem Herzpumpen-Identifikator verbunden ist.
  10. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 9, das weiter eine Kamera umfasst, die so konfiguriert ist, dass sie Zeichen liest, die einen Herzpumpen-Identifikator darstellen, und der Herzpumpen-Identifikator als den lokal eingegebenen Identifikator bereitstellt.
  11. Herzpumpen-Datensynchronisierer nach Anspruch 10, wobei die Kamera drahtlos mit dem Herzpumpen-Identifikator gekoppelt ist.
  12. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 11, wobei die Netzwerkschnittstelle so konfiguriert ist, dass sie mit dem Cloud-basierten Server über eine Anwendungsprogrammierschnittstelle (API) kommuniziert, die von dem Cloud-basierten Server bereitgestellt wird.
  13. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 1 bis 12, wobei die historischen Betriebsdaten einen von einer Blutpumpe gemessenen Blutdruck, eine Blutpumpen-Motordrehzahl, einen Blutpumpen-Motorstrom, eine Heparin-Infusionsrate durch eine Blutpumpe und/oder Blutpumpen-Spülinformationen umfassen.
  14. Herzpumpen-Datensynchronisierer für zeitkorrelierte Daten, wobei der Synchronisierer umfasst: einen Herzpumpen-Identifikator, der so konfiguriert ist, dass er zu einem elektronischen medizinischen Aufzeichnungssystem (EMR) hinzugefügt und darin betrieben werden kann, auf das gemäß Patienten-Identifikatoren zugegriffen werden kann und das Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert, wobei der Herzpumpen-Identifikator eine Benutzerschnittstelle enthält, die so konfiguriert ist, dass sie einem Benutzer eine erste Aufforderung zur Eingabe eines lokal eingegebenen Identifikators von (a) einer Herzpumpe und/oder (b) einem Patienten mit einer implantierten Herzpumpe anzeigt; eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie zu dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann und über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommunizieren kann, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat, wobei der Cloud-basierte Server zeitkorrelierte Betriebsdaten über eine Vielzahl von implantierten Herzpumpen speichert, wobei die Betriebsdaten eine Vielzahl von Datentypen für jede implantierte Herzpumpe umfassen; einen Datenelement-Identifikator, der so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und darin betrieben werden kann, wobei der Datenelement-Identifikator eine Benutzerschnittstelle enthält, die so konfiguriert ist, dass sie dem Benutzer eine zweite Aufforderung zur Identifizierung mindestens eines Datentyps aus der Vielzahl von Datentypen anzeigt, wobei die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden ist; einen Controller, der kommunikativ mit dem Herzpumpen-Identifikator, der Netzwerkschnittstelle und dem Datenelement-Identifikator gekoppelt ist und so konfiguriert ist, dass er dem EMR-System hinzugefügt und darin betrieben werden kann, wobei der Controller weiter so konfiguriert ist, dass er als Reaktion auf den Empfang des lokal eingegebenen Identifikators und des mindestens einen Datentyp-Identifikators über die Netzwerkschnittstelle den lokal eingegebenen Identifikator, den mindestens eine Datentyp-Identifikation und eine damit korrespondierende Datenanforderung an den Cloud-basierten Server sendet; einen Monitor, der kommunikativ mit der Netzwerkschnittstelle gekoppelt und so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und darin betrieben werden kann, wobei der Monitor so konfiguriert ist, dass er über die Netzwerkschnittstelle von dem Cloud-basierten Server entsprechende Daten empfängt, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen werden; und einen EMR-Datenaktualisierer, der so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann, und dass er in Verbindung mit einem Patienten, der dem lokal eingegebenen Identifikator zugeordnet ist, die entsprechenden Daten, die von dem Monitor empfangen werden, automatisch als strukturierte Daten in dem EMR-System speichert.
  15. Herzpumpen-Datensynchronisierer nach Anspruch 14, wobei die mehreren Datentypen mindestens zwei der folgenden umfassen: einen von einer Blutpumpe gemessenen Blutdruck, eine Blutpumpen-Motordrehzahl, einen Blutpumpen-Motorstrom, eine Heparin-Infusionsrate durch eine Blutpumpe oder Blutpumpen-Spülinformationen.
  16. Herzpumpen-Datensynchronisierer nach einem der Ansprüche 14 und 15, wobei: die Benutzerschnittstelle des Datenelement-Identifikators weiter so konfiguriert ist, dass sie von dem Benutzer in Verbindung mit der Identifizierung des mindestens einen Datentyps ein Aktualisierungsintervall eingibt; der Controller weiter so konfiguriert ist, dass er als Reaktion auf den Empfang des Aktualisierungsintervalls automatisch aktualisierte entsprechende Daten über die Netzwerkschnittstelle von dem Cloud-basierten Server in dem Aktualisierungsintervall anfordert; und der EMR-Datenaktualisierer weiter so konfiguriert ist, dass er die vom Monitor empfangenen aktualisierten entsprechenden Daten in Verbindung mit dem Patienten automatisch als strukturierte Daten in dem EMR-System speichert.
  17. Verfahren zur Steuerung eines Herzpumpen-Datensynchronisierers, wobei: der Herzpumpen-Datensynchronisierer einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und ein Ausgabeportal umfasst, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines elektronischen medizinischen Aufzeichnungssystems (EMR) konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und das Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert; die Netzwerkschnittstelle so konfiguriert ist, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der von dem EMR-System getrennt ist und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Mehrzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Mehrzahl von Datentypen für jede implantierte Herzpumpe umfassen; und das Verfahren umfasst: Anzeigen, mit einer ersten Benutzerschnittstelle des Herzpumpen-Identifikators, einer ersten Aufforderung an einen Benutzer zur Eingabe eines lokal eingegebenen Identifikators von (a) einer Herzpumpe und/oder (b) einem Patienten mit einer implantierten Herzpumpe; Anzeigen, mit einer zweiten Benutzerschnittstelle des Datenelement-Identifikators, einer zweiten Aufforderung an den Benutzer zur Eingabe einer Zeit und einer Identifikation von mindestens einem Datentyp der Vielzahl von Datentypen, wobei die Zeit und die mindestens eine Datentypidentifikation mit dem lokal eingegebenen Identifikator verbunden sind; Senden des lokal eingegebenen Identifikators, der Zeit, der mindestens einen Datentyp-Identifikation und einer entsprechenden Datenanforderung mit dem Controller über die Netzwerkschnittstelle an den Cloud-basierten Server; Empfangen von entsprechenden Daten, die von dem Cloud-basierten Server als Reaktion auf die Anforderung übertragen wurden, mit dem Monitor über die Netzwerkschnittstelle; und Anzeigen der entsprechenden Daten für den Benutzer über das Ausgabeportal.
  18. Verfahren nach Anspruch 17, wobei: der Herzpumpen-Datensynchronisierer weiter einen EMR-Datenaktualisierer umfasst, der so konfiguriert ist, dass er dem EMR-System hinzugefügt und in diesem betrieben werden kann; und das Verfahren weiter das Speichern, mit dem EMR-Datenaktualisierer, als strukturierte Daten, in Verbindung mit dem lokal eingegebenen Identifikator, von mindestens einem Teil der entsprechenden Daten, die dem Benutzer angezeigt werden, umfasst.
  19. Nicht-übertragbares computerlesbares Speichermedium mit darauf gespeicherten Anweisungen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, einen Herzpumpen-Datensynchronisierer zu steuern, wobei: der Herzpumpen-Datensynchronisierer einen Herzpumpen-Identifikator, eine Netzwerkschnittstelle, einen Datenelement-Identifikator, einen Controller, einen Monitor und ein Ausgabeportal umfasst, von denen jeder für die Hinzufügung zu und den Betrieb innerhalb eines elektronischen medizinischen Aufzeichnungssystems (EMR) konfiguriert ist, das gemäß Patienten-Identifikatoren zugänglich ist und das Informationen über eine Vielzahl von Herzpumpen-Patienten und eine Vielzahl von Nicht-Herzpumpen-Patienten speichert; die Netzwerkschnittstelle so konfiguriert ist, dass sie über ein Weitverkehrs-Computernetzwerk mit einem Cloud-basierten Server kommuniziert, der sich von dem EMR-System unterscheidet und ansonsten keine Kommunikationsverbindung mit diesem hat und der historische zeitkorrelierte Betriebsdaten über eine Mehrzahl von implantierten Herzpumpen speichert, wobei die historischen Betriebsdaten eine Mehrzahl von Datentypen für jede implantierte Herzpumpe umfassen; und die Steuerung des Herzpumpen-Datensynchronisierers umfasst: Steuern einer ersten Benutzerschnittstelle des Herzpumpen-Identifikators zur Anzeige einer ersten Aufforderung an einen Benutzer zur Eingabe eines lokal eingegebenen Identifikators von (a) einer Herzpumpe und/oder (b) einem Patienten mit einer implantierten Herzpumpe; Steuern einer zweiten Benutzerschnittstelle des Datenelement-Identifikators zur Anzeige einer zweiten Aufforderung an den Benutzer zur Eingabe einer Zeit und einer Identifikation von mindestens einem Datentyp der Vielzahl von Datentypen, wobei die Zeit und die mindestens eine Datentyp-Identifikation mit dem lokal eingegebenen Identifikator verbunden sind; Senden des lokal eingegebenen Identifikators, der Zeit, der mindestens einen Datentyp-Identifikation und einer damit korrespondierenden Datenanforderung über die Netzwerkschnittstelle an den Cloud-basierten Server; und Steuern des Ausgabeportals zur Anzeige der entsprechenden Daten, die vom Cloud-basierten Server als Reaktion auf die Anforderung übertragen und vom Monitor über die Netzwerkschnittstelle empfangen werden.
  20. Nicht-übertragbares computerlesbares Speichermedium nach Anspruch 19, wobei: der Herzpumpen-Datensynchronisierer weiter einen EMR-Datenaktualisierer umfasst, der so konfiguriert ist, dass er dem EMR-System hinzugefügt werden kann und in diesem betrieben werden kann; und die Steuerung des Herzpumpendaten-Synchronisierers weiter die Steuerung des EMR-Datenaktualisierers umfasst, um als strukturierte Daten in Verbindung mit dem lokal eingegebenen Identifikator mindestens einen Teil der entsprechenden Daten zu speichern, die dem Benutzer angezeigt werden.
DE112022003325.8T 2021-06-30 2022-06-28 Schnittstelle zwischen einer herzpumpen-controller-datenbank und einem krankenhaus Pending DE112022003325T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163216931P 2021-06-30 2021-06-30
US63/216,931 2021-06-30
PCT/US2022/035277 WO2023278413A1 (en) 2021-06-30 2022-06-28 Interface between heart pump controller database and hospital

Publications (1)

Publication Number Publication Date
DE112022003325T5 true DE112022003325T5 (de) 2024-04-25

Family

ID=82742962

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112022003325.8T Pending DE112022003325T5 (de) 2021-06-30 2022-06-28 Schnittstelle zwischen einer herzpumpen-controller-datenbank und einem krankenhaus

Country Status (10)

Country Link
US (1) US20230011929A1 (de)
EP (1) EP4364164A1 (de)
KR (1) KR20240024080A (de)
CN (1) CN117581311A (de)
AU (1) AU2022301171A1 (de)
CA (1) CA3221665A1 (de)
DE (1) DE112022003325T5 (de)
IL (1) IL309280A (de)
TW (1) TW202313140A (de)
WO (1) WO2023278413A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117524455B (zh) * 2024-01-05 2024-03-22 苏州同心医疗科技股份有限公司 植入式左心室辅助装置的智能化信息管理方法及其装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200098473A1 (en) 2018-09-20 2020-03-26 Abiomed, Inc. Data Storage and Retrieval System for Non-Contiguous Medical Device Operational Data

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130317852A1 (en) * 2012-05-22 2013-11-28 Geneva Healthcare, LLC Medical device information portal
US20200312450A1 (en) * 2019-03-30 2020-10-01 Abiomed, Inc. Medical Device Location and Tracking System
US11527322B2 (en) * 2019-06-30 2022-12-13 Abiomed, Inc. Context-based user interface to medical database

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200098473A1 (en) 2018-09-20 2020-03-26 Abiomed, Inc. Data Storage and Retrieval System for Non-Contiguous Medical Device Operational Data

Also Published As

Publication number Publication date
TW202313140A (zh) 2023-04-01
US20230011929A1 (en) 2023-01-12
IL309280A (en) 2024-02-01
AU2022301171A1 (en) 2023-12-14
CA3221665A1 (en) 2023-01-05
CN117581311A (zh) 2024-02-20
KR20240024080A (ko) 2024-02-23
WO2023278413A1 (en) 2023-01-05
EP4364164A1 (de) 2024-05-08

Similar Documents

Publication Publication Date Title
DE102008056013B4 (de) Patientenbehandlungsplanungssystem sowie computerimplementiertes Verfahren zum Erstellen eines Patientenbehandlungsplans
DE3741017C2 (de) Einrichtung zur Bildarchivierung und -übermittlung
DE102006036584B4 (de) Verwalten von unterschiedlich versionierten Konfigurationsdateien einer medizinischen Einrichtung
DE102007017552A1 (de) Fallabhängige Krankheitsverlaufsvorhersage bei einem Echtzeit-Überwachungssystem
DE102004047958A1 (de) System und Verfahren zur Planung von medizinischen Terminen und Untersuchungsabläufen
DE10126570A1 (de) Web-basierte Berichtfunktionalität und Entwurf für eine diagnostische Abbildungsentscheidungsunterstützung
DE102007050184B4 (de) Integrierte Lösung für diagnostische Lese- und Berichterstellung
DE102006046319B4 (de) Verfahren zum Auffinden und zur Anzeige von Informationen in einem Informationssystem einer medizinischen Einrichtung
DE102004013650A1 (de) System und Verfahren zur Verarbeitung von Information betreffend Labortests und Ergebnisse
DE102012103089A1 (de) System und maschinenlesbarer Datenträger zur Erstellung von Patientenprognosen
DE102004011168A1 (de) Medizinisches Versorgungssystem, welches mehrere vernetzte Fluidverabreichungspumpen unterstützt
DE102005056081A1 (de) Workflow-Generator für medizinisch-klinische Einrichtungen
DE102006000713A1 (de) Medizinisches Bildbetrachtungsmanagement- und Statussystem
DE102010016118A1 (de) Patientenüberwachungssystem und -verfahren
EP2722657A1 (de) Patientenwaage mit Kameraüberwachung und Dialysetherapiesystem mit kameraüberwachtem Wiegeablauf
DE102006057149A1 (de) System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten
DE4023785A1 (de) System zur speicherung, bereitstellung und aktualisierung von festen und/oder variablen patienten- und behandlungsdaten
DE102009006148A1 (de) Bildvolumen-Browser mit variabel einstellbarem Orientierungsmaß
DE102016213515A1 (de) Verfahren zur Unterstützung eines Befunders bei der Auswertung eines Bilddatensatzes, Bildaufnahmeeinrichtung, Computerprogramm und elektronisch lesbarer Datenträger
DE10316298A1 (de) Verfahren und Anordnung zur automatischen Aufbereitung und Auswertung medizinischer Daten
DE10227542A1 (de) Verfahren und System zum Erfassen und Analysieren von Krankheitsbildern und deren Ursachen sowie zum Ermitteln passender Therapievorschläge
DE112022003325T5 (de) Schnittstelle zwischen einer herzpumpen-controller-datenbank und einem krankenhaus
DE112019002930T5 (de) Vorrichtung, verfahren und programm zur unterstützung der erstellung eines patientenfragebogens
DE102007031686A1 (de) Verfahren und System zum klinischen Interpretieren und Überprüfen von Patientendaten
EP2966581A1 (de) Netzwerksystem und Verfahren zur Steuerung eines Computertomographen