DE102020110132A1 - Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit - Google Patents

Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit Download PDF

Info

Publication number
DE102020110132A1
DE102020110132A1 DE102020110132.5A DE102020110132A DE102020110132A1 DE 102020110132 A1 DE102020110132 A1 DE 102020110132A1 DE 102020110132 A DE102020110132 A DE 102020110132A DE 102020110132 A1 DE102020110132 A1 DE 102020110132A1
Authority
DE
Germany
Prior art keywords
token
local
tokens
predetermined
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020110132.5A
Other languages
English (en)
Inventor
Richard Houben
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
2bmedical BV
Original Assignee
2bmedical BV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 2bmedical BV filed Critical 2bmedical BV
Priority to DE102020110132.5A priority Critical patent/DE102020110132A1/de
Publication of DE102020110132A1 publication Critical patent/DE102020110132A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/80—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for detecting, monitoring or modelling epidemics or pandemics, e.g. flu
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0492—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload by using a location-limited connection, e.g. near-field communication or limited proximity of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Abstract

Die Erfindung betrifft ein Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe menschlicher Mitglieder, wobei jedes Mitglied der Gruppe eine mobile Vorrichtung mitführt. Es wird vorgeschlagen, dass eine Token-Logikeinheit dazu konzipiert ist, einen lokalen Token-Code zu erzeugen, und wobei, wenn sich zwei Token einander unterhalb eines vorbestimmten Schwellenabstands nähern, die lokalen Token-Codes in einer Näherungsroutine zwischen den Token-Steuerungen ausgetauscht werden.

