DE102019113070A1 - Techniken zum begrenzen von risiken bei der elektronischen übermittlung von patienteninformationen - Google Patents

Abstract

Es werden Techniken zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen offengelegt. In einer bestimmten Ausführungsform können die Techniken als Verfahren zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen gemäß einer Reihe von Anweisungen realisiert werden, die auf einem Speicher einer Computervorrichtung gespeichert und von einem Prozessor der Computervorrichtung ausgeführt werden, wobei das Verfahren die folgenden Schritte umfasst: Bestimmen einer Anzahl von elektronischen sicherheitsbezogenen Diensten, die von einem Gesundheitsdienstleister eingesetzt werden, der Patienteninformationen elektronisch übermittelt; Berechnen eines Deckungsgrades einer Haftpflichtversicherung, die dem Gesundheitsdienstleister bereitzustellen ist, basierend auf der Anzahl der Leistungen; und Berechnen von Prämienkosten der Haftpflichtversicherung basierend auf der Anzahl der Leistungen.

Description

• QUERVERWEIS AUF VERWANDTE ANWENDUNGEN
• Diese Patentanmeldung beansprucht den Vorrang der am 17. Mai 2018 eingereichten vorläufigen US-Patentanmeldung Nr. 62/672.858 , die durch Bezugnahme in ihrer Gesamtheit hierin aufgenommen wird.
• Diese Patentanmeldung bezieht sich auf: U.S. Patentanmeldung Nr. 14/643,910 , eingereicht am 10. März 2015, mit dem Titel „Methods and Systems für Common Key Services“; U.S. Patentanmeldung Nr. 15/847,506 , eingereicht am 19. Dezember 2017, mit dem Titel „Dynamic Network of Active Relationships with Semantic Information“; U.S. Patentanmeldung Nr. 15/961.605 , eingereicht am 24. April 2018, mit dem Titel „Secure, Accurate, and Efficient Patient Intake Systems and Methods“; und die am 11. Mai 2018 eingereichte US-Patentanmeldung Nr. 15/977.690 mit dem Titel „Systems and Methods for Managing Data Privacy“, von denen jede durch Bezugnahme in seiner Gesamtheit hierin aufgenommen wird.
• GEBIET DER OFFENBARUNG
• Die vorliegende Offenbarung bezieht sich im Allgemeinen auf das Begrenzen von Risiken bei der elektronischen Kommunikation und insbesondere auf Techniken zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen.
• HINTERGRUND DER OFFENBARUNG
• Es ist üblich, dass Parteien, die Leistungen erbringen und erhalten, über elektronische Medien miteinander kommunizieren. So können die Parteien beispielsweise über elektronische Medien, wie beispielsweise E-Mail, miteinander kommunizieren. In einem anderen Beispiel kann eine Partei den Speicher verwalten und Besuchern den Zugriff auf den Speicher über ein Abrufprotokoll, wie beispielsweise ein File Transfer Protocol (FTP), ermöglichen. Da sensiblere Informationen elektronisch übermittelt werden, müssen die Parteien Vorkehrungen treffen, um die Privatsphäre und den Schutz der Informationen zu gewährleisten.
• Einige dieser Vorsichtsmaßnahmen können durch Bundesgesetze oder -vorschriften vorgeschrieben oder gefordert sein. Insbesondere können Statuten vorschreiben, dass bei der Weitergabe von Informationen von einer Partei an eine andere (z.B. von einem ersten Gesundheitsdienstleister an einen zweiten Gesundheitsdienstleister) bestimmte Sicherheits- und Datenschutzbelange durch Schutztechniken wie Verschlüsselung gewahrt werden, um die Wahrscheinlichkeit von Sicherheitsverletzungen und Verstößen gegen Datenschutzbestimmungen durch die Offenlegung persönlicher Gesundheitsinformationen (PHI) zu verringern. So sind beispielsweise im Gesundheitswesen zwei Verfügungen, die Patienteninformation betreffen, durch das Bundesgesetz vorgeschrieben - der Health Information Portability and Accountability Act (HIPAA) und der Health Information Technology for Economic and Clinical Health Act (HITECH) Act. Dementsprechend haben verschiedene Gesundheitsdienste, Gesundheitsdienstleister und Interessengruppen Prozesse und Verfahren implementiert, um den sicheren Umgang und die sichere Kommunikation von Patienteninformationen zu gewährleisten.
• Zu diesem Zweck hat das Office of the National Coordinator (ONC) das Direct Project eingerichtet, das ein Standardprotokoll für Secure Messaging per E-Mail definiert. Das Direct-Protokoll ermöglicht es Teilnehmern, authentifizierte, sichere Nachrichten mit verschlüsselten Gesundheitsinformationen über das Internet an bekannte, vertrauenswürdige Empfänger zu senden. Im Wesentlichen schafft das Direct-Protokoll ein geschlossenes Netzwerk, in dem nur verifizierte und vertrauenswürdige Teilnehmer miteinander kommunizieren können. Das Direct-Protokoll verwendet das sichere Simple Mail Transfer Protocol (SMTP), um den Versand von Nachrichten von einer Partei zur anderen zu erleichtern, und benötigt spezielle digitale Sicherheitszertifikate für die Ver- und Entschlüsselung.
• Darüber hinaus kann jeder Gesundheitsdienstleister, der Patienteninformationen elektronisch weitergibt, bei einem Gesundheitsinformationsdienstleister (Health Information Service Provider, HISP) registriert werden. Ein HISP ist ähnlich wie ein Internet Service Provider (ISP), hat sich aber auf Direct Secure Messaging (Secure E-Mail) spezialisiert. Ein HISP kann viele Gesundheitseinrichtungen bedienen. Es können mehrere HISPs eingerichtet sein, und die Kommunikation zwischen HISPs kann unter Verwendung eines geschlossenen Netzwerkmessaging-Protokolls, wie beispielsweise des Direct-Protokolls, erfolgen. Jeder Gesundheitsdienstleister kann eine eindeutige Kennung haben, die von einem der HISPs vergeben wird, und die eindeutige Kennung für die Kommunikation mit anderen Gesundheitsdienstleistern verwenden. Ein HISP kann auch Dienste bereitstellen, die es Gesundheitsdienstleistern ermöglichen, Patienteninformationen sicher zu sammeln, zu pflegen und zu speichern.
• Trotz angemessener Vorsichtsmaßnahmen durch Gesundheitsdienstleister können Patienteninformationen versehentlich falsch gehandhabt werden (z.B. durch Übermittlung an einen Gesundheitsdienstleister oder einen Patienten, der nicht über die notwendigen Kenntnisse verfügt). Da Hacking in der Cyberwelt allgegenwärtig ist, können Patienteninformationen gehackt und an falsche Instanzen oder Personen weitergegeben werden. Daher ist es wahrscheinlich, dass Patienten, die Kenntnis von der missbräuchlichen Handhabung oder dem Hacken ihrer persönlichen und gesundheitlichen Daten erlangt haben oder erlangen, Klagen gegen Gesundheitsdienstleister einreichen würden, weil diese fahrlässig waren und keine angemessenen Maßnahmen zum Schutz ihrer Daten ergriffen haben. Es liegt daher im Interesse der Gesundheitsdienstleister, sich gegen solche Haftungsrisiken abzusichern. Wie in jedem Versicherungsmodell würden diese Gesundheitsdienstleister jedoch - selbst wenn sie die besten Vorkehrungen treffen würden, die ihnen zur Verfügung stehen - die Kosten für hohe Prämien tragen müssen, die dadurch entstehen, dass einige andere Gesundheitsdienstleister keine ausreichenden Vorkehrungen treffen und dadurch Patienteninformationen anfälliger für Misshandlungen oder Hacking machen.
• In Anbetracht der vorstehend beschriebenen Umstände, kann davon ausgegangen werden, dass es notwendig ist, eine Haftpflichtversicherung für Gesundheitsdienstleister bereitzustellen, die Patienteninformationen elektronisch übermitteln. Darüber hinaus kann es wünschenswert sein, dass die Gesundheitsdienstleister einer solchen Haftpflichtversicherung in der Lage sein sollten, das Deckungsniveau und die Prämien, die jedem Gesundheitsdienstleister zur Verfügung stehen, auf der Grundlage der vom Gesundheitsdienstleister getroffenen Vorsichtsmaßnahmen anzupassen.
• ZUSAMMENFASSUNG DER OFFENLEGUNG
• Es werden Techniken zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen offengelegt. In einer bestimmten Ausführungsform können die Techniken als Verfahren zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen gemäß einer Reihe von Anweisungen, die auf einem Speicher einer Computervorrichtung gespeichert und von einem Prozessor der Computervorrichtung ausgeführt werden, realisiert werden, wobei das Verfahren die folgenden Schritte umfasst: Bestimmen einer Anzahl von elektronischen sicherheitsbezogenen Diensten, die von einem Gesundheitsdienstleister eingesetzt werden, der Patienteninformationen elektronisch übermittelt; Berechnen eines Deckungsgrades einer Haftpflichtversicherung, die dem Gesundheitsdienstleister bereitzustellen ist, basierend auf der Anzahl der Leistungen; und Berechnen von Prämienkosten der Haftpflichtversicherung basierend auf der Anzahl der Leistungen.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform können die Dienste einen oder mehrere von einem aktiven Pflegedienstleistungsverhältnis (Active Care Relationship Service, ACRS), einem gemeinsamen Schlüsseldienst (Common Key Service (CKS) und einem elektronischen Einwilligungsdienst (Electronic Consent, eConsent) beinhalten.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform können die Dienste von einem Gesundheitsinformationsdienstleister (Health Information Service Provider, HISP) bereitgestellt werden.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform können die Dienste sicherstellen, dass die vom Gesundheitsdienstleister übermittelten Patienteninformationen mit den Datenstandards und Sicherheitsmaßnahmen übereinstimmen.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform können die berechneten Prämienkosten niedriger sein, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform können die berechneten Prämienkosten höher sein, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform kann der berechnete Deckungsgrad höher sein, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
• Gemäß anderen Aspekten dieser bestimmten Ausführungsform kann der berechnete Deckungsgrad niedriger sein, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
• In einer weiteren bestimmten Ausführungsform kann die Technik als ein System zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen realisiert werden, das einen oder mehrere Prozessoren umfasst, die kommunikativ mit einem Netzwerk gekoppelt sind; wobei der eine oder die mehreren Prozessoren konfiguriert sind, um die Schritte in dem oben beschriebenen Verfahren durchzuführen.
• In einer weiteren bestimmten Ausführungsform kann die Technik als ein Herstellungsgegenstand zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen realisiert werden, wobei der Herstellungsgegenstand mindestens ein prozessorlesbares Speichermedium und auf dem mindestens einen Medium gespeicherte Anweisungen umfasst, worin die Anweisungen konfiguriert sind, von dem mindestens einen Medium durch mindestens einen Prozessor lesbar zu sein und dadurch zu bewirken, dass der mindestens eine Prozessor so arbeitet, dass er die Schritte in dem oben beschriebenen Verfahren ausführt.
• Die vorliegende Offenbarung wird nun im Hinblick auf bestimmte Ausführungsformen von dieser, wie sie in den beigefügten Figuren dargestellt sind, näher beschrieben. Obwohl die vorliegende Offenbarung im Folgenden mit Bezug auf bestimmte Ausführungsformen beschrieben wird, ist zu beachten, dass die vorliegende Offenbarung nicht darauf beschränkt ist. Diejenigen mit gewöhnlichen Fähigkeiten in dem Fachgebiet, die Zugang zu den diesbezüglichen Lehren haben, werden zusätzliche Implementierungen, Modifikationen und Ausführungsformen sowie andere Anwendungsbereiche erkennen, die im Anwendungsbereich der vorliegenden Offenbarung liegen, wie hierin beschrieben, und für die die vorliegende Offenbarung von erheblichem Nutzen sein kann.
• Figurenliste
• Um ein umfassenderes Verständnis der vorliegenden Offenbarung zu ermöglichen, wird nun auf die beigefügten Figuren verwiesen, in denen gleiche Elemente mit gleichen Ziffern referenziert werden. Diese Figuren sind nicht als Einschränkung der vorliegenden Offenbarung zu verstehen, sondern sollen nur zur Veranschaulichung dienen.
• Es zeigen:
• 1 ein Flussdiagramm, das ein Verfahren zum Bestimmen des Deckungsgrades und der Prämie einer Haftpflichtversicherung darstellt, die einem Gesundheitsdienstleister gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung zu stellen ist.
• 2 ein Blockdiagramm, das eine exemplarische Computervorrichtung gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
• 3 ein exemplarisches System zum Erfassen, Pflegen und Aktualisieren von Patienteninformationen gemäß einer Ausführungsform der vorliegenden Offenbarung.
• 4 ein Flussdiagramm, das ein Verfahren zum Erzeugen eines gemeinsamen Schlüssels für bekannte Personen gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
• 5 ein Flussdiagramm, das ein Verfahren zum Erzeugen eines gemeinsamen Schlüssels für unbekannte Personen gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
• 6 ein Flussdiagramm, das ein Verfahren zum Verwenden eines bekannten gemeinsamen Schlüssels für eine bekannte Person gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
• 7 ein Flussdiagramm, das ein Verfahren zum Erfassen von Datensätzen mit einem gemeinsamen Schlüssel gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
• 8 ein Flussdiagramm, das ein Verfahren zum Überprüfen potenzieller Personenübereinstimmungen gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
• 9 ein Flussdiagramm, das ein Verfahren zum Aktualisieren von Dateien mit einem Common-Key-Service gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
• 10 ein Flussdiagramm, das ein Verfahren zum Nutzen eines Common-Key- Service in Verbindung mit einem Krankenhausbesuch eines Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
• 11 ein Flussdiagramm, das ein Verfahren zum Nutzen eines Common-Key- Service gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
• 12 ein Flussdiagramm, das den Aufnahmeprozess eines neuen Patienten bei einer Gesundheitsorganisation oder einem Gesundheitsdienstleister gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt.
• 13 ein Einwilligungsmanagementsystem gemäß einer Ausführungsform der vorliegenden Offenbarung.
• 14 ein erstes Beispiel einer grafischen Benutzeroberfläche (GUI), die einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung bereitgestellt werden kann.
• 15 eine zweite exemplarische GUI, die einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann.
• 16 eine dritte exemplarische GUI, die einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann.
• 17 eine vierte exemplarische GUI, die einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann.
• 18 ein Flussdiagramm eines ersten exemplarischen Verfahrens zum Handhaben der Datensicherheit gemäß einer Ausführungsform der vorliegenden Offenbarung.
• DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
• Unter Bezugnahme auf 1 ist ein Flussdiagramm dargestellt, das ein Verfahren 100 zum Bestimmen des Deckungsgrades und der Prämie einer Haftpflichtversicherung darstellt, die einem Gesundheitsdienstleister gemäß einer Ausführungsform der vorliegenden Offenbarung zu gewähren sind. Der hier verwendete Begriff „Haftpflichtversicherung“ kann eine Cyber-Haftpflichtversicherung beinhalten. Ein Gesundheitsdienstleister kann ein Krankenhaus, eine Krankenkasse, eine Krankenversicherung, ein Labor, einen Manager für verschreibungspflichtige Leistungen, eine Apotheke oder eine Klinik einschließen. In 1 werden der Deckungsgrad und die Prämie durch die Anzahl der Leistungen beeinflusst, die der Gesundheitsdienstleister in Anspruch nimmt, wobei die Leistungen von einem Gesundheitsinformationsdienstleister (Health Information Service Provider, HISP) oder einer anderen standardisierten Einheit erbracht werden. Obwohl drei Leistungen - Active Care Relationship Service (ACRS), Common Key Service (CKS) und Electronic Consent (eConsent) Management Service - in 1 dargestellt sind, ist das Verfahren 100 nicht auf diese Leistungen beschränkt und kann durch zusätzliche Leistungen ergänzt werden, die von einem oder mehreren HISPs oder anderen Unternehmen bereitgestellt werden. Der ACRS-, CKS- und eConsent-Managementdienst wird im Folgenden in Bezug auf die 3 bis 18 näher beschrieben.
• Das Verfahren 100 beginnt bei Operation 105 mit einem Gesundheitsdienstleister, der eine Haftpflichtversicherung für Risiken im Zusammenhang mit der elektronischen Übermittlung von Patienteninformationen sucht. Das Verfahren 100 beinhaltet das Bestimmen, welchen der ACRS-, CKS- und eConsent-Managementdienste der Gesundheitsdienstleister verwendet. Wenn der Gesundheitsdienstleister alle drei Leistungen - durch positive Feststellungen in den Operationen 110 bis 120 - in Anspruch nimmt, dann bestimmt das Verfahren 100 bei Operation 125, dass dem Gesundheitsdienstleister eine maximale Deckung und eine niedrigste Versicherungsprämie gewährt werden kann. Wenn der Gesundheitsdienstleister zwei der drei Leistungen in Anspruch nimmt - durch Operationen (110 Ja, 115 Nein und 145 Ja) oder (110 Nein, 130 Ja und 145 Ja) bestimmt -, dann bestimmt das Verfahren 100 bei Operation 150, dass dem Gesundheitsdienstleister eine mittlere Deckung und eine Prämie, die niedriger als eine Basisprämie ist, gewährt werden kann. Wenn der Gesundheitsdienstleister eine der drei Leistungen in Anspruch nimmt - durch Operationen (110 Ja, 115 Nein und 145 Nein) oder (110 Nein, 130 Nein und 135 Ja) bestimmt -, dann bestimmt das Verfahren 100 bei Operation 155, dass dem Gesundheitsdienstleister eine Basisversicherung und die Basisprämie gewährt werden können. Schließlich, wenn der Gesundheitsdienstleister keine der drei Leistungen in Anspruch nimmt, die die HISPs bereitgestellt haben - durch negatives Bestimmen in den Operationen 110, 130 und 135 -, dann bestimmt das Verfahren 100 bei Operation 140, dass dem Gesundheitsdienstleister kein Versicherungsschutz gewährt werden darf.
• Das Konzept hinter dem Verfahren 100 ist, dass, je mehr Leistungen ein Gesundheitsdienstleister in Anspruch nimmt, desto besser die Deckung ist, die ein Versicherungsunternehmen mit der niedrigsten Prämie anbieten kann. Wenn ein Gesundheitsdienstleister mehr standardisierte Leistungen von einem oder mehreren HISPs oder anderen zertifizierten Stellen in Anspruch nimmt, wird ein Versicherungsanbieter ein höheres Vertrauen haben in die Konformität und Belastbarkeit der zu erfassenden, zu übermittelnden und zu speichernden Patienteninformationen mit den in detaillierten Implementierungsleitfäden festgelegten Datenstandards (z.B. nach HL7-Standards) und den Sicherheitsmaßnahmen rund um das Erfassen, die Übermittlung und das Speichern der Patienteninformationen.
• Das Verfahren 100 kann auf mindestens einem von einem Server, einem Desktop-Computer, einem Laptop-Computer, einer Tablet-Computervorrichtung oder einer Handheld-Computervorrichtung implementiert werden. 2 ist ein Blockdiagramm, das eine exemplarische Computervorrichtung 200 gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Komponenten vorhanden sein. Die Computervorrichtung 200 kann ein beliebiges Rechengerät sein, wie beispielsweise ein Tablett, ein Smartphone, ein Laptop-Computer, ein Desktop-Computer, ein Server, eine Remote Client-Vorrichtung, eine Spielvorrichtung, eine Smart TV-Vorrichtung, ein tragbarer Computer oder eine Kombination davon. Die Computervorrichtung 200 kann mindestens einen Prozessor 202 einschließen, der mit einem Chipsatz 204 gekoppelt ist. Der Chipsatz 204 kann einen Memory-Controller-Hub 220 und einen Ein- / Ausgabe- (I/O) - Controller-Hub 222 einschließen. Ein Speicher 206 und eine Grafikkarte 212 können mit dem Memory-Controller-Hub 220 gekoppelt sein, und eine Anzeigevorrichtung 218 kann mit der Grafikkarte 212 gekoppelt sein. Eine Speichervorrichtung 208, eine Tastatur 210, eine Zeigevorrichtung 214 und ein Netzwerkadapter 216 können mit dem I/O - Controller-Hub 222 gekoppelt sein. Andere Ausführungsformen der Computervorrichtung 200 können unterschiedliche Architekturen aufweisen.
• Die Speichervorrichtung 208 kann ein nichtflüchtiges, computerlesbares Speichermedium sein, wie beispielsweise eine Festplatte, ein schreibgeschützter Compact-Disk-Speicher (CD-ROM), eine DVD oder eine Festkörperspeichervorrichtung (z.B. Nur-Lese-Speicher (ROM) und Direktzugriffsspeicher (RAM)). Der Speicher 206 kann Anweisungen und Daten enthalten, die vom Prozessor 202 verwendet werden können. Die Zeigevorrichtung 214 kann eine Maus, ein Trackball oder eine andere Art von Zeigevorrichtung sein und kann in Kombination mit der Tastatur 210 verwendet werden, um Daten in die Computervorrichtung 200 einzugeben. Die Zeigevorrichtung 214 kann auch eine Spielsystemsteuerung oder eine beliebige Art von Vorrichtung zum Steuern eines Spielsystems sein. So kann beispielsweise die Zeigevorrichtung 214 mit einer Video- oder Bilderfassungsvorrichtung verbunden werden, die ein biometrisches Abtasten verwendet, um einen bestimmten Benutzer zu erkennen. Der spezifische Benutzer kann mit Bewegung oder Gesten die Punktvorrichtung 214 steuern, um verschiedene Aspekte des Computers 200 zu steuern. Die Grafikkarte 212 kann Bilder und andere Informationen auf der Anzeigevorrichtung 218 anzeigen. Um die Interaktion mit einem Benutzer zu verbessern, können die hierin offenbarten Ausführungsformen unter Verwendung eines interaktiven Displays, wie beispielsweise einer grafischen Benutzeroberfläche (GUI), implementiert werden. Solche GUIs können interaktive Funktionen wie Popup- oder Pulldown-Menüs oder Listen, Auswahlregisterkarten und andere Funktionen beinhalten, die menschliche Eingaben empfangen können. Der Netzwerkadapter 216 kann die Computersystemvorrichtung 200 mit einem oder mehreren Computernetzwerken koppeln.
• Die Computervorrichtung 200 kann angepasst sein, um ein oder mehrere Computerprogramme auszuführen, um die hierin beschriebene Funktionalität bereitzustellen. Ein Computerprogramm (auch bekannt als Programm, Modul, Motor, Software, Softwareanwendung, Skript oder Code) kann in jeder Form von Programmiersprache geschrieben sein, einschließlich kompilierter oder interpretierter Sprachen, deklarativer oder prozeduraler Sprachen, und das Programm kann in jeder Form bereitgestellt werden, einschließlich als eigenständiges Programm oder als Modul, Komponente, Unterprogramm, Objekt oder andere Einheit, die für die Verwendung in einer Computerumgebung geeignet ist. Ein Computerprogramm kann, muss aber nicht, einer Datei in einem Dateisystem entsprechen. Ein Programm kann in einem Teil einer Datei gespeichert sein, der andere Programme oder Daten enthält (z.B. ein oder mehrere Skripte, die in einem Markup Language Dokument gespeichert sind), in einer einzelnen Datei, die dem betreffenden Programm zugeordnet ist, oder in mehreren koordinierten Dateien (z.B. Dateien, die ein oder mehrere Module, Unterprogramme oder Teile eines Codes speichern). Ein Computerprogramm kann zum Ausführen auf einer Computervorrichtung 200 oder auf mehreren Computervorrichtungen 200 bereitgestellt sein, die sich an einem Standort befinden oder über mehrere Standorte verteilt und durch ein Kommunikationsnetzwerk miteinander verbunden sind. In einer Ausführungsform können Programmmodule in der Speichervorrichtung 208 gespeichert, in den Speicher 206 geladen und vom Prozessor 202 ausgeführt werden.
• Wie hierin verwendet, bezieht sich der Begriff Modul auf die Logik des Computerprogramms, mit der die angegebene Funktionalität bereitgestellt wird. Somit kann ein Modul in Hardware, Firmware und / oder Software implementiert werden. Wie hierin verwendet, umfasst der Begriff Prozessor alle Arten von Apparaten, Vorrichtungen und Maschinen zur Datenverarbeitung, einschließlich beispielsweise eines programmierbaren Prozessors, eines Computers, eines Systems auf einem Chip oder mehrerer oder Kombinationen der vorgenannten. Der Prozessor kann eine spezielle Logikschaltung beinhalten, z.B. ein FPGA (field programmable gate array) oder ein ASIC (application-specific integrated circuit). Der Prozessor kann neben der Hardware auch einen Code beinhalten, der eine Ausführungsumgebung für das betreffende Computerprogramm schafft, z.B. Code, der die Prozessor-Firmware, einen Protokollstapel, ein Datenbankmanagementsystem, ein Betriebssystem, eine plattformübergreifende Laufzeitumgebung, eine virtuelle Maschine oder eine Kombination aus einem oder mehreren von ihnen darstellt.
• Die Arten von Computervorrichtungen, die von den hierin offenbarten Einheiten und Prozessen verwendet werden, können je nach Ausführungsform und der von der Einheit benötigten Rechenleistung variieren. Die Computervorrichtung 200 kann eine mobile Vorrichtung, ein Tablett, ein Smartphone oder eine andere Art von Computerelement mit den oben genannten Elementen sein. So kann beispielsweise eine Datenspeichervorrichtung, wie eine Festplatte, ein Halbleiterspeicher oder eine Speichervorrichtung, in einem verteilten Datenbanksystem gespeichert werden, das mehrere Blade-Server umfasst, die zusammenwirken, um die hierin beschriebene Funktionalität bereitzustellen. Den Computervorrichtungen fehlen möglicherweise einige der oben beschriebenen Komponenten, wie z.B. Tastaturen 210, Grafikadapter 212 und Anzeigevorrichtungen 218.
• Wie durch eine der üblichen Fertigkeiten in der Technik gewürdigt, können die hierin offenbarten Ausführungsformen auf jedem System, jeder Netzwerkarchitektur, Konfiguration, Vorrichtung, Maschine oder Vorrichtung implementiert werden und sind nicht so auszulegen, dass sie auf eine bestimmte Konfiguration, ein bestimmtes Netzwerk oder bestimmte Systeme beschränkt sind, auch wenn ein Beispielsystem in Bezug auf 2 dargestellt und beschrieben wird. Die hierin enthaltenen Ausführungsformen können auf herkömmlichen Computervorrichtungen, z.B. Computerarbeitsplätzen, auf internetbasierten Anwendungen, auf optischen Computervorrichtungen, Neurocomputern, biologischen Computern, molekularen Computervorrichtungen und anderen Vorrichtungen, angemessen implementiert werden. Wie von denjenigen, die im Fachgebiet erfahren sind, geschätzt werden kann, kann die vorliegende Erfindung, kurz gesagt, auf jedem System, Automaten und / oder jeder Turingmaschine implementiert werden.
• Ein Automat wird hierin als ein Mechanismus beschrieben, der relativ selbsttätig ist und dazu bestimmt ist, einer vorgegebenen Abfolge von Operationen zu folgen oder auf codierte Anweisungen zu reagieren. Eine Turingmaschine wird hierin als abstrakter Ausdruck einer Rechenvorrichtung beschrieben, die auf einer unendlichen Anzahl von verschiedenen physikalischen Rechenvorrichtungen realisiert oder implementiert werden kann. Beispiele für Systeme, Automaten und / oder Turingmaschinen, die bei der Durchführung des Verfahrens der vorliegenden Erfindung verwendet werden können, umfassen, sind aber nicht auf diese beschränkt: elektrische Computer (z.B. ein Personalcomputer von International Business Machines (IBM)); Neurocomputer (z.B. einer ähnlich dem „General Purpose Neural Computer“, beschrieben in U.S. Patent Nr. 5,155,802 , erteilt an Paul H. Müller am 13. Oktober 1992); molekulare Computer (z.B. einer ähnlich dem „Molecular Automata Using Single oder Double-Strand Oligonucleotides“, beschrieben in U.S. Pat. Nr. 5.804.373 , ausgestellt an Allan Lee Schweiter et al. am 8. September 1998); biologische Computer (z.B. einer ähnlich dem biologischen Computer, vorgestellt von Ehud Shapiro, Abteilung für Informatik und angewandte Mathematik am Weizman Institute of Science (Rehovot, Israel), beim Fünften Internationalen Treffen über DNA-basierte Computer); und optische Computer. Der Einfachheit halber werden diese Vorrichtungen im Folgenden als Computer bezeichnet, wie es in dem Fachgebiet üblich ist. Die hierin offenbarten Ausführungsformen sind jedoch nicht auf solche Vorrichtungen beschränkt und können auf jedem System oder jeder Sammlung von Systemen durchgeführt werden, die in der Lage sind, die hierin beschriebenen Merkmale und Funktionen bereitzustellen.
• Mehrere Computergeräte 200 können zu einem Computersystem aus Clients und Servern zusammengefasst werden. Ein Client und ein Server sind im Allgemeinen voneinander entfernt und interagieren typischerweise über ein Kommunikationsnetzwerk. Die Beziehung von Client und Server entsteht durch Computerprogramme, die auf den jeweiligen Computern laufen und eine Client-Server-Beziehung zueinander haben. In einigen Ausführungsformen sendet ein Server Daten (z.B. eine HTML-Seite) an einen Client (z.B. zum Anzeigen von Daten an einen Benutzer und Empfangen von Benutzereingaben von einem Benutzer, der mit der Client-Vorrichtung interagiert). Auf dem Client erzeugte Daten (z.B. ein Ergebnis der Benutzerinteraktion) können vom Client auf dem Server empfangen werden.
• Das aktive Pflegedienstleistungsverhältnis (ACRM), das ein ACRS bereitstellt, wie nachstehend in Bezug auf 3 beschrieben, die Verfahren zum Erzeugen und Verwenden von gemeinsamen Schlüsseln in einem gemeinsamen Schlüsseldienst (CKS), wie nachstehend in Bezug auf die 4 bis 12 beschrieben, und das Verfahren und System zum Erhalten der elektronischen Zustimmung eines Patienten, wie nachstehend in Bezug auf die 13 bis 18 beschrieben, können teilweise oder vollständig auf einem Prozessor, wie dem vorstehend in Bezug auf die Computervorrichtung 200 beschriebenen, implementiert oder durchgeführt werden.
• Unter Bezugnahme auf 3 ist ein exemplarisches System 300 zum Sammeln, Pflegen und Aktualisieren von Patienteninformationen gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Das System 300 beinhaltet ein ACRM-System, das verwendet werden kann, um ein ACRS bereitzustellen, eine Vielzahl von Gesundheitsorganisation -Computer 310, eine Vielzahl von Gesundheitsdienstleister-Computern 315 und eine Vielzahl von Patienten-Computern 320. Das ACRM-System 305 beinhaltet ein Ereigniserkennungsmodul 330, ein Netzwerk-Update-Modul 335, ein Netzwerk-Auswertungsmodul 340, ein Alarmgenerierungsmodul 345 und eine Datenbank 355.
• Das ACRM-System 305 ist konfiguriert, um das Erfassen, Verwalten und Verteilen von Patienteninformationen zu unterstützen. So kann beispielsweise das ACRM-System 305 Patienteninformationen von den Gesundheitsorganisation-Computern 310, den Gesundheitsdienstleister-Computern 315 und den Patienten-Computern 320 empfangen und die empfangenen Informationen verarbeiten, um Beziehungen zwischen verschiedenen Einheiten, einschließlich Patienten, Ärzten und anderen Gesundheitsdienstleistern des Gesundheitswesens, zu bestimmen. Das ACRM-System 305 kann ein semantisches Netzwerk basierend auf den Informationen, die von den Gesundheitsorganisation-Computern 310, den Gesundheitsdienstleister-Computern 315 und den Patienten-Computern 320 empfangen wurden, erzeugen und kontinuierlich aktualisieren. Das semantische Netzwerk kann eine Verbindung von Knoten sein, zu denen Patienten, Medikamente, medizinische Erkrankungen, Gesundheitsdienstleister, Krankenhäuser, Kliniken usw. gehören können, wie in der U.S. Patentanmeldung Nr. 15/847,506 beschrieben, die hierin in ihrer Gesamtheit enthalten ist.
• In einigen Ausführungsformen kann das Erzeugen und Aktualisieren des semantischen Netzwerks durch das Ereigniserkennungsmodul 330 und das Netzwerk-Update-Modul 335 durchgeführt werden. So kann beispielsweise das Ereigniserkennungsmodul 330 Informationen, die von den Gesundheitsorganisation-Computern 310, den Gesundheitsdienstleister-Computern 315 und den Patienten-Computern 320 empfangen wurden, analysieren und bestimmen, ob diese Informationen ein Ereignis darstellen, das eine Aktualisierung des semantischen Netzwerks erfordert. Das Netzwerk-Update-Modul 335 kann einen Knoten, der entweder einem Gesundheitsdienstleister oder einem Patienten entspricht, zum semantischen Netzwerk hinzufügen, wenn diese Knoten nicht bereits im semantischen Netzwerk vorhanden sind, und das Verbinden zwischen den Knoten hinzufügen oder ändern. Das Netzwerk-Update-Modul 335 kann auch semantische Informationen für die Knotenverbindung speichern. Das Netzwerkauswertungsmodul 340 kann das semantische Netzwerk analysieren, um Schlussfolgerungen zu ziehen, die für die Gesundheitsversorgung eines oder mehrerer Patienten im Netzwerk relevant sein können. So kann beispielsweise das Netzwerk-Auswertungsmodul 340 konfiguriert sein, um Muster zu erkennen, die zum Vorhersagen von Gesundheitsergebnissen oder zum Auswählen von präventiven Versorgungsstrategien für Patienten verwendet werden können. Das Alarmgenerierungsmodul 345 kann konfiguriert sein, um Warnmeldungen, wie beispielsweise eine E-Mail, eine Textnachricht, einen Telefonanruf oder eine Benachrichtigung über eine mobile Anwendung, an einen von dem Gesundheitsorganisation-Computer 310, dem Gesundheitsdienstleister-Computer 315 oder dem Patienten-Computer 320 bereitzustellen. Die Datenbank 355 kann Informationen über das semantische Netzwerk, Einwilligungsregeln, Richtlinien usw. speichern.
• In einigen Ausführungsformen können die Gesundheitsorganisation-Computer 310 jede Art oder Form von Computervorrichtungen sein, die sich im Besitz einer Gesundheitsorganisation befinden, von ihr betrieben werden oder auf die eine Gesundheitsorganisation anderweitig zugreifen kann, wie beispielsweise ein Gesundheitssystem, ein Krankenhaus, eine Krankenkasse, ein Krankenversicherer, ein Verwalter für verschreibungspflichtige Leistungen, eine Apotheke oder eine Klinik. In einigen Anordnungen ist jeder der Gesundheitsorganisation-Computer 310 der als mindestens einer von einem Server, einem Desktop-Computer oder einem Laptop implementiert, wie beispielsweise die vorstehend in Bezug auf 2 beschriebene Computervorrichtung. In einigen anderen Anordnungen kann jeder der Gesundheitsorganisation-Computer 310 eine mobile Computervorrichtung wie eine Tablet-Computer-Vorrichtung oder eine Handheld-Computer-Vorrichtung wie ein Smartphone sein, auf das ein Mitarbeiter oder ein anderer Vertreter der jeweiligen Gesundheitsorganisation zugreifen kann.
• Ebenso können die Gesundheitsdienstleister-Computer 315, die Patienten-Computer 320 und das ACRM-System 305 auch jede Art oder Form von Computervorrichtungen sein, die sich im Besitz jeweils eines Gesundheitsdienstleisters, eines Patienten oder eines ACRS-Anbieters befinden, von ihm betrieben oder anderweitig genutzt werden. Im Allgemeinen kann ein Gesundheitsdienstleister einen Arzt, einen Apotheker oder jede andere Person oder Gruppe von Personen umfassen, die Patienten medizinisch versorgt. In einigen Ausführungsformen können die Gesundheitsdienstleister-Computer 315, die Patienten-Computer 320 oder das ACRM-System 305 implementiert sein als mindestens einer von einem Server, einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer oder einem Handheld-Computer.
• Ein gemeinsamer Schlüssel bietet eine Möglichkeit, Patienten und ihre Datensätze über mehrere Organisationen, Anwendungen und Dienste hinweg abzugleichen, wie beispielsweise ein ACRS, das von einem ACRM-System (z.B. dem ACRM-System 305) unterstützt wird. Mit einem gemeinsamen Schlüssel können umfassende und vollständige Datensätze für einen Patienten abgerufen oder nach Belieben geändert werden. Selbst wenn mehrere Datensätze einem Patienten zugeordnet sind, kann ein gemeinsamer Schlüssel die verschiedenen Datensätze miteinander verbinden. Ein CKS ist sicher und geschützt, schützt die Vertraulichkeit und verfügt über eine hohe Genauigkeit und Datenintegrität der Datensätze, die von mehreren Unternehmen gemeinsam genutzt werden.
• In einer Ausführungsform der vorliegenden Offenbarung kann der Informationsaustausch zwischen Gesundheitsorganisationen und Gesundheitsdienstleistern unter Verwendung von CKSs erfolgen. Jeder Patient kann einer einzigen Identität zugeordnet werden, und dieser Identität wird ein eindeutiger gemeinsamer Schlüssel zugewiesen. Der gemeinsame Schlüssel kann eine alphanumerische Sequenz sein. Der gemeinsame Schlüssel ist für jeden Patienten eindeutig und wird verwendet, um Datensätze zu verknüpfen, die von mehreren Gesundheitsorganisationen und Gesundheitsdienstleistern gespeichert, untergebracht und / oder generiert wurden.
• Der gemeinsame Schlüssel kann, wenn dieser mit einer einzelnen Identität eines Patienten verknüpft ist, verwendet werden, um Datensätze des Patienten über mehrere Einheiten und Datenspeicher im gesamten Gesundheitsmarkt hinweg zu verknüpfen, wie z.B. Hausarztakten, Facharztakten, Krankenhausakten, demographische Datensätze, Abrechnungsinformationen, Versicherungsinformationsakten, Krankengeschichtsakten, Pflegekoordinatorendaten, Forschungsdatenbanken, onkologische Datenbanken, psychiatrische Datenbanken, Apothekendatenbanken, etc.
• Ein CKS kann verwendet werden, um Patienten mit ihren jeweiligen elektronischen Krankenakten zu verbinden. Datensätze können aus verschiedenen Formaten stammen und über verschiedene Systeme hinweg gespeichert werden. Ein gemeinsamer Schlüssel kann verwendet werden, um verschiedene Datensätze eines Patienten miteinander zu verbinden. Darüber hinaus können sich die demografischen Informationen eines Patienten (z.B. Adresse, Name, Rechnungsinformationen usw.) im Laufe der Zeit ändern, was dazu führt, dass demografische Informationen veraltet sind oder einem Fehler unterliegen. Durch die Verwendung eines gemeinsamen Schlüssels zur Verfolgung von Datensätzen können Komplikationen und Fehler bei der Behandlung von Patienten aufgrund unvollständiger Informationen und Datensätze reduziert werden.
• Ein CKS kann unpassende Datensatz- / Patientenzuordnungen minimieren und sicherstellen, dass der Buchführungsdatensatz korrekt ist. Abgleiche und Verknüpfungen zwischen einem Patienten und den Patientendaten können über mehrere Organisationen, Anwendungen und Dienste hinweg beeinträchtigt sein. Dies kann zu einer höheren Datenintegrität führen, was wiederum die Patientensicherheit erhöht, indem Fehler der Datenverwerter minimiert werden. So kann beispielsweise ein CKS eine verbesserte Patientensicherheit und Koordination der Pflege gewährleisten, indem es sicherstellt, dass Medikamenten- und Allergieinformationen über ein Kontinuum von Pflege der richtigen Person zugeordnet sind, was die Patientensicherheit erhöht und das Risiko von medizinischen Fehlern potentiell reduziert. Ein CKS kann auch den Arbeitsaufwand für die Koordination der Versorgung von Patienten in verschiedenen Organisationen, Anwendungen und Diensten reduzieren. Dies kann auch die Kosten für die Aufbewahrung von Datensätzen in Dienstleistungsunternehmen wie dem Gesundheitswesen senken. Darüber hinaus kann ein CKS implementiert werden, um die aktuellen Systeme für den Austausch von Gesundheitsinformationen (HIE) und die Gesundheitsinformationstechnologie (HIT) zu nutzen.
• In einer Ausführungsform der vorliegenden Offenbarung kann ein HIT- oder HIE-Endpunkt mittels CKSs auf einen Master Person Index (MPI) abgebildet werden. So kann beispielsweise eine Regierungsstelle wie eine Landesregierung ein MPI unterhalten. Das MPI kann ein Datensatz jeder Person, die im Staat lebt oder dem Staat bekannt ist, enthalten. Ein solches MPI kann mit Informationen gefüllt sein, die von verschiedenen Regierungsstellen erworben wurden, wie z.B. Stellen, die eine Identifizierung vornehmen, Steuern verarbeiten, Gesundheitsleistungen verarbeiten oder Schulen. Der CKS kann sicherstellen, dass alle medizinischen Datensätze einer einzigen Identität einer Person zugeordnet werden, wie sie im MPI gepflegt wird. In einer Ausführungsform der vorliegenden Offenbarung können die hierin für ein CKS offenbarten Systeme und Verfahren als Webservice ausgeführt werden, der Aufrufe der Anwendungsprogrammierschnittstelle (API) an das MPI und / oder HITs und HIEs verwendet. Eine solche Ausführungsform kann eine einfache Integration eines MPI, HIT und / oder HIE mit dem CKS ermöglichen.
• In einer Ausführungsform der vorliegenden Offenbarung kann der CKS in einem Fall verwendet werden, der ein aktives Pflegedienstleistungsverhältnis eines Gesundheitsdienstleisters oder eines Gesundheitsdienstleisters zu einem Patienten in der Gesundheitsbranche verfolgt. Beispielsweise wird ein Patient X in ein Krankenhaus aufgenommen. Das Krankenhaus kann Teil einer Data Sharing Organisation (DSO) sein. Eine solche DSO kann auch andere Gesundheitsdienstleister oder Krankenhäuser umfassen, die Teil eines einzelnen Gesundheitssystems sind. Ein Gesundheitsdienstleister, wie beispielsweise ein Arzt, im Krankenhaus kann eine ADT-Meldung (Admit-Discharge-Transfer) erzeugen, die angibt, dass Patient X in das Krankenhaus aufgenommen wurde. Die ADT-Meldung kann über die DSO, das den CKS aufruft, an ein von einem ACRM-System (z.B. ACRM-System 305) unterstütztes ACRS gesendet werden. Mit anderen Worten, wenn die DSO versucht, die ADT-Meldung zu speichern, ruft das ACRS (das separat von oder in Verbindung mit dem CKS angeboten werden kann) einen gemeinsamen Schlüssel von dem CKS an oder verweist auf ihn, um festzustellen und / oder um zu überprüfen, ob die ADT-Meldung ordnungsgemäß mit dem Patienten X verknüpft und ordnungsgemäß gespeichert ist.
• Der CKS verwendet dann demographische Informationen, die in Verbindung mit der ADT-Meldung empfangen wurden, um ein MPI nach der Identität des Patienten X zu durchsuchen. Das MPI kann von einer staatlichen Behörde unterhalten werden, wie oben beschrieben, oder es kann von einer anderen Einrichtung, wie beispielsweise der Einrichtung, die den CKS anbietet, gespeichert und verwaltet werden. Wenn im MPI eine Übereinstimmung für Patient X gefunden wird und Patient X bereits einem gemeinsamen Schlüssel zugeordnet ist, sendet das MPI den eindeutigen gemeinsamen Schlüssel des Patienten X an den CKS zurück. Auf diese Weise kann die ADT-Meldung ordnungsgemäß aufgezeichnet und mit der wahren Identität des Patienten X in den Dateien der aktiven Pflegedienstleistungsverhältnis verknüpft werden. Ebenso kann der gemeinsame Schlüssel auch von der DSO und dem ACRS verwendet werden, um andere Datensätze in Bezug auf Patient X zu bestimmen, was die ordnungsgemäße Versorgung von Patient X erleichtern kann, während Patient X im Krankenhaus behandelt wird.
• Wenn das MPI basierend auf den demographischen Informationen eine wahre Identität des Patienten X findet, Patient X aber noch nicht mit einem eindeutigen gemeinsamen Schlüssel verbunden ist, fordert das MPI von dem CKS einen gemeinsamen Schlüssel an. Ein gemeinsamer Schlüssel wird von dem CKS erzeugt und dieser gemeinsame Schlüssel wird dem Patienten X zugewiesen. Ähnlich wie oben beschrieben kann der gemeinsame Schlüssel dann den entsprechenden Datensätzen hinzugefügt werden. Wenn das MPI keine Identitätsübereinstimmung für Patient X oder einen gemeinsamen Schlüssel findet, kann das MPI einen neuen Personendatensatz erstellen und einen neuen eindeutigen gemeinsamen Schlüssel von dem CKS anfordern. Beispiele für Personen, die möglicherweise keinen Datensatz oder gemeinsamen Schlüssel haben, können ein Neugeborenes oder eine Person sein, die keine vorherige Zugehörigkeit zu der Stelle hat, die das MPI unterhält.
• In einem weiteren Beispiel kann der Patient X in ein Krankenhaus aufgenommen werden und die mit dem Krankenhaus verbundene DSO kann bereits einen gemeinsamen Schlüssel kennen, der mit dem Patienten X verbunden ist. Dementsprechend kann die DSO, wenn eine ADT-Meldung erzeugt wird, die ADT-Meldung zusammen mit dem bekannten gemeinsamen Schlüssel an das ACRS sowie den CKS senden. Dementsprechend können die Datensätze gespeichert und mit dem gemeinsamen Schlüssel verknüpft werden, und der CKS muss möglicherweise nicht nach dem gemeinsamen Schlüssel suchen und eine Identität im MPI abgleichen. In einer alternativen Ausführungsform kann der CKS jedoch immer noch den gemeinsamen Schlüssel und die Identität des Patienten X im MPI suchen, um zu überprüfen, ob alle Informationen aus der DSO korrekt sind.
• In einer weiteren Ausführungsform der vorliegenden Offenbarung kann der CKS verwendet werden, um Datensätze zu anonymisieren und diese sicherer und privater zu gestalten. Nachdem beispielsweise ein gemeinsamer Schlüssel für einen Patienten erstellt und den DSOs, Gesundheitsdienstleistern, einem MPI, dem CKS usw. bekannt ist, dürfen personenbezogene Identifikationsinformationen über den Patienten nicht mehr zwischen diesen verschiedenen Einheiten übertragen werden. So können beispielsweise die Datensätze eines Patienten nur unter Verwendung des gemeinsamen Schlüssels des Patienten aktualisiert werden, um festzustellen, welche Datensätze zu aktualisieren sind, und der Name des Patienten, das Geburtsdatum, die Sozialversicherungsnummer, die Adresse, andere demografische Daten usw. dürfen nicht zur Aktualisierung der Krankenakten des Patienten verwendet werden. Auf diese Weise kann die Übermittlung der Krankenakten des Patienten und der Krankenakten selbst unkenntlich gemacht werden.
• In einer weiteren Ausführungsform der vorliegenden Offenbarung kann ein anderes Anwendungsbeispiel in Verbindung mit einem CKS angewendet werden. In der Ausführungsform kann ein Forscher einen medizinischen Zustand untersuchen und Datensätze zur Durchführung einer Studie verwenden. Zum Beispiel kann der Forscher die Wirksamkeit der Depressionsbehandlung untersuchen, wenn ein Krebspatient eine Chemotherapie durchläuft. Verschiedene Behandlungen für einen Krebspatienten können von mehreren Gesundheitsdienstleistern für einen einzigen Patienten durchgeführt werden. Datensätze für die unterschiedlichen Behandlungen können auf mehreren verschiedenen Systemen erstellt und / oder gespeichert werden. Dementsprechend kann es schwierig sein, genaue Informationen über verschiedene Systeme hinweg für einen einzelnen Patienten zu finden. Zum Beispiel ist der Name John Smith sehr gebräuchlich, und wenn er Gegenstand der Studie ist, kann die Verknüpfung verschiedener Krankenakten mit verschiedenen Krankenaktennummern schwierig sein. Mit anderen Worten kann der Forscher Schwierigkeiten haben, genau herauszufinden, welcher John Smith welche Behandlungen erhalten hat, wann die Behandlungen durchgeführt wurden und wo die Behandlungen durchgeführt wurden, da zum Teil jedes System unterschiedliche Krankenblattnummern für die verschiedenen John Smiths, die existieren, verwenden kann. Dementsprechend kann der Forscher das Common Key System verwenden, um festzustellen, welcher der verschiedenen Datensätze zu einem John Smith im Zusammenhang mit dem John Smith steht, der Gegenstand der Studie ist. Auf diese Weise kann die Forschung einfacher und genauer durchgeführt werden. In einer Ausführungsform dürfen die Datensätze nicht mit einem gemeinsamen Schlüssel verknüpft werden, so dass der CKS jeden Datensatz mit einer wahren Identität abgleicht, die mit dem John Smith verbunden ist, der Gegenstand der Studie ist. In einer weiteren Ausführungsform kann der Forscher Datensätze finden, die bereits mit einem gemeinsamen Schlüssel verknüpft sind. In diesem Fall kann der Forscher den CKS nutzen, um den gemeinsamen Schlüssel des John Smith anzufordern, der Gegenstand der Studie ist. Sobald der gemeinsame Schlüssel für den richtigen John Smith bestimmt ist, können die Datensätze, die den gleichen gemeinsamen Schlüssel enthalten, leicht identifiziert werden, entweder durch den Forscher oder automatisch durch den CKS. Mit anderen Worten, diese Ausführungsform ermöglicht es Forschern, Informationen aus verschiedenen Systemen mit den entsprechenden Patienten über den CKSs zu verknüpfen.
• Die hierin offenbarten CKS-Systeme und -Verfahren überwinden Schwierigkeiten bei der Zuordnung von Patienten, um den Austausch von Gesundheitsinformationen zu erleichtern, obwohl medizinische Informationen in unterschiedlichen Systemen gespeichert sind. So kann beispielsweise ein Krankenhausregistrierungs- / Aufnahmesystem das Geschlecht als männlich, weiblich, unbekannt erfassen, während ein anderes Krankenhaus-System stattdessen M, F oder U auflisten kann. Darüber hinaus können Inkonsistenzen in der demographischen Datenlage der Patienten auch die genaue Zuordnung erschweren. So kann beispielsweise der Name eines Patienten in einem System als Jane Smith-Jones eingegeben werden, in einem anderen System als Jane Smith Jones (ohne den Bindestrich (-)) und ein drittes System könnte diesen Namen als Jane Jones aufgezeichnet haben. In einem System kann Janes Adresse ihre jüngste sein, während ein anderes System ihre Adresse noch als ihre vorherige Heimat angibt; eines kann ihr Geburtsdatum mit dem Jahr 1975 nennen, während die anderen ihr Geburtsjahr mit dem Jahr 1957 angeben. In einer Ausführungsform der vorliegenden Offenbarung kann das System, wenn ein Gesundheitsdienstleister oder DSO Datensätze für einen bestimmten Patienten anfordert (oder Datensätze, die einem bestimmten gemeinsamen Schlüssel zugeordnet sind), Datensätze entsprechend der Art und Weise formatieren, wie der Anforderer Patientendaten und - datensätzen speichert und übermittelt. Auf diese Weise kann ein Anforderer die angeforderten Informationen leichter interpretieren, anzeigen und speichern, entsprechend dem System des Anforderers.
• Um den Informationsaustausch zu vereinheitlichen, um einen sinnvollen Gebrauch und eine verantwortungsvolle Pflege zu unterstützen, verwenden elektronische Gesundheitssysteme einen zuverlässigen Abgleich durch Nutzung eines CKS, wie hierin offenbart, um festzustellen, dass die richtigen Informationen jedes Mal dem richtigen Patienten zugeordnet werden. Die hierin offenbarten CKSs bieten eine konsistente und zuverlässige Möglichkeit, Patienten über mehrere Organisationen, Anwendungen und Dienste hinweg abzugleichen. Solche zuverlässigen Abgleichfunktionen gewährleisten Patientensicherheit und hohe Datenintegrität beim Datenaustausch. Der CKS verknüpft Informationen für Einzelpersonen oder Unternehmen, indem es bewährte Verfahren zum Erfüllen von Kriterien anwendet, um sicherzustellen, dass Kennungen und Attribute mehrere Arten von Einheiten positiv und genau identifizieren. Beispiele für Attribute, die verwendet werden können, um Identitäten abzugleichen, sind demografische Informationen wie Name, Geburtsdatum, Geschlecht usw. In einer alternativen Ausführungsform können patienteneigene Informationen wie biometrische Informationen (Fingerabdruck, Handflächenscan, Augenscan, etc.) verwendet werden, um eine Identitätsübereinstimmung zu bestimmen. Zu den natürlichen Personen wie auch Einheiten, die ein CKS nutzen können, können Patienten, Leistungsempfänger, Ärzte und Arztorganisationen, Leistungsträger und Krankenkassen, Krankenhäuser und Gesundheitssysteme, Gesundheitseinrichtungen, öffentliche Gesundheitseinrichtungen usw. gehören. Die hierin offenbarten CKS können einen genauen Datenaustausch durch eine Vielzahl von Anwendungsfällen ermöglichen, wie z.B. Bereitstellung von Ergebnissen, Krankenhausbenachrichtigungen, Berichterstattung im Gesundheitswesen, Pflegekoordination und Patientensicherheit, Qualitäts- und Verwaltungsberichte, Patienteneinbindung, Infrastruktur (z.B. ACRS, landesweites Gesundheitsdienstleisterverzeichnis, Informationssicherheit / Identitätsmanagement), Standardkonsens, Qualitätssicherungssysteme, etc.
• Der hierin offenbarte CKS bietet Mittel, um Informationen für Einzelpersonen oder Organisationen genau zu verknüpfen, um verschiedene Anwendungsfälle zu unterstützen. So erhöht beispielsweise eine verbesserte Zuordnung der Patienten den Umfang der ausgehenden ADT-Nachrichten, welche Gesundheitsdienstleister und Kostenträger genau erreichen, was einem weit verbreiteten Gesundheitssystem hilft, effizienter zu arbeiten. Die hierin offenbarten Common-Key-Systeme und -Verfahren können auch das MPI eines Staates nutzen, welches belastbare Prozesse zur Verwaltung von Informationen über Personen und zum De-Duplizieren von Einträgen mit großer Genauigkeit nutzen kann.
• In einer Ausführungsform der vorliegenden Offenbarung erhält der CKS eine Anforderung für den gemeinsamen Schlüssel eines Patienten und leitet die Anforderung an das MPI eines jeweiligen Staates weiter. Eine solche Anforderung kann zu folgenden Aktionen führen: (1) Wenn der Patient im MPI gefunden wird, erstellt der CKS einen gemeinsamen Schlüssel für den Patienten und vergleicht ihn mit dem MPI des Staates, um eine genaue systemübergreifende Zuordnung sicherzustellen. (2) Wenn eine Person nicht im MPI des Staates gefunden wird, weist der CKS einen gemeinsamen Schlüssel zu und übergibt ihn an das MPI des Staates, das einen Datensatz für diesen Patienten im MPI erstellt oder ändert. (3) Wird im MPI des Staates eine mögliche Übereinstimmung oder ein mögliches Duplikat identifiziert, erhält der Anforderer eine Liste möglicher Übereinstimmungen und wird aufgefordert, die Datensätze im Detail zu überprüfen, um den richtigen Patienten zu identifizieren und/oder Fehler zu identifizieren, welche die Ursache für das Entstehen der Duplikate im MPI sind (z.B. falsch geschriebener Name, falsches Geburtsdatum). Der Anforderer sendet dann eine Nachricht an den CKS, die das MPI darüber informiert, welche der Duplikate die richtige Person ist. Wenn das MPI die Quelle für die doppelten Daten ist, kann ein MPI-Mitarbeiter die Daten überprüfen und Duplikate und Fehler korrigieren. Ein solcher Prozess kann dazu beitragen, dass die Personendaten auf dem neuesten Stand gehalten werden, die Integrität des CKS zu verbessern und sowohl das MPI als auch den CKS belastbarer zu machen. Ein Datensatz kann im MPI geändert oder erstellt werden, indem eine Nachricht von dem CKS gesendet wird, die eine Aktion und alle zugehörigen gemeinsamen Schlüssel enthält. So kann beispielsweise die Aktion in einer Nachricht eines oder mehreres von einem Zusammenführen, Aktualisieren oder Löschen sein. Gemeinsame Schlüssel zum Zusammenführen, Aktualisieren oder Löschen wären in der Nachricht enthalten und mit der entsprechenden Aktion in der Nachricht verknüpft.
• Zusätzlich kann der CKS ein ACRS verwenden, das von einem ACRM-System (z.B. ACRM-System 305) unterstützt wird. Ein ACRM-System oder ein ähnliches Datensatzmanagementsystem kann über eine API dem CKS ausgesetzt werden und dann über seine APIs dem MPI zugeordnet und mit diesem integriert werden. Dies kann zu einer einfachen technischen Umsetzung führen. So kann beispielsweise eine Medicaid-Population, die mit einem ACRS versorgt wird, einfach angewendet und mit einem CKS verwendet werden.
• 4 ist ein Flussdiagramm, das ein Verfahren 400 zum Erzeugen eines gemeinsamen Schlüssels für bekannte Personen gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 405 erhält ein CKS eine Anforderung für den gemeinsamen Schlüssel einer Person. In einer Operation 410 sendet der CKS eine Anforderung an ein MPI. In einer alternativen Ausführungsform kann das MPI stattdessen jede Datenbank sein, die Informationen über Personen speichert und Datensätze über einzelne Personen vervielfältigt. In einer Operation 415 wird die Person im MPI gefunden, aber die Person ist nicht mit einem gemeinsamen Schlüssel verknüpft. In einer Operation 420 erzeugt der CKS einen gemeinsamen Schlüssel. In einer Operation 425 sendet der CKS den gemeinsamen Schlüssel an das MPI, so dass der gemeinsame Schlüssel mit dem Datensatz der Person im MPI verknüpft werden kann. In einer alternativen Ausführungsform dürfen das MPI und der CKS keine getrennten Systeme sein. Mit anderen Worten, das Common-Key-System kann Personen ähnlich einem MPI speichern, die Personenübereinstimmungen im MPI gemäß den Anforderungen von Data-Sharing-Organisationsvorrichtungen oder Gesundheitsdienstleistern bestimmen und die gemeinsamen Schlüssel verwenden, um Datensätze über einzelne Personen zu de-duplizieren. Mit anderen Worten, das Common-Key-System und das MPI können dieselben oder mehrere Systeme sein, die die gleichen Funktionen wie hierin offenbart erzielen.
• 5 ist ein Flussdiagramm, das ein Verfahren 500 zum Erzeugen eines gemeinsamen Schlüssels für unbekannte Personen gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 505 erhält ein CKS eine Anforderung für den gemeinsamen Schlüssel einer Person. In einer Operation 510 sendet der CKS eine Anforderung an ein MPI. In einer Operation 515 wird die Person im MPI nicht gefunden. In einer Operation 520 erzeugt der CKS einen gemeinsamen Schlüssel für die Person als Reaktion auf einen Datensatz der Person, der nicht im MPI gefunden wird. In einer Operation 525 sendet der CKS die erzeugten gemeinsamen Schlüsselinformationen, die mit der Person verbunden sind, an das MPI. In einer Operation 530 erstellt das MPI für diese Person einen Datensatz, der die Identifizierung demographischer Informationen und des gemeinsamen Schlüssels beinhaltet.
• 6 ist ein Flussdiagramm, das ein Verfahren 600 zum Verwenden eines bekannten gemeinsamen Schlüssels für eine bekannte Person gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 605 erhält ein CKS eine Anforderung für den gemeinsamen Schlüssel einer Person. In einer Operation 610 sendet der CKS eine Anforderung an ein MPI. In einer Operation 615 sind die Person und ein zugehöriger gemeinsamer Schlüssel im MPI zu finden. In einer Operation 620 sendet der CKS den vom MPI empfangenen gemeinsamen Schlüssel an die Anforderungsvorrichtung. Zusätzlich kann der CKS in einer weiteren Ausführungsform auch einen Datensatz des Anforderers dem gemeinsamen Schlüssel zuordnen.
• 7 ist ein Flussdiagramm, das ein Verfahren 700 zum Erfassen von Datensätzen mit einem gemeinsamen Schlüssel gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 705 erhält der CKS eine Anforderung für die Datensätze einer Person. In einer Operation 710 verwendet der CKS einen gemeinsamen Schlüssel, um Datensätze zu finden, die sich auf die Person beziehen. In einer Ausführungsform können die gefundenen Datensätze im Common Key System gespeichert werden. In einer weiteren Ausführungsform können sich die Datensätze auf anderen Systemen befinden, wie beispielsweise einem DSO-System, einem ACRM-System, einem Provider-System, einem MPI oder anderen Orten, an denen Datensätze gespeichert werden können. Der gemeinsame Schlüssel, der zum Auffinden oder Identifizieren der Datensätze verwendet wird, kann auf verschiedene Weise bestimmt werden, wie beispielsweise durch die oben beschriebenen Verfahren in Bezug auf die 4 bis 6. In einer Operation 715 werden die gefundenen Datensätze basierend auf einer Formatpräferenz des Anforderers formatiert. Diese Formatierung kann die Art und Weise, wie bestimmte Informationen / Daten präsentiert werden, und die Art und Weise, wie Informationen / Daten präsentiert werden, beeinflussen. Mit anderen Worten, das System kann das Formular für die gelieferten Datensätze formatieren und bestimmen, welche Datensätze oder Teile von Datensätzen tatsächlich geliefert werden sollen. In einer Operation 720 werden die gefundenen und formatierten Datensätze an den Anforderer gesendet.
• 8 ist ein Flussdiagramm, das ein Verfahren 800 zum Überprüfen potenzieller Personenübereinstimmungen gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 805 erhält der CKS eine Anforderung bezüglich einer Person. In einer Operation 810 fragt der CKS ein MPI bezüglich der Person ab. In einer Operation 815 identifiziert das MPI potenzielle Übereinstimmungen (oder eine einzelne potenzielle Übereinstimmung) für die Person. In einer Operation 820 wird / werden die potenzielle(n) Übereinstimmung(en) an die Anforderungsvorrichtung gesendet. In einer Operation 825 sendet der Anforderer den Nachweis einer korrekten Übereinstimmung mit der ursprünglichen Anforderung an den CKS und / oder das MPI. Mit anderen Worten, der Anforderer bestätigt, welche der potenziellen Übereinstimmungen die richtige ist. In einer Operation 830 kann der Anforderer auch Korrekturinformationen senden, um Fehler zu korrigieren, die mehrere Übereinstimmungen verursachen. So können beispielsweise einige demografische Informationen einer Person falsch im MPI gespeichert sein, so dass das MPI diese Person fälschlicherweise als potenzielle Übereinstimmung anzeigt. Die Anforderung kann in Operation 830 den Fehler korrigieren, um zukünftige Fehler zu vermeiden und das MPI und der CKS genauer und hilfreicher zu machen. In einer alternativen Ausführungsform kann die Bestätigung einer korrekten Übereinstimmung und / oder Korrekturinformationen zu einem Datensatz von einer anderen Einheit oder Vorrichtung als dem Anforderer gesendet werden. So kann beispielsweise der CKS oder das MPI auch in der Lage sein, aus potenziellen Übereinstimmungen eine korrekte Übereinstimmung zu bestimmen und falsche Informationen in einem Datensatz zu korrigieren.
• 9 ist ein Flussdiagramm, das ein Verfahren 900 zum Aktualisieren von Dateien, welche ein CKS verwenden, gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 905 sendet ein Gesundheitsdienstleister Dateien über eine DSO-Vorrichtung (z.B. die Gesundheitsorganisation-Computer 310 oder Gesundheitsdienstleister-Computer 315) an einen CKS. In einer Operation 910 fragt der CKS ein MPI nach Personen ab, die mit Personen übereinstimmen, die in den von der DSO gesendeten Dateien vertreten sind. In einer Operation 915 gibt das MPI einen gemeinsamen Schlüssel für alle übereinstimmenden Personen in der MPI-Datenbank zurück, die den Personen in den von der DSO gesendeten Dateien entsprechen, In einer Operation 915 wurden den übereinstimmenden Personen bereits ein gemeinsamer Schlüssel zugeordnet. In einer Operation 920 fügt der CKS die gemeinsamen Schlüssel, die den übereinstimmenden Personen zugeordnet sind, zu den Dateien hinzu. In einer Operation 925 fordert das MPI gemeinsame Schlüssel für Personen an, die noch keinen gemeinsamen Schlüssel zugeordnet haben. In einer Operation 930 erzeugt der CKS gemeinsame Schlüssel für diese Personen und sendet die gemeinsamen Schlüssel an das MPI. In einer Operation 935 ordnet das MPI die erzeugten gemeinsamen Schlüssel der im MPI gefundenen Person zu, die bisher noch keinen gemeinsamen Schlüssel erhalten hat. In einer Operation 940 erstellt das MPI für jede der Personen aus den Dateien, die noch keine übereinstimmende Person im MPI oder einen zugehörigen gemeinsamen Schlüssel haben, einen neuen Personendatensatz. Das in 9 demonstrierte Verfahren kann zur Aufnahme und Verarbeitung großer Mengen von Dateien und Datensätze verwendet werden, die für viele verschiedene Personen gelten.
• 10 ist ein Flussdiagramm, das ein Verfahren 1000 zur Verwendung eines CKS in Verbindung mit einem Krankenhausbesuch eines Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 1005 wird ein Patient in ein Krankenhaus aufgenommen. In einer Operation 1010 wird durch eine DSO-Vorrichtung (z.B. ein Gesundheitsorganisation-Computer 310 oder ein Gesundheitsdienstleister-Computer 315) ein Aufnahmeprotokoll für den Patienten erzeugt. In einer Operation 1015 rufen das Aufnahmeprotokoll und die DSO-Vorrichtung ein CKS auf, um den gemeinsamen Schlüssel des Patienten von einem MPI anzufordern. In einer Operation 1020 ruft der CKS den gemeinsamen Schlüssel des Patienten aus dem MPI ab. In alternativen Ausführungsformen kann der gemeinsame Schlüssel des Patienten ähnlich wie die oben beschriebenen gemeinsamen Schlüssel in Bezug auf die 4 und 5 erzeugt werden. In einer Operation 1025 verknüpft der CKS den gemeinsamen Schlüssel, um den Patienten mit anderen Gesundheitsdienstleistern zu verbinden, die Datensätze zu diesem Patienten haben (und mit den Patientenakten, die im Besitz anderer Gesundheitsdienstleister sind). In einer Operation 1030 wird zur besseren Koordination der Patientenversorgung die Aufnahme um den gemeinsamen Schlüssel ergänzt. In einer weiteren Ausführungsform kann das Aufnahmeprotokoll auch mit anderen Informationen angereichert werden, wie beispielsweise den verknüpften anderen Gesundheitsdienstleistern und anderen Gesundheitsdienstleister-Datensätzen, die in Operation 1025 identifiziert wurden.
• 11 ist ein Flussdiagramm, das ein Verfahren 1100 zum Verwenden eines CKS gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. Das Verfahren 1100 zeigt Schritte, die von einem MPI 1155 ausgeführt werden können, und Schritte, die von einem CKS 1150 ausgeführt werden können. In einer Operation 1105 fordert ein Shared Service oder ein Anwendungsfall eine Patienten- und / oder Gesundheitsdienstleister-Suche von einem CKS 1150 an. In einer Operation 1110 fragt der CKS 1150 das MPI 1155 ab. In einer Operation 1115 bestimmt das MPI 1155, ob der Patient und / oder der Gesundheitsdienstleister einen gemeinsamen Schlüssel hat. Wenn der Patient und / oder der Gesundheitsdienstleister einen gemeinsamen Schlüssel hat, stellt das MPI 1155 dem CKS 1150 den gemeinsamen Schlüssel und alle anderen angeforderten Attribute (wie z.B. demografische Informationen oder andere Datensätze) zur Verfügung. In einer Operation 1125 stellt der CKS 1150 wiederum diese Informationen und den gemeinsamen Schlüssel für den Anforderer, den Shared Service, den Anwendungsfall usw. bereit. In einer Operation 1130 setzt der CKS 1150 dann den Anwendungsfall, Shared Service usw. fort. Mit anderen Worten, der Shared Service, der Anwendungsfall usw. verwendet die bereitgestellten Informationen und / oder den gemeinsamen Schlüssel für einen Zweck, für den die Informationen und / oder der gemeinsame Schlüssel angefordert wurden, wie z.B. das Erhalten oder Aktualisieren eines Datensatzes. In einer Operation 1135 weist der CKS 1150 einen gemeinsamen Schlüssel zu, da das MPI 1155 in der Operation 1115 keinen gemeinsamen Schlüssel gefunden hat. In einer Operation 1140 wird der generierte gemeinsame Schlüssel dem Anwendungsfall, Shared Service, Anforderer usw. zur Verfügung gestellt. In einer Operation 1145 wird der erzeugte gemeinsame Schlüssel dem MPI 1155 bereitgestellt, so dass das MPI 1155 mit dem erzeugten gemeinsamen Schlüssel aktualisiert werden kann. In der Operation 1145 wird der erzeugte gemeinsame Schlüssel im MPI 1155 dem Patienten und / oder Gesundheitsdienstleister zugeordnet, für den der gemeinsame Schlüssel erzeugt wurde, so dass der gemeinsame Schlüssel später diesem Patienten und / oder Gesundheitsdienstleister zugeordnet werden kann. In einer Operation 1130 setzt der CKS 1150 dann den Anwendungsfall, Shared Service usw. fort. Mit anderen Worten, der Shared Service, der Anwendungsfall usw. verwendet die bereitgestellten Informationen und / oder den gemeinsamen Schlüssel für einen Zweck, für den die Informationen und / oder der gemeinsame Schlüssel angefordert wurden, wie z.B. das Erhalten oder Aktualisieren eines Datensatzes.
• 12 ist ein Flussdiagramm, das den Aufnahmeprozess 1200 eines neuen Patienten bei einer Gesundheitsorganisation oder einem Gesundheitsdienstleister gemäß einer Ausführungsform der vorliegenden Offenbarung darstellt. In alternativen Ausführungsformen können weniger, zusätzliche und / oder unterschiedliche Operationen durchgeführt werden. Auch die Verwendung eines Flussdiagramms ist nicht als Einschränkung in Bezug auf die Reihenfolge der durchgeführten Operationen gedacht. In einer Operation 1205 präsentiert eine DSO-Vorrichtung (z.B. einen Gesundheitsorganisation-Computer 310 oder einen Gesundheitsdienstleister-Computer 315) auf ihrer Anzeige den neuen Patienten mit einer elektronischen Version einer ersten von einer oder mehreren Aufnahme- oder Einwilligungsformularen. In einer Operation 1210 fordert die DSO-Vorrichtung den Patienten auf, eine erste demografische Kennung einzugeben, die beispielsweise der Vorname des Patienten sein kann. Sobald der Patient die erste demografische Kennung in einer Operation 1215 eingibt, ruft die DSO-Vorrichtung ein CKS auf, um zu bestimmen, ob es eine eindeutige Übereinstimmung für den Patienten in einem MPI gibt. Wenn es keine Übereinstimmung gibt, bestimmt die DSO-Vorrichtung in einer Operation 1220, ob es eine zusätzliche demografische Kennung (z.B. Vorname, Nachname, Postleitzahl, Geburtsdatum, Geschlecht, die letzten vier Ziffern der Sozialversicherungsnummer, Telefonnummer, E-Mail-Adresse usw.) gibt, die der Patient eingeben kann. Wenn ja, fordert die DSO-Vorrichtung in einer Operation 1225 den Patienten auf, eine nachfolgende demografische Kennung einzugeben. Die DSO-Vorrichtung kann dann die Operationen 1215 bis 1225 wiederholen, bis entweder eine eindeutige Übereinstimmung im MPI für den Patienten bei der Operation 1215 gefunden wurde oder festgestellt wird, dass es keine zusätzliche demografische Kennung gibt, die der Patient bei der Operation 1220 eingeben kann.
• Wenn eine eindeutige Übereinstimmung bei der Operation 1215 gefunden wird, fordert die DSO-Vorrichtung von dem CKS bei einer Operation 1230 den gemeinsamen Schlüssel des Patienten und alle zusätzlichen Informationen, die das MPI über den Patienten hat, an. Das MPI speichert typischerweise alle demographischen Kennungen der Patienten. Wenn keine zusätzliche demografische Kennung eingegeben werden muss, ruft die DSO-Vorrichtung bei einer Operation 1235 einen Identitätsprüfdienst auf, um festzustellen, ob die Identität des Patienten überprüft werden kann. Ein Identitätsprüfdienst ist in der U.S. Patentanmeldung Nr. 14/642 , 092 und 14/949 , 395 beschrieben und kann wissensbasierte Authentifizierung und / oder optionale biometrische Identifizierung verwenden. Wenn entweder der gemeinsame Schlüssel des Patienten und die MPI-Informationen bei der Operation 1230 empfangen werden oder wenn die Identität des Patienten durch den Identitätsprüfdienst bei der Operation 1235 überprüft wird, füllt die DSO-Vorrichtung bei einer Operation 1240 so viele unbefüllte Felder wie möglich in elektronischer Form mit Informationen des MPI oder des Identitätsprüfdienstes vor.
• Bei einer Operation 1245 ruft die DSO-Vorrichtung ein ACRM-System (z.B. ACRM-System 305) auf, das verwendet wird, um ein ACRS bereitzustellen, um entweder unter Verwendung des gemeinsamen Schlüssels des Patienten aus der Operation 1230 oder der verifizierten Identität des Patienten aus der Operation 1235 zu bestimmen, ob es eine bekannte Beziehung zwischen dem Patienten und anderen Gesundheitsdienstleistern gibt, in der Informationen über den Patienten gespeichert werden können. Für jeden Gesundheitsdienstleister, mit dem der Patient in Beziehung steht, fragt die DSO-Vorrichtung bei einer Operation 1250 den Gesundheitsdienstleister nach Informationen über den Patienten. Die Operation 1250 kann das Abrufen einer elektronischen Adresse für den Gesundheitsdienstleister aus einem Gesundheitsdienstleister-Verzeichnisdienstprogramm und den Aufruf eines intelligenten Anfragevermittlers (wie in der U.S. Patentanmeldung Nr. 15/855,319 beschrieben, die hierin in ihrer Gesamtheit enthalten ist) beinhalten, um den Gesundheitsdienstleister unter seiner elektronischen Adresse nach Informationen über den Patienten zu fragen.
• Sobald zusätzliche Informationen über den Patienten von (einem) anderen Gesundheitsdienstleister(n) empfangen werden, füllt die DSO-Vorrichtung bei einer Operation 1255 so viele verbleibende unausgefüllte Felder wie möglich in elektronischer Form im Voraus aus. Bei einer Operation 1260 fordert die DSO-Vorrichtung den Patienten auf, alle verbleibenden Felder auszufüllen und / oder alle vorab ausgefüllten Felder zu korrigieren und das elektronische Formular elektronisch zu genehmigen und zu unterschreiben. Die Operation 1260 kann auch von der Operation 1235 aus erreicht werden, wenn die Identität des Patienten nicht durch den Identitätsprüfdienst überprüft werden kann.
• Bei einer Operation 1265 bestimmt die DSO-Vorrichtung, ob es eine zusätzliche elektronische Aufnahme- oder Einverständniserklärung für den Patienten zum Ausfüllen gibt. Wenn es ein zusätzliches elektronisches Formular gibt, schaltet die DSO-Vorrichtung zurück zur Operation 1255 und füllt so viele Felder wie möglich in dem neuen Formular im Voraus aus, wobei es Informationen verwendet, die aus dem MPI, der Identitätsprüfung des Patienten oder dem / den Gesundheitsdienstleister(n) gewonnen werden, mit dem / denen der Patient in Beziehung steht. Dann, bei der Operation 1260, fordert die DSO-Vorrichtung den Patienten auf, alle verbleibenden Felder auszufüllen. Wenn es für den Patienten bei der Operation 1265 kein zusätzliches Formular zum Ausfüllen gibt, wird der Patientenaufnahmeprozess 1200 bei einer Operation 1270 abgeschlossen. Der Patientenaufnahmeprozess 1200 ermöglicht es einem Patienten somit, einmalig Aufnahmeformulare zu erstellen und jede Information einmal einzugeben, was eine sichere Kommunikation und einen genauen Austausch der Patientendaten unabhängig vom geografischen Standort von Gesundheitsorganisationen oder Gesundheitsdienstleistern ermöglicht.
• 13 veranschaulicht ein Einwilligungsmanagementsystem 1300 gemäß einer Ausführungsform der vorliegenden Offenbarung. Das Einwilligungsmanagementsystem 1300 kann verwendet werden, um einen eConsent Management Service bereitzustellen, und beinhaltet ein Einwilligungsmanagementmodul 1332, ein Anfragemanagementmodul 1334, ein GUI-Modul 1336 und eine Datenbank 1338. Bei einigen Ausführungen kann das GUI-Modul 1336 des Einwilligungsmanagementsystems 1300 konfiguriert sein, um eine oder mehrere GUIs zu erzeugen und bereitzustellen, die es einem Patienten ermöglichen, die Einwilligung für den Austausch der Gesundheitsinformationen des Patienten zu erteilen. Eine solche GUI kann beispielsweise verwendet werden, um es dem Patienten zu ermöglichen, die vom Einwilligungsmanagementmodul 1332 verwendeten Einwilligungsinformationen bereitzustellen, um den Einwilligungsdatensatz für den Patienten zu erstellen oder zu ändern. In einigen Ausführungen kann das GUI-Modul 1336 Informationen für eine solche GUI erzeugen und kann die Informationen an einen Patienten-Computer (z.B. den Patienten-Computer 320 in 3) in einem Format übertragen, das es ermöglicht, die GUI über eine Anzeigevorrichtung oder ein anderes Ausgabegerät des Patienten-Computers wiederzugeben. Der Patient kann dann mit dem Patienten-Computer interagieren, z.B. über eine oder mehrere Eingabevorrichtungen, die in dem Patienten-Computer enthalten sind oder anderweitig zugänglich sind, um die Einwilligungsinformationen über die GUI bereitzustellen. Die Einwilligungsinformationen können dann vom Patienten-Computer an das Einwilligungsmanagementmodul 1332 übertragen werden, das die Einwilligungsinformationen verwenden kann, um den Einwilligungsdatensatz für den Patienten zu erstellen oder zu aktualisieren. Die 14 bis 17 zeigen exemplarische GUIs, die vom GUI-Modul 1336 generiert werden können.
• 14 veranschaulicht eine erste Beispiel GUI 1400, das einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann. So können beispielsweise Informationen, die der GUI 1400 entsprechen, durch das GUI-Modul 1336 erzeugt und an einen Patienten-Computer (z.B. den Patienten-Computer 320 in 3) übertragen werden, um den Patienten-Computer zu veranlassen, die GUI 1400 an einen Benutzer des Patienten-Computers zu übertragen. In einigen Ausführungen kann die GUI 1400 es dem Benutzer (z.B. einem Patienten) ermöglichen, Informationen bereitzustellen, entsprechend den aktiven Gesundheitsdienstleistungsverhältnissen, die der Patient zu einer beliebigen Anzahl von Gesundheitsdienstleistern oder anderen Gesundheitsorganisationen unterhält. Wie dargestellt, beinhaltet die GUI 1400 einen Text, der den Benutzer darüber informiert, dass der Benutzer die GUI verwenden kann, um Gesundheitsdienstleister hinzuzufügen oder zu bestätigen, die Teil des Pflegeteams des Benutzers sind, und um Gesundheitsdienstleister in Frage zu stellen, von denen der Benutzer glaubt, dass sie nicht Teil des Pflegeteams des Benutzers sein sollten. Die GUI 1400 beinhaltet eine Vielzahl von Feldern, wie beispielsweise das Feld 1405, von denen jedes den Namen eines Gesundheitsdienstleisters angibt, der Teil des Pflegeteams des Benutzers sein kann. In einigen Ausführungen können die Felder 1405 vorab ausgefüllt sein (z.B. ausgefüllt ohne Eingabe des Benutzers). So können beispielsweise die Felder 1405 so ausgefüllt werden, dass sie eine oder alle Gesundheitsorganisationen oder -dienstleister umfassen, die mit dem Benutzer verknüpft sind. Für jeden genannten Gesundheitsdienstleister beinhaltet die GUI 1400 ein entsprechendes Dropdown-Menü, wie beispielsweise das Dropdown-Menü 1410. Das Dropdown-Menü 1410 kann genutzt werden, um anzugeben, ob der Benutzer den jeweiligen Gesundheitsdienstleister als Teil des Pflegeteams des Benutzers bestätigen oder ablehnen möchte. Die GUI 1400 beinhaltet auch eine Schaltfläche 1415, die ausgewählt werden kann, um einen neuen Gesundheitsdienstleister hinzuzufügen, der derzeit nicht in der GUI 1405 aufgeführt ist. Wenn der Benutzer beispielsweise vor kurzem damit begonnen hat, einen neuen Gesundheitsdienstleister zu konsultieren, der noch nicht als Teil des Pflegeteams des Benutzers aufgeführt ist, kann der Benutzer mit der Schaltfläche 1415 den neuen Gesundheitsdienstleister zum Pflegeteam des Benutzers hinzufügen.
• In einigen Ausführungen kann der Benutzer mit dem Dropdown-Menü 1410 und der Schaltfläche 1415 über jede geeignete Schnittstellenvorrichtung interagieren, wie beispielsweise eine Maus, einen Trackball, einen Stift, ein Touchscreen, eine Tastatur oder jede andere Art von Eingabegerät, die es dem Benutzer ermöglichen kann, mit dem Dropdown-Menü 1410 oder der Schaltfläche 1415 zu interagieren. In einigen Ausführungen kann die GUI konfiguriert werden, um vom Benutzer über die Oberflächenelemente der GUI 1400 vorgenommene Eingabeauswahlen zu erfassen, einschließlich des Dropdown-Menüs 1410 und der Schaltfläche 1415, und um Informationen, die den Eingabeauswahlen des Benutzers entsprechen, an das Einwilligungsmanagementsystem 1300 oder das ACRM-System 305 zu übertragen. So können beispielsweise Informationen über Gesundheitsdienstleister, die der Benutzer bestätigt oder ablehnt, an das ACRM-System 305 übermittelt werden, um dem ACRM-System 305 zu ermöglichen, die Datenstruktur zu aktualisieren, um die bestätigte oder abgelehnte Beziehung zwischen dem Patienten und den ausgewählten Gesundheitsdienstleistern wie oben beschrieben anzuzeigen.
• 15 veranschaulicht eine zweite Beispiel GUI 1500, das einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann. In einigen Ausführungen kann die GUI 1500 es dem Benutzer ermöglichen, die Zustimmung zu Gesundheitsinformationen im Zusammenhang mit psychologischen und psychiatrischen Diensten sowie die Überweisung und Behandlung bei Alkohol- oder Drogenmissbrauchsstörungen an einen oder mehrere Gesundheitsdienstleister oder Gesundheitsorganisationen zu erteilen. Die GUI 1500 beinhaltet eine Vielzahl von Feldern 1535, die den Identifikationsinformationen für den Benutzer entsprechen. In einigen Ausführungen kann der Benutzer die Identifikationsinformationen des Benutzers eingeben, z.B. über eine Tastatur oder eine andere Benutzereingabevorrichtung, und die GUI 1500 kann konfiguriert sein, um die Informationen an das Einwilligungsmanagementsystem 1300 zu übertragen. In einigen Ausführungen kann mindestens ein Teil der Identifikationsinformationen des Benutzers in der GUI 1500 vorab ausgefüllt sein, bevor der Benutzer eine Eingabe macht. Die GUI 1500 beinhaltet auch eine Vielzahl von Feldern 1540, die jeweils einem jeweiligen Gesundheitsdienstleister oder einer jeweiligen Gesundheitsorganisation entsprechen, für die die Zustimmung gilt. In einigen Ausführungen kann der Benutzer eine Zeigevorrichtung oder eine andere Benutzereingabevorrichtung verwenden, um die in diesen Feldern 1540 angezeigten Gesundheitsdienstleister zu entfernen oder zu ändern. Der Benutzer kann auch die Schaltfläche 1548 wählen, um einen neuen Gesundheitsdienstleister oder eine neue Gesundheitsorganisation hinzuzufügen, die nicht bereits in der GUI 1500 angezeigt wird.
• Nachdem der Benutzer eine Auswahl über die GUI 1500 getroffen hat, kann dem Benutzer das dritte Beispiel GUI 1600, in 16 dargestellt, angezeigt werden. Die GUI 1600 beinhaltet eine Vielzahl von Benutzeroberflächenelementen 1655, welche Kontrollkästchen und Textfelder beinhalten können, die es einem Benutzer ermöglichen, eine Vielzahl von Arten von Informationen auszuwählen, für die die Zustimmung des Benutzers gilt. Die GUI 1600 beinhaltet auch einen Text, der den Benutzer über die Folgen der Einwilligung informiert, sowie Signaturfelder 1665 und ein optionales Ablaufdatumsfeld 1660. Die GUI 1600 beinhaltet auch eine Vielzahl von Beziehungsfeldern 1670, in denen der Benutzer aufgefordert wird, die Beziehung des Benutzers zu dem Patienten zu bestätigen, für den die Zustimmung erteilt wird. In einigen Ausführungen können, nachdem der Benutzer eine Auswahl über die GUIs 1500 und 1600 getroffen hat, Informationen, die der Auswahl entsprechen, an das Einwilligungsmanagementsystem 1300 übertragen werden. In einigen Ausführungen kann das Einwilligungsmanagementsystem 1300 die Informationen verwenden, um einen Einwilligungsdatensatz für den Benutzer zu erzeugen oder zu ändern, der in der Datenbank 1338 gespeichert werden kann.
• 17 veranschaulicht eine vierte Beispiel GUI 1700, das einem Patienten gemäß einer Ausführungsform der vorliegenden Offenbarung zur Verfügung gestellt werden kann. In einigen Ausführungen kann die GUI 1700 einem Benutzer über einen Patienten-Computer (z.B. den Patienten-Computer 320 in 3) zur Verfügung gestellt werden, um dem Benutzer zu ermöglichen, die Einwilligung zu widerrufen, dass die Gesundheitsinformationen des Benutzers an einen Gesundheitsdienstleister oder eine Gesundheitsorganisation weitergegeben werden, dem der Benutzer zuvor seine Einwilligung erteilt hat. Die GUI 1700 verfügt über ein Kontrollkästchen 1785, das dem Benutzer ermöglicht, die jeweiligen Gesundheitsdienstleister oder Gesundheitsorganisationen anzugeben, für die der Benutzer die Zustimmung zur Datenweitergabe widerrufen möchte. So kann der Benutzer beispielsweise nach dem Aktivieren des Kontrollkästchens 1785 über die Schaltfläche 1786 die Gesundheitsdienstleister oder Gesundheitsorganisationen hinzufügen, für die der Benutzer die Zustimmung zur Datenweitergabe widerrufen möchte. Alternativ kann der Benutzer das Kontrollkästchen 1788 aktivieren, um die Zustimmung aller Gesundheitsdienstleister und Gesundheitsorganisationen zur Weitergabe der Gesundheitsinformationen des Benutzers zu widerrufen, ohne die Gesundheitsdienstleister oder Gesundheitsorganisationen auflisten zu müssen, für die die Zustimmung widerrufen werden soll. Die GUI 1700 bietet auch Signaturfelder 1790, Beziehungs-Kontrollkästchen 1792 für den Benutzer, um die Beziehung des Benutzers zu dem Patienten anzuzeigen, für den die Zustimmung widerrufen wird. Wurde die Einwilligung mündlich widerrufen, z.B. während eines vom Patienten durchgeführten medizinischen Eingriffs, kann der Patient diesen Widerruf durch den mündlichen Widerruf der Einwilligungsfelder 1794 bestätigen, die eine Unterschrift und ein Datum erfordern.
• Die GUI 1700 beinhaltet auch eine Speichertaste 1796, mit der der Benutzer einen Datensatz der über die GUI 1700 eingegebenen Informationen speichern kann. In einigen Ausführungen kann das Auswählen der Speichertaste 1796 dazu führen, dass die Informationen lokal auf dem Patienten-Computer gespeichert werden. In einigen Ausführungen kann das Auswählen der Speichertaste 1796 dazu führen, dass die Informationen an das Einwilligungsmanagementsystem 1300 übertragen werden, damit die Einwilligungsaufzeichnung für den Patienten entsprechend aktualisiert werden kann. Die GUI 1700 beinhaltet auch eine PDF-Schaltfläche 1798, die der Benutzer auswählen kann, um eine Kopie der in die GUI 1700 eingegebenen Informationen im Portable Document Format (PDF) - Format anzuzeigen.
• Die in den 14 bis 17 dargestellten GUIs 1400, 1500, 1600 und 1700 können auf einem Patienten-Computer (z.B. dem Patienten-Computer 320 in 3) in jedem geeigneten Format angezeigt werden. In einigen Ausführungen können beispielsweise die GUIs 1400, 1500, 1600 und 1700 als Teil einer mobilen Anwendung angezeigt werden, die auf dem Patienten-Computer ausgeführt wird. In einigen Ausführungen können die GUIs 1400, 1500, 1600 und 1700 innerhalb einer Webbrowser-Anwendung gerendert werden, die auf dem Patienten-Computer ausgeführt wird. So kann beispielsweise der Benutzer des Patienten-Computers bewirken, dass der Patienten-Computer die GUIs 1400, 1500, 1600 und 1700 innerhalb der Webbrowser-Anwendung wiedergibt, indem er auf einen Uniform Ressource Locator (URL) einer Website zugreift, die vom Einwilligungsmanagementsystem 1300 gehostet wird, was wiederum dazu führen kann, dass das GUI-Modul 1336 Informationen entsprechend den GUIs 1400, 1500, 1600 und 1700 erzeugt und an die Patienten-Computervorrichtung übermittelt.
• In einigen Ausführungen kann das Einwilligungsmanagementsystem 1330 die GUIs 1400, 1500, 1600 und 1700 für den Patienten-Computer bereitstellen, als Reaktion auf das Bestimmen, dass einem Gesundheitsdienstleister oder einer Gesundheitsorganisation die Erlaubnis zum Teilen oder Zugriff auf die Gesundheitsinformationen des Patienten verweigert wurde. So kann beispielsweise das Einwilligungsmanagementsystem 1330 eine Anfrage von einem Gesundheitsorganisation-Computer (z.B. dem Gesundheitsorganisation-Computer 310 in 3) oder einem Gesundheitsdienstleister-Computer (z.B. dem Gesundheitsdienstleister-Computer 315 in 3) empfangen und bestimmen, dass der Patient der Gesundheitsorganisation oder dem mit der Anfrage verbundenen Gesundheitsdienstleister keine Einwilligung erteilt hat, die Gesundheitsinformationen des Patienten weiterzugeben oder darauf zuzugreifen. Als Reaktion darauf kann das GUI-Modul 1336 Informationen entsprechend den GUIs 1400, 1500, 1600 und 1700 erzeugen und an den dem Patienten zugeordneten Patienten-Computer übertragen, um es dem Patienten zu ermöglichen, die Einwilligung zu aktualisieren, um die mit der Anfrage verbundene Gesundheitsorganisation oder den Gesundheitsdienstleister einzubeziehen, wenn der Benutzer dies wünscht.
• 18 veranschaulicht ein Flussdiagramm eines ersten exemplarischen Verfahrens 1800 zum Handhaben des Datenschutzes gemäß einer Ausführungsform der vorliegenden Offenbarung. In einigen Ausführungen kann das Verfahren 1800 durch das in 13 dargestellte Einwilligungsmanagementsystem 1300 durchgeführt werden. Das Verfahren 1800 beinhaltet das Empfangen von Einwilligungsinformationen (Operation 1805), das Abgleichen der empfangenen Einwilligungsinformationen mit gespeicherten Einwilligungsinformationen (Operation 1810), das Aktualisieren eines Einwilligungsprotokolls basierend auf den abgeglichenen Einwilligungsinformationen (Operation 1815), das Empfangen einer Anfrage, um zu bestimmen, ob eine Datenaustauschorganisation die Erlaubnis hat, Gesundheitsinformationen für einen Patienten zu teilen (Operation 1820), das Erzeugen einer Antwort auf die Anfrage (Operation 1825) und das Übertragen der Antwort an die Datenaustauschorganisation (Operation 1830).
• Unter erneuter Bezugnahme auf 18 beinhaltet das Verfahren 1800 das Empfangen von Einwilligungsinformationen (Operation 1805). In einigen Ausführungen können die Einwilligungsinformationen von einem Patienten-Computer, wie beispielsweise den Patienten-Computern 320 aus 3, empfangen werden. So können beispielsweise die Einwilligungsinformationen basierend auf Benutzereingaben über eine GUI gesammelt werden, die auf dem Patienten-Computer angezeigt wird. Die Einwilligungsinformationen können eine erste Patientenkennung beinhalten, die den Patienten, für den die Einwilligungsinformationen bereitgestellt werden, eindeutig identifizieren kann. So können beispielsweise die Einwilligungsinformationen den Namen des Patienten, die Sozialversicherungsnummer, eine andere Identifikationsnummer oder eine beliebige Kombination aus diesen oder anderen Arten von Identifizierungsinformationen beinhalten. In einigen Ausführungen können die Einwilligungsinformationen auch einen Hinweis darauf enthalten, dass der Patient dem Austausch von Gesundheitsinformationen mit mindestens einer Gesundheitsorganisation zustimmt. Beispielsweise können die Einwilligungsinformationen auch eine Kennung der Gesundheitsorganisation beinhalten, die eine Gesundheitsorganisation eindeutig identifiziert, für die der Patient die Einwilligung erteilt. In einigen Ausführungen können die Einwilligungsinformationen auch eine Gesundheitsdienstleisterkennung für einen Gesundheitsdienstleister, wie beispielsweise einen Arzt, beinhalten, für den der Patient die Zustimmung erteilt.
• Das Verfahren 1800 beinhaltet das Abgleichen der empfangenen Einwilligungsinformationen mit gespeicherten Einwilligungsinformationen (Operation 1810). In einigen Ausführungen kann das Einwilligungsmanagementmodul 132 den Abgleich basierend auf den erhaltenen Einwilligungsinformationen und einem oder mehreren in einer Datenbank gespeicherten Einwilligungssätzen durchführen. In einigen Ausführungen kann der Einwilligungssatz jede Art oder Form von Datenstruktur sein, einschließlich eines Datenfraktals. So kann beispielsweise der Einwilligungssatz mindestens ein Teil eines in einem Ledger gespeicherten Eintrags sein. In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 eine Reihe von Richtlinien speichern, die den üblichen Datenformatierungs-Inkonsistenzen entsprechen, sowie Richtlinien zur Behebung oder Korrektur der Inkonsistenzen. So können die Richtlinien beispielsweise eine oder mehrere Regeln oder Schritte beinhalten, die durchzuführen sind, um Daten, die in den empfangenen Einwilligungsinformationen enthalten sind, in ein Format zu konvertieren, das mit der Formatierung der gespeicherten Einwilligungsinformationen übereinstimmt. In einigen Ausführungen kann der Abgleich der empfangenen Einwilligungsinformationen mit den gespeicherten Einwilligungsinformationen das Identifizieren redundanter Daten (z.B. dieselben Daten, die sowohl in den empfangenen Einwilligungsinformationen als auch in den gespeicherten Einwilligungsinformationen enthalten sind) und das Verwerfen der redundanten Daten beinhalten. In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 einen gemeinsamen Schlüsseldienst (wie oben beschrieben) verwenden, um mindestens einen Teil der Abstimmung durchzuführen.
• Das Verfahren 1800 beinhaltet das Aktualisieren des Einwilligungsprotokolls basierend auf den Einwilligungsinformationen (Operation 1815). In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 den Einwilligungsdatensatz basierend auf den in Operation 1805 erhaltenen Einwilligungsinformationen aktualisieren. In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 einen neuen Einwilligungssatz generieren, der den erhaltenen Einwilligungsinformationen entspricht. So kann beispielsweise das Einwilligungsmanagementmodul 1332 den Einwilligungssatz in Form einer beliebigen Datenstruktur erzeugen, die zum Speichern der Einwilligungsinformationen konfiguriert ist. In einigen Ausführungen kann der Einwilligungssatz als Extensible Markup Language (XML) - Dokument formatiert werden. Der Einwilligungsdatensatz kann dem jeweiligen Patienten, der die Einwilligungsinformationen zur Verfügung gestellt hat, zugeordnet oder anderweitig assoziiert werden. In einigen Ausführungen, wenn für den Patienten bereits ein Einwilligungsdatensatz vorhanden ist, kann das Einwilligungsmanagementmodul 1332 stattdessen den bestehenden Einwilligungsdatensatz basierend auf den in Operation 1805 erhaltenen Einwilligungsinformationen ändern, anstatt einen neuen Einwilligungsdatensatz zu erstellen. Das Einwilligungsmanagementmodul 1332 kann den Einwilligungsdatensatz z.B. in der Datenbank 1338 speichern.
• Das Verfahren 1800 beinhaltet das Empfangen einer Anfrage, um zu bestimmen, ob eine datenteilende Organisation die Berechtigung hat, Gesundheitsinformationen für einen Patienten auszutauschen (Operation 1820). Die Anfrage kann beispielsweise vom Anfragemanagementmodul 1334 von einem Gesundheitsorganisation-Computer 310 oder einem Gesundheitsdienstleister-Computer 315 empfangen werden. Die Anfrage kann eine zweite Patientenkennung beinhalten, die dem Patienten entspricht, für den die Zustimmung zur Weitergabe von Gesundheitsinformationen eingeholt wird. Darüber hinaus kann die Anfrage eine Kennung einer Gesundheitsorganisation oder eines Gesundheitsdienstleisters beinhalten, mit dem die Gesundheitsorganisation, die die Anfrage einleitet, die Gesundheitsinformationen des Patienten teilen möchte. So kann beispielsweise die Gesundheitsorganisation, die die Anforderung einleitet, die Gesundheitsinformationen des Patienten an eine andere Gesundheitsorganisation des Gesundheitsdienstleisters weitergeben, aber es kann erforderlich sein, die Zustimmung des Patienten einzuholen, bevor sie die Gesundheitsinformationen weitergibt.
• Das Verfahren 1800 beinhaltet das Erzeugen einer Antwort auf die Anfrage (Operation 1825). In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 zunächst bestimmen, ob die datenteilende Organisation die Berechtigung hat, die Gesundheitsinformationen des Patienten basierend auf der Anfrage und dem gespeicherten Einwilligungsdatensatz des Patienten zu teilen. So kann beispielsweise das Einwilligungsmanagementmodul 1332 die Bestimmung vornehmen, indem es eine Übereinstimmung zwischen der zweiten in der Anfrage enthaltenen Patientenkennung und der ersten Patientenkennung, die mit den in Operation 1805 empfangenen Einwilligungsinformationen verknüpft ist, identifiziert. Diese Übereinstimmung kann es dem Einwilligungsmanagementmodul 1332 ermöglichen, den Einwilligungssatz für den entsprechenden Patienten zu finden. Das Einwilligungsmanagementmodul 1332 kann auch eine Übereinstimmung zwischen der ersten Kennung einer Gesundheitsorganisation oder einer anderen Einheit, für die der Patient die Einwilligung zur Datenfreigabe erteilt hat, wie sie im Einwilligungsprotokoll des Patienten festgehalten ist, und der Kennung der Datenteilenden Organisation, die die Anforderung eingeleitet hat, identifizieren. In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 auch bestimmen, ob die Einwilligung des Patienten noch gültig ist (d.h., dass die Einwilligung vom Patienten nicht widerrufen wurde oder zum Zeitpunkt des Eingangs der Anforderung abgelaufen ist). In einigen Ausführungen kann das Einwilligungsmanagementmodul 1332 auch bestimmen, ob die Einwilligung des Patienten für die in der Anfrage angegebene Kategorie oder Art von Informationen gilt.
• Wenn das Einwilligungsmanagementmodul 1332 bestimmt, dass eine gültige Einwilligung für die datenteilende Organisation vorliegt, kann das Anfragemanagementmodul 1334 eine Antwort auf die Anfrage erzeugen, die angibt, dass die datenteilende Organisation berechtigt ist, die Gesundheitsinformationen des Patienten gemeinsam zu nutzen. Andernfalls, wenn das Einwilligungsmanagementmodul 1332 feststellt, dass für die datenteilende Organisation keine gültige Einwilligung vorliegt, kann das Anfragemanagementmodul 1334 eine Antwort auf die Anfrage erzeugen, die besagt, dass die datenteilende Organisation nicht berechtigt ist, die Gesundheitsinformationen des Patienten weiterzugeben. Das Verfahren 1800 beinhaltet auch das Übertragen der Antwort an die datenteilende Organisation (Operation 1830).
• An dieser Stelle sei darauf hingewiesen, dass das Bestimmen des Deckungsgrades und der Prämie einer Haftpflichtversicherung, die einem Gesundheitsdienstleister wie vorstehend beschrieben zur Verfügung zu stellen ist, in gewissem Umfang das Verarbeiten von Eingangsdaten und das Erzeugen von Ausgangsdaten beinhalten kann. Diese Eingangsdatenverarbeitung und Ausgangsdatenerzeugung können in Hardware oder Software implementiert werden. So können beispielsweise spezifische elektronische Komponenten in einem Computerserver oder ähnlichen oder verwandten Schaltungen verwendet werden, um die Funktionen zu implementieren, die mit der Aufnahme eines Patienten bei einem Gesundheitsdienstleister gemäß der vorliegenden Offenbarung wie vorstehend beschrieben verbunden sind. Alternativ können ein oder mehrere in Übereinstimmung mit den Anweisungen arbeitende Prozessoren die Funktionen ausführen, die mit dem Bestimmen des Deckungsgrades und der Prämie einer Haftpflichtversicherung verbunden sind, die einem Gesundheitsdienstleister gemäß der vorliegenden Offenbarung, wie vorstehend beschrieben, zur Verfügung zu stellen ist. Wenn dies der Fall ist, liegt es im Anwendungsbereich der vorliegenden Offenbarung, dass diese Anweisungen auf einem oder mehreren nichtflüchtigen, prozessorlesbaren Speichermedien (z.B. einer Magnetplatte oder einem anderen Speichermedium) gespeichert sind, oder über ein oder mehrere Signale, die in einer oder mehreren Trägerwellen enthalten sind, an einen oder mehrere Prozessoren übertragen werden.
• Die vorliegende Offenbarung soll nicht durch die hierin beschriebenen spezifischen Ausführungsformen im Anwendungsbereich eingeschränkt werden. Tatsächlich werden weitere verschiedene Ausführungsformen und Modifikationen der vorliegenden Offenbarung, zusätzlich zu den hierin beschriebenen, für diejenigen, die im Fachgebiet erfahren sind, aus der vorstehenden Beschreibung und den zugehörigen Figuren ersichtlich sein. Daher sollen solche anderen Ausführungsformen und Modifikationen in den Anwendungsbereich der vorliegenden Offenbarung fallen. Ferner, obwohl die vorliegende Offenbarung hierin im Rahmen mindestens einer bestimmten Implementierung in mindestens einer bestimmten Umgebung für mindestens einen bestimmten Zweck beschrieben wurde, werden diejenigen, die im Fachgebiet erfahren sind, erkennen, dass ihr Nutzen nicht darauf beschränkt ist und dass die vorliegende Offenbarung in einer beliebigen Anzahl von Umgebungen für eine beliebige Anzahl von Zwecken vorteilhaft umgesetzt werden kann. Dementsprechend sind die nachstehend dargelegten Ansprüche im Hinblick auf die volle Breite und den Geist der vorliegenden Offenbarung, wie hierin beschrieben, auszulegen.
• 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 62672858 [0001]
• US 14643910 [0002]
• US 15847506 [0002, 0036]
• US 15961605 [0002]
• US 15977690 [0002]
• US 5155802 [0032]
• US 5804373 [0032]
• US 14642 [0066]
• US 092 [0066]
• US 14949 [0066]
• US 395 [0066]
• US 15855319 [0067]

Claims (18)

1. Verfahren zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen gemäß einer Reihe von Anweisungen, die auf einem Speicher einer Computervorrichtung gespeichert und von einem Prozessor der Computervorrichtung ausgeführt werden, wobei das Verfahren die folgenden Schritte umfasst: Bestimmen einer Anzahl von elektronischen sicherheitsbezogenen Diensten, die von einem Gesundheitsdienstleister eingesetzt werden, der Patienteninformationen elektronisch übermittelt; Berechnen eines Deckungsgrades einer Haftpflichtversicherung, die dem Gesundheitsdienstleister bereitzustellen ist, basierend auf der Anzahl der Leistungen; und Berechnen von Prämienkosten der Haftpflichtversicherung basierend auf der Anzahl der Leistungen.
2. Verfahren nach Anspruch 1, wobei die Dienste einen oder mehrere von einem aktiven Pflegedienstleistungsverhältnis, einem gemeinsamen Schlüsseldienst und einem elektronischen Einwilligungsdienst einschließen.
3. Verfahren nach Anspruch 1, wobei die Dienste von einem Gesundheitsinformationsdienstleister bereitgestellt werden.
4. Verfahren nach Anspruch 1, wobei Dienste sicherstellen, dass die vom Gesundheitsdienstleister übermittelten Patienteninformationen mit den Datenstandards und Sicherheitsmaßnahmen übereinstimmen.
5. Verfahren nach Anspruch 1, wobei die berechneten Prämienkosten niedriger sind, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
6. Verfahren nach Anspruch 1, wobei die berechneten Prämienkosten höher sind, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
7. Verfahren nach Anspruch 1, wobei der berechnete Deckungsgrad höher ist, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
8. Verfahren nach Anspruch 1, wobei der berechnete Deckungsgrad niedriger ist, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
9. Mindestens ein prozessorlesbares Speichermedium, das ein Computerprogramm mit Anweisungen speichert, die konfiguriert sind, um von mindestens einem Prozessor lesbar zu sein, um den mindestens einen Prozessor anzuweisen, einen Computerprozess zum Durchführen des in Anspruch 1 genannten Verfahrens auszuführen.
10. System zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen, wobei das System Folgendes umfasst: einen oder mehrere Prozessoren, die kommunikativ mit einem Netzwerk gekoppelt sind, wobei der eine oder die mehreren Prozessoren konfiguriert sind zum: Bestimmen einer Reihe von elektronischen sicherheitsbezogenen Diensten, die von einem Gesundheitsdienstleister eingesetzt werden, der Patienteninformationen elektronisch übermittelt; Berechnen eines Deckungsgrades einer Haftpflichtversicherung, die dem Gesundheitsdienstleister, basierend auf der Anzahl der Leistungen, zu gewähren ist; und Berechnen von Prämienkosten der Haftpflichtversicherung auf der Grundlage der Anzahl von Leistungen.
11. System nach Anspruch 10, wobei die Leistungen einen oder mehrere von einem aktiven Pflegedienstleistungsverhältnis, einem gemeinsamen Schlüsseldienst und einem elektronischen Einwilligungsdienst einschließen.
12. System nach Anspruch 10, wobei die Leistungen von einem Gesundheitsinformationsdienstleister bereitgestellt werden.
13. System nach Anspruch 10, wobei die Dienste sicherstellen, dass die vom Gesundheitsdienstleister übermittelten Patienteninformationen mit den Datenstandards und Sicherheitsmaßnahmen übereinstimmen.
14. System nach Anspruchs 10, wobei die berechneten Prämienkosten niedriger sind, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
15. System des Anspruchs 10, wobei die berechneten Prämienkosten höher sind, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
16. System nach Anspruch 10, wobei der berechnete Deckungsgrad höher ist, wenn der Gesundheitsdienstleister mehr Leistungen in Anspruch nimmt.
17. System nach Anspruch 10, wobei der berechnete Deckungsgrad niedriger ist, wenn der Gesundheitsdienstleister weniger Leistungen in Anspruch nimmt.
18. Herstellungsgegenstand zum Begrenzen von Risiken bei der elektronischen Übermittlung von Patienteninformationen, wobei der Herstellungsgegenstand Folgendes umfasst: mindestens ein prozessorlesbares Speichermedium; und Anweisungen, die auf dem mindestens einen Medium gespeichert sind; wobei die Anweisungen konfiguriert sind, um von dem mindestens einen Medium durch mindestens einen Prozessor gelesen werden zu können und um dadurch herbeizuführen, dass der mindestens eine Prozessor so arbeitet, dass er Folgendes bewirkt: Bestimmen einer Reihe von elektronischen sicherheitsbezogenen Diensten, die von einem Gesundheitsdienstleister, der Patienteninformationen elektronisch übermittelt, eingesetzt werden; Berechnen eines Deckungsgrades einer Haftpflichtversicherung, die dem Gesundheitsdienstleister, basierend auf der Anzahl von Leistungen, zu gewähren ist; und Berechnen von Prämienkosten der Haftpflichtversicherung auf der Grundlage der Anzahl von Leistungen.

Images