Description

  • Die Erfindung betrifft: ein Verfahren zum Überwachen einer potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe menschlicher Gruppenmitglieder, ein Token, das von den Mitglieder der Gruppe mitgeführt wird, zum Durchführen des obenstehenden Verfahrens nach Anspruch 15, ein System, das eine Anzahl der obenstehenden Token und einen Server umfasst, zum Durchführen des obenstehenden Verfahrens nach Anspruch 16 und ein Computerprogrammprodukt zum Durchführen des obenstehenden Verfahrens nach Anspruch 17.
  • Infektionskrankheiten gehen auf pathogene Mikroorganismen wie etwa Bakterien, Viren, Parasiten oder Pilze zurück. In Abhängigkeit von ihrer Art können diese Krankheiten ausgebreitet werden, was ein Infektionsrisiko für eine große Anzahl von Menschen bedeuten kann. Neben medizinischer Behandlung und Immunisierung ist die Kontrolle von potenziellen Kontakten zwischen gefährdeten Menschen ein leistungsfähiges Mittel gegen die Ausbreitung einer solchen Infektionskrankheit. Ein neues Verfahren für eine solche Kontrolle ist der Schwerpunkt der vorliegenden Erfindung. Derzeitig stehen keine Hilfsmittel zur Verfügung, um eine effektive Kontrolle mit tolerierbaren Kosten und vertretbarem Aufwand bereitzustellen.
  • Das der Erfindung zugrundeliegende Problem liegt darin, ein effektives Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe menschlicher Gruppenmitglieder mit geringem Aufwand und geringen Kosten bereitzustellen.
  • Die Erfindung basiert auf der allgemeinen Idee, einer Gruppe menschlicher Mitglieder mobile Vorrichtungen bereitzustellen, die im Folgenden „Token“ genannt werden. Falls sich zwei Token gemäß einem vorbestimmten Näherungskriterium einander nahekommen, tauschen diese Token lokale Token-Codes miteinander aus, wobei die lokalen Token-Codes für das jeweilige Token spezifisch sind. Diese lokalen Token-Codes alleine enthalten jedoch keine Informationen, die es ermöglichen würden, den Eigentümer des jeweiligen Tokens zurückzuverfolgen. Die Datensicherheit ist daher größtenteils gewährleistet.
  • Falls eines der Mitglieder der Gruppe infiziert zu sein scheint, ist es allgemein möglich, aus dem jeweiligen Token die Liste lokaler Token-Codes auszulesen, die durch das Token des infizierten Mitglieds empfangen wurden. Diese Auslesung soll durch eine vertrauenswürdige Entität durchgeführt werden, insbesondere durch einen Arzt.
  • Ein Hauptelement der Erfindung besteht nun darin, dass jedes Token bei einem vertrauenswürdigen Server zu registrieren ist, wobei die Registrierung das Speichern der Konkordanzinformationen zwischen dem jeweiligen Mitglied und dem dem Mitglied zugewiesenen Token beinhaltet. Basierend auf diesen Konkordanzinformationen ist es der vertrauenswürdigen Entität, bei der es sich hier und vorzugsweise um den Arzt handelt, möglich, Mitglieder der Gruppe anzusprechen, die wahrscheinlich auch ein hohes Risiko der Infizierung aufweisen. Basierend auf diesen Informationen können notwendige Schritte einer zumindest teilweisen Isolierung dieser gefährdeten Gruppenmitglieder bis zu einer vollständigen Quarantäne im Anfangsstadium durchgeführt werden, insbesondere während der Inkubationsphase.
  • Insbesondere ist die Erfindung auf ein Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe menschlicher Mitglieder ausgerichtet, wobei jedes Mitglied der Gruppe eine mobile elektronische Vorrichtung führt, nämlich ein obenstehendes Token.
  • Ein vertrauenswürdiger Server ist bereitgestellt, der Konkordanzinformationen zwischen jedem Mitglied und dem dem Mitglied zugewiesenen Token vorzugsweise in einem Registrierungsschritt speichert.
  • Jedes Token umfasst eine elektronische Token-Steuerung mit einer Token-Logikeinheit, einer Token-Speichereinheit und einer Token-Kommunikationseinheit.
  • Die Token-Steuereinheit ist dazu konzipiert, einen lokalen Token-Code zu erzeugen, wobei, wenn sich zwei Token einander nähern und vorbestimmte Näherungskriterien erfüllt sind, die lokalen Token-Codes in einer Näherungsroutine zwischen den Token-Steuerungen der beiden Token ausgetauscht werden.
  • Das vorgeschlagene Verfahren erlaubt, die Ausbreitungswege der Infektionskrankheit abzuschneiden, indem Isoliermaßnahmen bezüglich jener Mitglieder der Gruppe, die aufgrund ihrer Kontaktgeschichte mit dem infizierten Mitglied der Gruppe gefährdet sind, vorgenommen werden. Der Begriff „Kontakt“ wird in einem weiten Sinn verwendet, sodass er auch die Näherung von zwei Mitgliedern der Gruppe unterhalb des vorbestimmten Schwellenabstands wie oben angegeben beinhaltet. Der Begriff „Abstandsverlauf“ repräsentiert dementsprechend den Verlauf von zwei sich einander nähernden Mitgliedern der Gruppe wie oben angegeben.
  • Die Erfindung erlaubt auch die Analyse des Ausbreitungsmusters der Infektionskrankheit hinsichtlich Gruppenmitgliedern und Zeit. Dies kann auf der Kombination verschiedener Konkordanzinformationen basieren, die wie oben angegeben im vertrauenswürdigen Server gespeichert sind.
  • Nach Anspruch 2 werden, wenn sich zwei Token einander unterhalb eines vorbestimmten Schwellenabstands nähern, die lokalen Token-Codes in einer Näherungsroutine zwischen den Token-Steuerungen über die jeweiligen Token-Kommunikationseinheiten der beiden Token ausgetauscht. Dies ist die einfachste mögliche Weise zum Umsetzen der vorliegenden Erfindung.
  • Es sind verschiedene Alternativen für die Erzeugung des lokalen Token-Codes in Abhängigkeit von dem erforderlichen Datensicherheitsniveau möglich. Dies ist der Gegenstand von Anspruch 3.
  • Die Token müssen nur Kommunikation mit dem jeweiligen Token innerhalb des vorbestimmten Schwellenabstands bereitstellen. Aus diesem Grund kann ein einfacher Drahtloskommunikationsstandard wie etwa Bluetooth® verwendet werden (Anspruch 4).
  • Aufgrund des niedrigen Leistungsverbrauchs des obenstehenden Kommunikationsprinzips ist es nach Anspruch 5 gut möglich, dass die Token-Steuerung kontinuierlich den lokalen Code mittels der Kommunikationseinheit aussendet.
  • Die weiteren bevorzugten Ausführungsformen nach den Ansprüchen 6 bis 8 beziehen sich auf vorteilhafte Varianten für die Näherungsroutine. Es ist nach Anspruch 8 insbesondere vorteilhaft, dass zeitbezogene Informationen in der Näherungsliste von Anspruch 7 gespeichert werden. Mit diesen zeitbezogenen Informationen kann es gut möglich sein, die Ausbreitung der Infektionskrankheit basierend auf einem dynamischen Ausbreitungsmodell vorherzusagen.
  • Die Bereitstellung einer Sensoranordnung zum Sammeln mitgliedsspezifischer Körperdaten ist der Gegenstand von Anspruch 9. Es ist nun möglich, die Näherungsroutine nicht nur basierend auf dem obenstehenden Näherungsabstand, sondern zusätzlich basierend auf Sensordaten durchzuführen.
  • Die Hardwareumsetzung ist der Gegenstand der Ansprüche 10 und 11. Es ist insbesondere kosteneffektiv, falls die Hardware der Token-Steuerung speziell für die Funktion des Überwachungsverfahrens ausgelegt ist. Infolgedessen kann das resultierende Token kostengünstig und gleichzeitig kompakt sein. Andererseits kann das Token auf einer standardmäßigen mobilen Vorrichtung basieren. Diese Alternative ist für Mitglieder der Gruppe gut anwendbar, die ohnehin eine mobile Vorrichtung wie etwa ein Smartphone mit sich führen. Dementsprechend kann das vorgeschlagene Verfahren auf verschiedene Weisen umgesetzt werden, wobei die Umsetzung an den jeweiligen Lebensstil der jeweiligen Mitglieder angepasst werden kann. In jedem Fall erlaubt die vorgeschlagene Lösung einen äußerst effizienten und kostengeringen Überwachungsprozess.
  • Anspruch 12 bezieht sich auf eine bevorzugte Ausführungsform für den Registrierungsschritt, der einfach für jedes Mitglied einzeln durch Eingeben einer Identifikation des Tokens und einer Identifikation des Mitglieds in einen vertrauenswürdigen Server umgesetzt wird. Die Identifikation des Tokens kann auch der lokale Token-Code sein. Hier wird erkennbar, dass während der Überwachung gar keine Kommunikation zwischen den Token und dem vertrauenswürdigen Server notwendig ist. Es muss nur gewährleistet sein, dass der Registrierungsschritt irgendwann durchgeführt wurde, was durch eine vertrauenswürdige Kommunikationsleitung zwischen einem Endgerät und dem vertrauenswürdigen Server durchgeführt werden kann. Im einfachsten Fall wird der vertrauenswürdige Server von einer vertrauenswürdigen Entität betrieben, die vom jeweiligen Gruppenmitglied einfach mittels Telefon angerufen werden kann, um den Registrierungsschritt durchzuführen.
  • Die ebenfalls bevorzugte Ausführungsform nach Anspruch 13 bezieht sich auf die Situation, bei der eines der Mitglieder der Gruppe infiziert zu sein scheint. Dann wird eine Infektionsroutine durchgeführt, bei der die Näherungsliste vom Token des infizierten Mitglieds der Gruppe empfangen wird. In der Infektionsroutine werden die lokalen Token-Codes in dieser Näherungsliste basierend auf den Konkordanzinformationen in die jeweiligen Mitgliedsidentifikationen umgewandelt. Diese Mitgliedsidentifikationen können zum Durchführen der obenstehenden Isoliermaßnahmen verwendet werden. Die Erzeugung der obenstehenden Mitgliedsidentifikationen kann vorzugsweise durch eine Endgeräteinheit nach Anspruch 14 durchgeführt werden, die von einer vertrauenswürdigen Entität wie etwa einem Arzt oder dergleichen betrieben wird.
  • Eine andere Lehre nach Anspruch 15 bezieht sich auf das vorgeschlagene Token an sich. Der unabhängige Anspruch 16 bezieht sich auf ein System, das eine Anzahl der vorgeschlagenen Token und einen vertrauenswürdigen Server an sich umfasst. Ferner bezieht sich der unabhängige Anspruch 16 auf ein Computerprogrammprodukt, das auf den Token und/oder dem vertrauenswürdigen Server an sich ausgeführt wird. Alle bei dem vorgeschlagenen Verfahren gegebenen Erläuterungen sind gleichermaßen auf das Token nach Anspruch 15, das System nach Anspruch 16 und das Computerprogrammprodukt nach Anspruch 17 anwendbar.
  • Im Folgenden wird eine bevorzugte Ausführungsform der Erfindung mit Bezug auf die Zeichnungen erläutert. In den Zeichnungen zeigen:
    • 1 das vorgeschlagene System zum Durchführen des vorgeschlagenen Verfahrens während der Registrierung und/oder Überwachung, und
    • 2 das vorgeschlagene System zum Durchführen des vorgeschlagenen Verfahrens während der Infektionsroutine.
  • Das vorgeschlagene Verfahren dient zur Überwachung der potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe Z menschlicher Mitglieder zn , wobei jedes Mitglied zn der Gruppe Z ein mobiles elektronisches Token tn mitführt.
  • Neben den Token tn umfasst das vorgeschlagene System 1 einen vertrauenswürdigen Server 2, der als eine Cloud-Anwendung ausgeführt werden kann, wie in den Zeichnungen angegeben, der jedoch eine beliebige Art von Computerhardware sein kann. Der Ausdruck „vertrauenswürdig“ bedeutet, dass Maßnahmen getroffen wurden, die einen unautorisierten Zugriff auf die im Server 2 gespeicherten Informationen verhindern.
  • Insbesondere speichert der Server 2 Konkordanzinformationen 3 für jedes registrierte Mitglied zn , wobei die Konkordanzinformationen 3 die Verknüpfung zwischen dem Mitglied zn und dem dem Mitglied zugewiesenen Token tn repräsentieren. Die Registrierung wird vorzugsweise in einem zu erläuternden Registrierungsschritt durchgeführt.
  • Jedes Token tn umfasst eine elektronische Token-Steuerung 5 mit einer Token-Logikeinheit 6, einer Token-Speichereinheit 7 und einer Token-Kommunikationseinheit 8. Der Ausdruck „Einheit“ soll nur in einem funktionellen Sinn verstanden werden. Diese Einheiten können auch in ein und dieselbe elektronische Hardware integriert sein.
  • Die Token-Logikeinheit 6 ist dazu konzipiert, einen lokalen Token-Code cn zu erzeugen, wobei, wenn sich zwei Token tn , tn+1 einander nähern und vorbestimmte Näherungskriterien erfüllt sind, die lokalen Token-Codes cn , cn+1 in einer Näherungsroutine mittels der jeweiligen Token-Kommunikationseinheiten 8 zwischen den Token-Steuerungen 5 der beiden Token tn , tn+1 ausgetauscht werden.
  • In einer besonders bevorzugten Ausführungsform werden demnach, wenn sich zwei Token tn und tn+1 einander unterhalb eines vorbestimmten Schwellenabstands do nähern, die lokalen Token-Codes cn und cn+1 in einer Näherungsroutine mittels der jeweiligen Token-Kommunikationseinheiten 8 zwischen den Token-Steuerungen 5 der beiden Token tn und tn+1 ausgetauscht.
  • Zusätzlich oder alternativ beinhalten die vorbestimmten Näherungskriterien, dass sich die beiden Token tn , tn+1 einander auf eine vorbestimmte zeitliche Weise nähern. Dies kann bevorzugt bedeuten, dass die vorbestimmten Näherungskriterien beinhalten, dass die beiden Token tn , tn+1 zumindest für ein vorbestimmtes Zeitintervall in einem Abstand voneinander unterhalb des vorbestimmten Schwellenabstands bleiben.
  • Zu diesem Punkt sollte verstanden werden, dass die betreffende Gruppe Z auf verschiedene Weisen definiert werden kann. In einer Alternative ist die Gruppe Z von Mitgliedern eine kleine Gruppe, wie Menschen, die in einem Krankenhaus anwesend sind, wie etwa Patienten, Krankenpfleger und Ärzte. Als eine Alternative kann es sich bei einer solchen Gruppe um die Menschen handeln, die in Altersheimen oder Pflegeheimen anwesend sind. Als noch eine Alternative kann die Gruppe Z sich auf Schulen, Geschäftsanlagen oder dergleichen beziehen. Eine Gruppe Z kann jedoch auch sehr groß sein und beispielsweise als alle Bürger eins Landes oder sogar Kontinents definiert sein. Die große Variabilität der Definition der betreffenden Gruppe Z führt zu der Tatsache, dass verschiedene Mitglieder mit sehr unterschiedlichen Lebensstilen zu berücksichtigen sind. Diese Erkenntnis hat einen sofortigen Einfluss auf die Umsetzung des Tokens tn , wie auch später erläutert wird.
  • Vorzugsweise erzeugt die Token-Logikeinheit 6 des jeweiligen Tokens tn den lokalen Token-Code cn basierend auf dem Speicherinhalt der Token-Speichereinheit 7. Als eine besonders einfache Ausführungsform kann die Erzeugung des lokalen Token-Codes cn auch auf das einfache Erlangen des lokalen Token-Codes cn aus der Token-Speichereinheit 7 zurückgehen. Zusätzlich oder alternativ kann bereitgestellt werden, dass die Token-Logikeinheit 6 den lokalen Token-Code cn basierend auf einem Verschlüsselungsalgorithmus erzeugt. Die Erzeugung des lokalen Token-Codes cn kann statisch sein, sodass der lokale Token-Code cn für ein und dasselbe Token tn immer der gleiche ist. Der lokale Token-Code cn kann jedoch auch als ein dynamischer Code konzipiert sein, der im Laufe der Zeit oder beim Auftreten von Auslöseereignissen variiert.
  • Um in der Lage zu sein, Standardhardware für die Token-Kommunikationseinheit 8 zu verwenden, basiert die Token-Kommunikationseinheit 8 auf der Kommunikation mittels eines Drahtloskommunikationsstandards wie etwa Bluetooth®. Andere Drahtloskommunikationsstandards können angewendet werden.
  • Ferner sendet vorzugsweise die Token-Steuerung 6 kontinuierlich, hier und vorzugsweise periodisch, den lokalen Token-Code mittels der Token-Kommunikationseinheit 8 aus. Dementsprechend soll der Ausdruck „kontinuierlich“ in einem weiten Sinn verstanden werden. In der Näherungsroutine übertragen die Token-Steuerungen 5 der sich nähernden Token tn und tn+1 den lokalen Token-Code cn und cn+1 zu der jeweiligen anderen Token-Steuerung 5 und empfangen den lokalen Token-Code cn und cn+1 von der jeweiligen anderen Token-Steuerung 5. All dies wird mittels der jeweiligen Token-Kommunikationseinheiten 8 durchgeführt, wie in 1 angegeben.
  • Ein einfaches Verfahren zur Detektion der vermerkten Näherung, die den vorbestimmten Schwellenabstand do unterschreitet, besteht in dem Veranlassen, dass die Token tn ein Funksignal mit dem lokalen Token-Code cn mittels solcher reduzierter Übertragungsenergie übertragen, dass das Funksignal durch ein anderes Token tn+1 nur innerhalb des vorbestimmten Schwellenabstands do empfangen werden kann. In diesem Fall warten alle Token tn konitunierlich auf den Empfang des Funksignals und damit den lokalen Token-Code cn+1 eines anderen Tokens tn+1 . Falls ein solches Funksignal und damit ein lokaler Token-Code empfangen wird, wird die Näherungsroutine initiiert. Alternativ kann ein Abstandsmesssensor bereitgestellt sein, der basierend auf Funkwellen, optischen Signalen, Ultraschallsignalen, kapazitiven Signalen, induktiven Signalen oder dergleichen arbeiten kann.
  • In der Näherungsroutine wird der empfangene lokale Token-Code cn mittels der Token-Speichereinheit 7 in einer Näherungsliste 9 gespeichert. Zusätzlich wird in der Näherungsroutine vorzugsweise der Zeitpunkt und/oder weiter bevorzugt die Dauer der jeweiligen Näherung zwischen den beiden Token tn und tn+1 durch die Token-Logikeinheit 6 detektiert und in der Näherungsliste 9 gespeichert. Diese zeitbezogenen Informationen sind in 1 mit der Bezugsziffer 10 angegeben.
  • Vorzugsweise ist eine Sensoranordnung bereitgestellt, die Teil des jeweiligen Tokens tn sein kann oder separat von dem jeweiligen Token tn umgesetzt sein kann, die dann vorzugsweise mit dem Token tn kommuniziert, um entsprechende Sensordaten zu übertragen.
  • Die Sensoranordnung sammelt mitgliedsspezifische Körperdaten, die beispielsweise Körpertemperatur, Aktivität hinsichtlich Körperbewegung im Laufe des Tags oder der Nacht, Herzfrequenz usw. des Mitglieds zn sein können. Es wird bevorzugt, dass die vorbestimmten Näherungskriterien auch beinhalten, dass vorbestimmte gesammelte Körperdaten eine vorbestimmte Grenze überschreiten. Beispielsweise sind die vorbestimmten Näherungskriterien erfüllt, falls zusätzlich zu der Näherung an sich die Körpertemperatur des jeweiligen Mitglieds zn eine gewisse Grenze überschreitet.
  • Es sei darauf hingewiesen, dass in der Näherungsroutine nicht notwendigerweise nur die lokalen Token-Codes cn , cn+1 zwischen den jeweiligen Token tn , tn+1 ausgetauscht werden. Zusätzlich zu den lokalen Token-Codes cn , cn+1 können andere Informationen wie etwa Sensordaten einer obenstehenden Sensoranordnung auch zwischen den beiden Token tn , tn+1 ausgetauscht werden. Es ist gemäß gewissen Kommunikationsregeln auch möglich, dass die lokalen Token-Codes cn , cn+1 bidirektional ausgetauscht werden, während die zusätzlichen Informationen unidirektional kommuniziert werden.
  • Wie oben angemerkt, hängt die Hardware des Tokens tn und insbesondere die Hardware der Token-Steuerung 5 von der Art der Mitglieder zn der betreffenden Gruppe Z ab. In einer bevorzugten Ausführungsform ist die Hardware der Token-Steuerung 5 besonders für die Funktion des vorgeschlagenen Überwachungsverfahrens ausgelegt. Wie in den Zeichnungen gezeigt, kann das Token tn eine kompakte Einheit mit eine Drucktaste 11 für dessen Aktivierung sein. Es kann allgemein das Design von Notfall-Token aufweisen, die in vielen Einrichtungen wie Krankenhäusern und Pflegeheimen als Standard anzusehen sind. Solche Token tn können als kleine handgehaltene Gegenstände, Halsketten, Klebestreifen, entweder an Bekleidung oder am Körper angebracht, umgesetzt sein.
  • Zusätzlich oder alternativ kann die Hardware der Token-Steuerung 5 eine standardmäßige mobile Vorrichtung wie etwa ein Smartphone sein. Wie oben angemerkt, kann dies vorteilhaft sein, falls die betreffenden Mitglieder zn aufgrund ihres Lebensstils ohnehin ein Smartphone mitführen.
  • Das Token tn kann auch mit einer Anzeige 12 ausgestattet sein, die so einfach wie eine Lichtangabe sein kann oder dem Mitglied Textinformationen bereitstellen kann. Die Anzeige 12 kann auch akustische Informationen bereitstellen, wie etwa einfache Pieptöne bis hin zu Sprachausgabe. Es kann vorteilhaft sein, dass die Anzeige 12 das jeweilige Mitglied zn während der Näherungsroutine gemäß einer Alarmregel alarmiert, vorzugsweise, falls der Abstand zwischen zwei Mitgliedern zn , zn+1 für ein zweites vorbestimmtes Zeitintervall unterhalb der vorbestimmten Schwelle liegt.
  • Wie oben angemerkt, ist ein wichtiger Aspekt des vorgeschlagenen Verfahrens die Umsetzung des Registrierungsschritts 4. Vorzugsweise wird der Registrierungsschritt durch das Eingeben einer Identifikation des Tokens tn und einer Identifikation des Mitglieds zn in den Server 2 umgesetzt. Abhängig von der Anwendung gibt es verschiedene Möglichkeiten zum Durchführen dieses Registrierungsschritts. Im Fall eines Pflegeheims wird der Server 2 auf einem lokalen Computer im Pflegeheim umgesetzt, wobei der Computer von der lokalen IT-Abteilung verwaltet wird. In einer solchen Struktur kann der Registrierungsschritt einfach ein Telefonanruf des jeweiligen Mitglieds zn bei der IT-Abteilung zur Übermittlung der Identifikation des Mitglieds zn und der Identifikation des Tokens tn sein. In einem besonders einfachen Fall wird die Identifikation des Tokens tn einfach auf das Token tn aufgedruckt. Die Eingabe der jeweiligen Informationen in den Server 2 wird dann durch die IT-Abteilung durchgeführt. Dafür ist verschiedenartige technische Unterstützung möglich, wie etwa das Lesen eines QR-Codes, der auf dem Token tn platziert ist und seine Identifikation repräsentiert, unter Verwendung eines QR-Code-Lesegeräts. Dies und die Eingabe der Identifikation des Mitglieds zn kann durch eine standardmäßige mobile Vorrichtung wie etwa ein Smartphone bereitgestellt werden.
  • 2 zeigt die Situation, bei der ein Mitglied zn der Gruppe Z infiziert zu sein scheint. Die vertrauenswürdige Entität, hier der Arzt P, initiiert eine Infektionsroutine. Dafür wird die Näherungsliste 9 vom Token tn des Mitglieds zn empfangen. Der Arzt P verwendet eine Empfangseinheit 13, die Teil eines Endgeräts 14 im Büro des Arztes ist. Die Funktion des Endgeräts 14 kann auch durch eine andere Komponente durchgeführt werden, insbesondere eine standardmäßige mobile Vorrichtung wie etwa ein Smartphone. Eine sichere Kommunikationsleitung 15 ist zwischen dem Endgerät 14 und dem Server 2 bereitgestellt, sodass der Arzt P einen direkten oder indirekten Zugriff auf die im Server 2 gespeicherten Konkordanzinformationen 3 aufweist. Anschließend werden die lokalen Token-Codes cn in dieser Näherungsliste 9 in die Liste von Mitgliedsidentifikationen 16 umgewandelt, die den lokalen Token-Codes cn entsprechen, wobei die Umwandlung auf den im Server 2 gespeicherten Konkordanzinformationen 3 basiert. Die Umwandlung kann auf dem Server 2 oder auf dem Endgerät 14 durchgeführt werden, jeweils basierend auf den im Server 2 gespeicherten Konkordanzinformationen 3.
  • Insgesamt ist das obenstehende Endgerät 14 bereitgestellt, das die Näherungsliste 9 von dem Token tn empfängt, das mit dem Server 2 kommuniziert und dem Arzt P die Liste von Mitgliedsinformationen 16 bereitstellt, sodass er die jeweiligen obenstehenden Maßnahmen ergreifen kann.
  • Falls das Token tn auch zusätzliche Informationen wie etwa obenstehende Sensordaten speichert, kann der Arzt P auch diese Daten aus dem Token tn abrufen und Schlussfolgerungen bezüglich des dem Token tn zugewiesenen Mitglieds und bezüglich aller Mitglieder, die der Näherungsliste 9 entsprechen, ziehen. Außerdem kann bereitgestellt sein, dass der Arzt P Informationen des allgemeinen Gesundheitszustands des jeweiligen Mitglieds zn aus einem anderen Patienteninformationssystem abruft, um die Infektionssituation auf Basis eines umfassenderen Bildes zu beurteilen.
  • Die Token-Logik 6 und/oder das Endgerät 14 und/oder ein separates Rechensystem können mit einem Bewertungsmodul ausgestattet sein, das eine Bewertung des jeweiligen Mitglieds zn bezüglich seines Infizierungsrisikos in einer Bewertungsroutine berechnet. In der Bewertungsroutine wird ein Bewertungsindex basierend auf der Näherungsliste 9, vorzugsweise auch basierend auf im Server 2 gespeicherten Informationen berechnet. Dies ist besonders für Ärzte vorteilhaft, die ständig in engem Kontakt mit Patienten arbeiten.
  • Gemäß unabhängigen Lehren werden das vorgeschlagene Token tn an sich, das vorgeschlagene System 1 an sich und das vorgeschlagene Computerprogrammprodukt zum Durchführen des vorgeschlagenen Verfahrens an sich beansprucht. Alle Erläuterungen, die bezüglich des vorgeschlagenen Verfahrens gegeben werden, sind vollständig auf diese unabhängigen Lehren anwendbar.

Claims (17)

  1. Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit innerhalb einer Gruppe (Z) menschlicher Mitglieder (zn), wobei jedes Mitglied (zn) der Gruppe (Z) ein mobiles elektronisches Token (tn) mitführt, wobei ein Server (2) bereitgestellt ist, der Konkordanzinformationen (3) zwischen jedem Mitglied (zn) und dem dem Mitglied (zn) zugewiesenen Token (tn) vorzugsweise in einem Registrierungsschritt (3) speichert, wobei jedes Token (tn) eine elektronische Token-Steuerung (5) mit einer Token-Logikeinheit (6), einer Token-Speichereinheit (7) und einer Token-Kommunikationseinheit (8) umfasst, wobei die Token-Logikeinheit (6) dazu konzipiert ist, einen lokalen Token-Code (cn) zu erzeugen, und wobei, wenn sich zwei Token (tn, tn+1) einander nähern und vorbestimmte Näherungskriterien erfüllt sind, die lokalen Token-Codes (cn, cn+1) in einer Näherungsroutine zwischen den Token-Steuerungen (5) der beiden Token (tn, tn+1) ausgetauscht werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die vorbestimmten Näherungskriterien beinhalten, dass sich die beiden Token (tn, tn+1) einander unterhalb eines vorbestimmten Schwellenabstands (do) nähern, und/oder dass die vorbestimmten Näherungskriterien beinhalten, dass sich die beiden Token (tn, tn+1) auf eine vorbestimmte zeitliche Weise einander nähern, vorzugsweise, dass die vorbestimmten Näherungskriterien beinhalten, dass die beiden Token (tn, tn+1) zumindest für ein vorbestimmtes Zeitintervall in einem Abstand voneinander unterhalb des vorbestimmten Schwellenabstands bleiben.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Token-Logikeinheit (6) den lokalen Token-Code (cn) basierend auf dem Speicherinhalt der Token-Speichereinheit (7) erzeugt, und/oder dass die Token-Logikeinheit (6) den lokalen Token-Code (cn) basierend auf einem Verschlüsselungsalgorithmus erzeugt.
  4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Token-Kommunikationseinheit (8) auf der Kommunikation mittels eines Drahtloskommunikationsstandards basiert, insbesondere Bluetooth®.
  5. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Token-Steuerung (5) kontinuierlich, vorzugsweise periodisch, den lokalen Token-Code (cn) mittels der Token-Kommunikationseinheit (8) aussendet.
  6. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass in der Näherungsroutine die Token-Steuerungen (5) der sich nähernden Token (tn, tn+1) den lokalen Token-Code (cn, cn+1) zu der jeweiligen anderen Token-Steuerung (5) übertragen und den lokalen Token-Code (cn, cn+1) von der jeweiligen anderen Token-Steuerung (5) empfangen.
  7. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass in der Näherungsroutine der empfangene lokale Token-Code (cn, cn+1) mittels der Token-Speichereinheit (7) in einer Näherungsliste (9) gespeichert wird.
  8. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass in der Näherungsroutine der Zeitpunkt und/oder vorzugsweise die Dauer der jeweiligen Näherung durch die Token-Logikeinheit (6) detektiert und in der Näherungsliste (9) gespeichert wird.
  9. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass eine Sensoranordnung bereitgestellt ist, die mitgliedsspezifische Körperdaten sammelt, und dass die vorbestimmten Näherungskriterien beinhalten, dass vorbestimmte gesammelte Körperdaten eine vorbestimmte Grenze überschreiten.
  10. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Hardware der Token-Steuerung (5) speziell für die Funktion des Überwachungsverfahrens ausgelegt ist, und/oder wobei die Hardware der Token-Steuerung (5) eine standardmäßige mobile Vorrichtung ist, insbesondere ein Smartphone.
  11. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass in der Näherungsroutine die beiden sich nähernden Token (tn, tn+1) eine Nachricht mittels einer Anzeige (12) zu dem zugewiesenen Mitglied (zn, zn+1) entsenden.
  12. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Registrierungsschritt (4) durch Eingeben einer Identifikation des Tokens (tn) und einer Identifikation des Mitglieds (zn) in den Server (2) umgesetzt wird.
  13. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass in einer Infektionsroutine die Näherungsliste (9) von einem Token (tn) empfangen wird und die lokalen Token-Codes (cn) in dieser Näherungsliste (9) in die Liste von Mitgliedsidentifikationen (16), die den lokalen Token-Codes (cn) entsprechen, umgewandelt werden, wobei die Umwandlung auf den im Server (2) gespeicherten Konkordanzinformationen (3) basiert.
  14. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein Endgerät (14) bereitgestellt ist, das die Näherungsliste (9) von dem Token empfängt, das mit dem Server (2) kommuniziert und die Liste von Mitgliedsidentifikationen (16) bereitstellt.
  15. Token zum Durchführen eines Verfahrens nach einem der vorangegangenen Ansprüche.
  16. System, das eine Anzahl von Token (tn) und einen Server (2) zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 14 umfasst.
  17. Computerprogrammprodukt zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 14.
DE102020110132.5A 2020-04-13 2020-04-13 Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit Pending DE102020110132A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102020110132.5A DE102020110132A1 (de) 2020-04-13 2020-04-13 Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020110132.5A DE102020110132A1 (de) 2020-04-13 2020-04-13 Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit

Publications (1)

Publication Number Publication Date
DE102020110132A1 true DE102020110132A1 (de) 2021-10-14

Family

ID=77851730

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020110132.5A Pending DE102020110132A1 (de) 2020-04-13 2020-04-13 Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit

Country Status (1)

Country Link
DE (1) DE102020110132A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180353085A1 (en) 2017-06-09 2018-12-13 Anthony Olivero Portable biometric monitoring device and method for use thereof

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180353085A1 (en) 2017-06-09 2018-12-13 Anthony Olivero Portable biometric monitoring device and method for use thereof

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Können wir der Corona-App vertrauen? , 09.04.2020 [recherchiert am 19.11.2020]. Im Internet: <URL: https://www.heise.de/tp/features/Koennen-wir-der-Corona-App-vertrauen-4700302.html>
Was kann die geplante Corona-App ?, 02.04.2020 [recherchiert am 19.11.2020]. Im Internet: <URL: https://www.lto.de/recht/hintergruende/h/corona-app-gesundheitsschutz-infektion-virus-datenschutz-pepp-pt/>

Similar Documents

Publication Publication Date Title
DE60035112T2 (de) System und verfahren zur generierung und übertragung von daten
DE60129964T2 (de) System zur gesundheitsüberwachung
DE102008054442A1 (de) Verfahren zur ferndiagnostischen Überwachung und Unterstützung von Patienten sowie Einrichtung und telemedizinisches Zentrum
DE102020107972A1 (de) Verfahren zur Reduzierung der Übertragung von Krankheitserregern sowie System umfassend eine Vielzahl von Kommunikationseinrichtungen
DE4441907A1 (de) Patienten-Notfallreaktionssystem
DE10354929A1 (de) Verfahren und Einrichtung zum Identifizieren eines Subjektes
DE102010060751A1 (de) System und Verfahren zur Patientenaufenthaltsorts-Vorhersage
DE102012214697A1 (de) Vorrichtung, Verfahren und Applikation zur Ermittlung eines aktuellenBelastungsniveaus
WO2002056234A2 (de) System zur erfassung und speicherung personenspezifischer daten und entsprechendes speicherelement sowie verfahren zur rettung und/oder medizinischen versorgung von lebewesen im notfall
EP1226782B1 (de) Verfahren und Vorrichtung zur poststationären Überwachung eines Patienten
CH713793B1 (de) Zentrales Stationsinformationssystem.
DE102020110132A1 (de) Verfahren zum Überwachen der potenziellen Ausbreitung einer Infektionskrankheit
CN106606348A (zh) 基于移动通信的监测长者生命安全、健康及生活安全系统
DE60210302T2 (de) Verfahren zum sicheren übertragen von patientendaten auf einem/einen datenträger
DE102007032610A1 (de) Verfahren zur Fernüberwachung des medizinischen Zustandes eines Nutzers, System und Vorrichtung dafür
EP1288838A2 (de) Patienteninformationssystem zur Erläuterung von medizinischen Befunden
DE102017011683A1 (de) Gasmessvorrichtung
DE102017010149A1 (de) Verfahren zur Durchführung einer Änderung einer Zuordnung von zugeordneten Patienten in einem Pflegesystem sowie Pflegesystem
von Solodkoff et al. Acceptance of Care Offers for exclusive Remote Treatment Illustrated by the Telemedical Model Project" docdirekt" with a Mixed-Methods Design
CN108831534A (zh) 结核病综合管理系统及移动app项目
DE102020201627A1 (de) Verfahren, vorrichtung und system zur fernüberwachung eines medizintechnischen geräts
DE102021104705A1 (de) Verfahren und System zur Erfassung des Gesundheitszustandes einer Person
DE102018127348A1 (de) Benachrichtigungsverfahren und Benachrichtigungssystem
DE102021100063A1 (de) Patientenverwaltungssystem
DE102020110134A1 (de) Vorrichtung und Verfahren zur Ermittlung der Wahrscheinlichkeit einer Infektion

Legal Events

Date Code Title Description
R163 Identified publications notified