DE102017113121A1 - Verfahren und Einrichtung für die automatische Übertragung medizinischer Daten - Google Patents

Verfahren und Einrichtung für die automatische Übertragung medizinischer Daten Download PDF

Info

Publication number
DE102017113121A1
DE102017113121A1 DE102017113121.3A DE102017113121A DE102017113121A1 DE 102017113121 A1 DE102017113121 A1 DE 102017113121A1 DE 102017113121 A DE102017113121 A DE 102017113121A DE 102017113121 A1 DE102017113121 A1 DE 102017113121A1
Authority
DE
Germany
Prior art keywords
vehicle
data
accident
processor
occupant
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.)
Withdrawn
Application number
DE102017113121.3A
Other languages
English (en)
Inventor
Tuan Anh Be
Oliver Lei
Allen R. MURRAY
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.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
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 Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102017113121A1 publication Critical patent/DE102017113121A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0004—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by the type of physiological signal transmitted
    • A61B5/0013—Medical image data
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0022—Monitoring a patient using a global network, e.g. telephone networks, internet
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0059—Measuring for diagnostic purposes; Identification of persons using light, e.g. diagnosis by transillumination, diascopy, fluorescence
    • A61B5/0077—Devices for viewing the surface of the body, e.g. camera, magnifying lens
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/16—Devices for psychotechnics; Testing reaction times ; Devices for evaluating the psychological state
    • A61B5/18—Devices for psychotechnics; Testing reaction times ; Devices for evaluating the psychological state for vehicle drivers or machine operators
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/68—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient
    • A61B5/6887—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient mounted on external non-worn devices, e.g. non-medical devices
    • A61B5/6893—Cars
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/74—Details of notification to user or communication with user or patient ; user input means
    • A61B5/746—Alarms related to a physiological condition, e.g. details of setting alarm thresholds or avoiding false alarms
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/74—Details of notification to user or communication with user or patient ; user input means
    • A61B5/7465—Arrangements for interactive communication between patient and care services, e.g. by using a telephone network
    • A61B5/747—Arrangements for interactive communication between patient and care services, e.g. by using a telephone network in case of emergency, i.e. alerting emergency services
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/02—Registering or indicating driving, working, idle, or waiting time only
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/10—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using wireless transmission systems
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5116—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B2503/00—Evaluating a particular growth phase or type of persons or animals
    • A61B2503/20—Workers
    • A61B2503/22—Motor vehicles operators, e.g. drivers, pilots, captains
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/68—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient
    • A61B5/6801—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient specially adapted to be attached to or worn on the body surface
    • A61B5/6802—Sensor mounted on worn items
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/68—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient
    • A61B5/6887—Arrangements of detecting, measuring or recording means, e.g. sensors, in relation to patient mounted on external non-worn devices, e.g. non-medical devices
    • A61B5/6898—Portable consumer electronic devices, e.g. music players, telephones, tablet computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2038—Call context notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Landscapes

  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Veterinary Medicine (AREA)
  • Molecular Biology (AREA)
  • Animal Behavior & Ethology (AREA)
  • Biophysics (AREA)
  • Pathology (AREA)
  • Surgery (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Emergency Management (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physiology (AREA)
  • Environmental & Geological Engineering (AREA)
  • Critical Care (AREA)
  • Emergency Medicine (AREA)
  • Marketing (AREA)
  • Nursing (AREA)
  • Child & Adolescent Psychology (AREA)
  • Educational Technology (AREA)
  • Primary Health Care (AREA)
  • Social Psychology (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • Developmental Disabilities (AREA)
  • Psychology (AREA)
  • Hospice & Palliative Care (AREA)
  • Psychiatry (AREA)
  • Radiology & Medical Imaging (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Computing Systems (AREA)
  • Alarm Systems (AREA)

Abstract

Ein System beinhaltet einen Prozessor, der dazu ausgelegt ist, kabellos Unfallindizien von einem Fahrzeug zu empfangen. Der Prozessor ist auch dazu ausgelegt, auf ein Insassenprofil mit medizinische Daten, die einen Insassen des Fahrzeugs betreffen, zuzugreifen, einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale) zu identifizieren und die medizinischen Daten als Reaktion auf die Unfallindizien an den identifizierten PSAP zu senden.

Description

  • TECHNISCHES GEBIET
  • Die beispielhaften Ausführungsformen betreffen allgemein ein Verfahren und eine Einrichtung für die automatische Übertragung medizinischer Daten.
  • ALLGEMEINER STAND DER TECHNIK
  • Auf dem Gebiet der Automobilsicherheit wurden im Hinblick auf das Bereitstellen von Unterstützung für ein in einen Unfall verwickeltes Fahrzeug zahlreiche Fortschritte gemacht. Fahrzeugsensoren sind fähig, das Auftreten von Unfällen zu erkennen und mittels Fahrzeugtelematiksystemen automatisch Notrufzentralen oder andere Parteien anzurufen. Beschädigte Fahrzeugsysteme können dies selbst melden oder der Schaden kann durch fahrzeugseitige Sensoren erkannt werden. Dieser Schaden kann ebenfalls einer Notrufzentrale gemeldet werden, falls er relevant ist oder möglicherweise die Art der bereitgestellten Hilfe beeinflusst.
  • Fahrzeugkameras können Bilder des Innenraums und der äußeren Umgebung an Notrufzentralen weiterleiten. Mikrofone können Audiodaten weiterleiten und die Kommunikation von Insassen mit einer Notrufzentrale ermöglichen. Ein gemeinsames Merkmal der meisten dieser Unfallunterstützungssysteme ist, dass die Notrufzentrale oder ein anderer Drittparteienhelfer auf irgendeine Weise direkt mit dem Fahrzeug interagiert oder zumindest durch eine entfernte Vermittlungseinrichtung Daten mit dem Fahrzeug austauscht.
  • KURZDARSTELLUNG
  • Bei einer ersten beispielhaften Ausführungsform beinhaltet ein System einen Prozessor, der dazu ausgelegt ist, als Reaktion auf das Erkennen eines Fahrzeugunfalls kabellos eine Anweisung an einen entfernten Server zu senden, medizinische Daten von Insassen an einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale) zu übertragen.
  • Bei einer zweiten beispielhaften Ausführungsform beinhaltet ein System einen Prozessor, der dazu ausgelegt ist, kabellos Unfallindizien von einem Fahrzeug zu empfangen. Der Prozessor ist auch dazu ausgelegt, auf ein Insassenprofil mit medizinischen Daten, die einen Insassen des Fahrzeugs betreffen, zuzugreifen, einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale) zu identifizieren, mit dem das Fahrzeug wahrscheinlich kommuniziert, und die medizinischen Daten als Reaktion auf die Zusammenstoßindizien an den identifizierten PSAP zu senden.
  • Bei einer dritten beispielhaften Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Senden medizinischer Fahrzeuginsasseninformationen an einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale), der als ein PSAP zum Bearbeiten von Unfalldaten als Reaktion auf das Empfangen einer kabellosen Benachrichtigung von einem Fahrzeug, das einen Unfall meldet, identifiziert ist. Die medizinischen Insasseninformationen werden aus einem Insassenprofil aufgerufen, das zuvor gespeicherte medizinische Informationen für einen Insassen, der sich gegenwärtig in einem Fahrzeug, das den Unfall meldet, befindet, beinhaltet.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 stellt ein beispielhaftes Fahrzeugdatenverarbeitungssystem dar;
  • 2 stellt ein Beispiel für einen Passagieridentifikationsprozess dar;
  • 3 stellt ein Beispiel für einen Notfallereignisabwicklungsprozess dar;
  • 4A stellt ein Beispiel für einen Profilerfassungsprozess dar;
  • 4B stellt ein Beispiel für einen Datensammlungs- und -zustellungsprozess dar; und
  • 5 stellt ein Beispiel für einen weiteren Datensammlungsprozess dar.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Wie erfordert werden hier ausführliche Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft sind und in verschiedenen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details bestimmter Komponenten zu zeigen. Die speziellen strukturellen und funktionalen Details, die hier offenbart werden, sollen deshalb nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie der beanspruchte Gegenstand auf verschiedene Weise einzusetzen ist.
  • 1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Datenverarbeitungssystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines solchen fahrzeugbasierten Datenverarbeitungssystems 1 ist das von THE FORD MOTOR COMPANY hergestellte SNYC-System. Ein mit einem fahrzeugbasierten Datenverarbeitungssystem ausgestattetes Fahrzeug kann eine im Fahrzeug befindliche visuelle Frontend-Schnittstelle 4 enthalten. Der Nutzer kann auch in der Lage sein, mit der Schnittstelle zu interagieren, falls sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. Bei einer weiteren beispielhaften Ausführungsform geschieht die Interaktion durch Knopfdruck, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
  • Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeugbasierten Datenverarbeitungssystems. Der Prozessor ist im Fahrzeug bereitgestellt und erlaubt das fahrzeugseitige Verarbeiten von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtpersistenten 5 als auch einem persistenten Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher ein Direktzugriffsspeicher (RAM) und der persistente Speicher ist ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann persistenter (nichtflüchtiger) Speicher alle Formen von Speicher beinhalten, die Daten beibehalten, wenn ein Computer oder ein anderes Gerät ausgeschaltet wird. Dies beinhaltet, ohne darauf beschränkt zu sein, HDDs, CDs, DVDs, Magnetbänder, Solid-State-Laufwerke, tragbare USB-Laufwerke und jede andere geeignete Form persistenten Speichers.
  • Der Prozessor ist auch mit mehreren unterschiedlichen Eingängen versehen, die es dem Nutzer erlauben, mit dem Prozessor in Verbindung zu treten. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Zusatzeingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der ein Touchscreen-Display sein kann, und ein BLUETOOTH-Eingang 15 bereitgestellt. Ein Eingangswähler 51 ist ebenfalls bereitgestellt, um es einem Nutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Eingaben ins Mikrofon und den Zusatzanschluss werden von einem Konverter 27 von analog zu digital konvertiert, bevor sie an den Prozessor weitergeleitet werden. Auch wenn dies nicht gezeigt ist, können zahlreiche Fahrzeugkomponenten und Zusatzkomponenten, die in Verbindung mit dem VCS stehen, ein Fahrzeugnetzwerk (wie zum Beispiel, ohne darauf beschränkt zu sein, einen CAN-Bus) nutzen, um Daten an das und vom VCS (oder Komponenten desselben) weiterzuleiten.
  • Ausgaben des Systems können, ohne darauf beschränkt zu sein, eine visuelle Displayausgabe 4 und eine Lautsprecherausgabe 13 oder Stereoanlagenausgabe beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Konverter 9 vom Prozessor 3. Die Ausgabe kann entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, auch an ein entferntes BLUETOOTH-Gerät wie beispielsweise das PND 54 oder ein USB-Gerät wie beispielsweise das Fahrzeugnavigationsgerät 60 erfolgen.
  • Bei einer beispielhaften Ausführungsform nutzt das System 1 den BLUETOOTH-Sendeempfänger 15, um mit einem mobilen Gerät 53 eines Nutzers (z. B. Mobiltelefon, Smartphone, PDA oder einem anderen Gerät, das kabellose Konnektivität mit einem entfernten Netzwerk aufweist) zu kommunizieren 17. Das mobile Gerät kann dann genutzt werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, zum Beispiel mittels Kommunikation 55 mit einem Mobilfunkmast 57. Bei einigen Ausführungsformen kann der Mast 57 ein Wi-Fi-Zugangspunkt sein.
  • Eine beispielhafte Kommunikation zwischen dem mobilen Gerät und dem BLUETOOTH-Sendeempfänger ist durch das Signal 14 dargestellt.
  • Das Paaren eines mobilen Geräts 53 und des BLUETOOTH-Sendeempfängers 15 kann durch einen Knopf 52 oder eine ähnliche Eingabe veranlasst werden. Entsprechend wird die CPU angewiesen, dass der fahrzeugseitige BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einem mobilen Gerät gepaart wird.
  • Zwischen der CPU 3 und dem Netzwerk 61 können zum Beispiel unter Verwendung eines dem mobilen Gerät 53 zugeordneten Datentarifs, von Data-over-Voice oder von DTMF-Tönen Daten kommuniziert werden. Alternativ kann es wünschenswert sein, ein fahrzeugseitiges Modem 63, das eine Antenne 18 aufweist, um über das Sprachband Daten zwischen der CPU 3 und dem Netzwerk 61 zu kommunizieren 16, beizufügen. Das mobile Gerät 53 kann dann genutzt werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, zum Beispiel mittels Kommunikation 55 mit einem Mobilfunkmast 57. Bei einigen Ausführungsformen kann das Modem 63 zum Kommunizieren mit dem Netzwerk 61 die Kommunikation 20 mit dem Mast 57 aufnehmen. Als ein nichteinschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und die Kommunikation 20 kann eine Mobilfunkkommunikation sein.
  • Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem, das eine API beinhaltet, versehen, um mit Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Sendeempfängerzugreifen, um die kabellose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie beispielsweise dem, der sich in einem mobilen Gerät befindet) abzuschließen. Bluetooth ist eine Unterart der IEEE-802-PAN-Protokolle (PAN – Personal Area Network; persönliches Netzwerk). IEEE-802-LAN-Protokolle (LAN – Local Area Network; lokales Netzwerk) beinhalten Wi-Fi und weisen eine bedeutende Funktionalitätsüberschneidung mit IEEE 802 PAN auf. Beide sind geeignet für die kabellose Kommunikation innerhalb eines Fahrzeugs. Ein weiteres Kommunikationsmittel, das in diesem Bereich genutzt werden kann, sind die optische Freiraumkommunikation (wie beispielsweise IrDA) und nichtstandardisierte Verbraucher-IR-Protokolle.
  • Bei einer weiteren Ausführungsform beinhaltet das mobile Gerät 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine Technik, die als Frequenzmultiplexverfahren bekannt ist, eingesetzt sein, wenn der Eigentümer des mobilen Geräts am Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Eigentümer das Gerät nicht gerade nutzt, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz bei einem Beispiel) nutzen. Zwar ist das Frequenzmultiplexverfahren in der analogen Funkkommunikation zwischen dem Fahrzeug und dem Internet gebräuchlich und wird noch immer genutzt, jedoch wurde es für die digitale Mobilfunkkommunikation größtenteils ersetzt durch Mischformen aus Codemultiplexverfahren (CDMA – Code Domain Multiple Access), Zeitmultiplexverfahren (TDMA – Time Domain Multiple Access) und Raummultiplexverfahren (SDMA – Space-Domain Multiple Access). Falls der Nutzer über einen Datentarif, der dem mobilen Gerät zugeordnet ist, verfügt, ist es möglich, dass der Datentarif eine Breitbandübertragung erlaubt und das System könnte eine viel größere Bandbreite nutzen (was die Datenübertragung beschleunigen würde). Bei noch einer weiteren Ausführungsform ist das mobile Gerät 53 durch ein Funkkommunikationsgerät (nicht gezeigt) ersetzt, das am Fahrzeug 31 installiert ist. Bei noch einer weiteren Ausführungsform kann das mobile Gerät 53 ein kabelloses Local-Area-Network-(LAN-)Gerät sein, das zu Kommunikation über zum Beispiel (und ohne Einschränkung) ein 802. 11g-Netzwerk (d. h. Wi-Fi) oder ein WiMax-Netzwerk fähig ist.
  • Bei einer Ausführungsform können eingehende Daten mittels Data-over-Voice oder eines Datentarifs durch das mobile Gerät, durch den fahrzeugseitigen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs hinein geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder anderen Speichermedien 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
  • Zusätzliche Quellen, die mit dem Fahrzeug in Verbindung treten können, beinhalten ein persönliches Navigationsgerät 54, das zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, ein Fahrzeugnavigationsgerät 60, das eine USB- 62 oder eine andere Verbindung aufweist, ein fahrzeugseitiges GPS-Gerät 24 oder ein entferntes Navigationssystem (nicht gezeigt), das Konnektivität mit dem Netzwerk 61 aufweist. USB ist eines von einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWireTM (Apple), i. LINKTM (Sony) und LynxTM (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Gerät-Gerät-Standards. Die meisten der Protokolle können sowohl für die elektrische als auch die optische Kommunikation eingesetzt werden.
  • Ferner könnte die CPU in Verbindung mit verschiedenen anderen Zusatzgeräten 65 stehen. Diese Geräte können durch eine kabellose 67 oder eine kabelgebundene 69 Verbindung verbunden sein. Das Zusatzgerät 65 kann, ohne darauf beschränkt zu sein, persönliche Medienabspielgeräte, kabellose Gesundheitsgeräte, tragbare Computer und ähnliches beinhalten.
  • Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten kabellosen Router 73 verbunden sein, zum Beispiel unter Nutzung eines Wi-Fi-(IEEE-802. 11-)Sendeempfängers 71. Dies könnte es der CPU erlauben, sich mit entfernten Netzwerken in Reichweite des lokalen Routers 73 zu verbinden.
  • Zusätzlich zum Aufweisen beispielhafter Prozesse, die von einem in einem Fahrzeug befindlichen Fahrzeugdatenverarbeitungssystem ausgeführt werden, können die beispielhaften Prozesse bei bestimmten Ausführungsformen von einem Datenverarbeitungssystem, das in Verbindung mit einem Fahrzeugdatenverarbeitungssystem steht, ausgeführt werden. Ein derartiges System kann, ohne darauf beschränkt zu sein, ein kabelloses Gerät (z. B. und ohne Beschränkung ein Mobiltelefon) oder ein entferntes Datenverarbeitungssystem (z. B. und ohne Beschränkung einen Server), das durch das kabellose Gerät verbunden ist, beinhalten. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Datenverarbeitungssysteme (VACS – Vehicle Associated Computing Systems) bezeichnet werden. Bei bestimmten Ausführungsformen können spezielle Komponenten der VACS abhängig von der speziellen Implementierung des Systems spezielle Teile eines Prozesses durchführen. Als Beispiel und nicht als Beschränkung ist es wahrscheinlich, dass, falls ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einem gepaarten kabellosen Gerät aufweist, das kabellose Gerät diesen Teil des Prozesses nicht durchführt, da das kabellose Gerät keine Informationen mit sich selbst „senden und empfangen” würde. Ein Fachmann versteht, wann es unangebracht ist, ein spezielles Datenverarbeitungssystem für eine gegebene Lösung anzuwenden.
  • Bei jeder der hier besprochenen beispielhaften Ausführungsformen ist ein beispielhaftes, nichtbeschränkendes Beispiel eines Prozesses, der von einem Datenverarbeitungssystem durchführbar ist, gezeigt. Im Hinblick auf jeden Prozess ist es möglich, dass das den Prozess ausführende Datenverarbeitungssystem für den beschränkten Zweck des Ausführens des Prozesses als ein Prozessor für einen besonderen Zweck ausgelegt wird, um den Prozess durchzuführen. Nicht alle Prozesse müssen vollständig durchgeführt werden und es versteht sich, dass sie Beispiele für Arten von Prozessen sind, die durchgeführt werden können, um Elemente der Erfindung zu erreichen. Zusätzliche Schritte können den beispielhaften Prozessen wie gewünscht hinzugefügt oder aus diesen entfernt werden.
  • Im Hinblick auf die beispielhaften Ausführungsformen, die in den Figuren, die beispielhafte Prozessflüsse zeigen, beschrieben sind, ist anzumerken, dass zum Zweck des Ausführens eines oder aller der von diesen Figuren gezeigten beispielhaften Verfahren ein Prozessor für allgemeine Zwecke zeitweise als ein Prozessor für einen besonderen Zweck aktiviert sein kann. Wenn Code ausgeführt wird, der Anweisungen bereitstellt, einige oder alle Schritte des Verfahrens durchzuführen, kann der Prozessor zeitweise zu einem Prozessor für einen besonderen Zweck umfunktioniert werden, bis das Verfahren abgeschlossen ist. Bei einem weiteren Beispiel kann in einem angebrachten Maße Firmware, die gemäß einem vorkonfigurierten Prozessor agiert, bewirken, dass der Prozessor als ein Prozessor für einen besonderen Zweck, der zum Zweck des Durchführens des Verfahrens oder einer vernünftigen Variation desselben bereitgestellt ist, agiert.
  • In Notfallsituationen wie beispielsweise Unfällen ist es wünschenswert, so viele nützliche Informationen wie möglich an eine Notrufzentrale oder Ersthelfer zu übertragen. Dies kann Fahrzeugzustände (Brand, Umkippen etc.), Unfalleigenschaften (Front, Kollisionsgeschwindigkeit, seitliche Kollision) und die Position des Fahrzeugs beinhalten. Je mehr Informationen Notrufzentralen haben oder anfordern können, desto präziser kann eine Notfallreaktion ausfallen. Zum Beispiel kann das Wissen, dass ein Fahrzeug entweder brennt oder ein erhöhtes Brandrisiko aufweist, bewirken, dass die Notrufzentrale sowohl ein Feuerwehrfahrzeug als auch ein Polizeifahrzeug sendet. Das Warten, bis das Polizeifahrzeug eingetroffen ist, ehe derartige Dienste angefordert werden, kann zu einer größeren Verletzung oder einem größeren Schaden für Insassen und die Umgebung führen.
  • Bei den vorgestellten beispielhaften Ausführungsformen sendet ein entfernter Server erweiterte Informationen über Fahrzeuginsassen, wenn ein Unfall geschieht. Ein Mobilgerät oder Fahrzeug speichert diese Informationen zunächst und der Server ruft die Informationen beim Hochfahren, wenn ein Unfall geschieht oder zu einem anderen geeigneten Zeitpunkt ab. Das Fahrzeug benachrichtigt den Server (oder ein System, das mit dem Server zusammenarbeitet) über den Unfall und der Server kann agieren, um die gespeicherten passagierspezifischen Informationen mittels Festnetz- oder Internetverbindung an die Notrufzentrale zu senden. Zwar könnte das Fahrzeug oder ein Mobilgerät diese Informationen auch senden, falls die Notrufzentrale unter Nutzung einer Sprachverbindung nur mit dem Fahrzeug direkt kommunizieren kann, das Vermögen des Servers, zusätzliche Informationen über die Fahrzeuginsassen zu senden, kann jedoch eine nützliche Ergänzung zum Sprachanruf bereitstellen.
  • Einige Fahrzeuge sind mit der Fähigkeit versehen, Fahrzeuginsassen sowohl durch ihre Position als auch ihre spezifische Identität zu erkennen. Diese Erkennungssysteme können Fahrzeugkameras mit visuellem Identifikationsvermögen, kabellose Geräteerfassungstechnologie, die fähig ist, eine Geräteposition durch Triangulation zu bestimmen und einen bekannten Nutzer als an dieser Position befindlich zuzuordnen, und andere ähnliche Systeme beinhalten. Falls ein Fahrzeug oder Fahrzeugsystem einen Nutzer spezifisch identifizieren kann, kann das Fahrzeug diesen Nutzer entweder für einen entfernten Server für die Abrufung nutzerbezogener Informationen identifizieren oder kann lokal gespeicherte Nutzerinformationen an den entfernten Server übermitteln. Außerdem speichern bei einigen Beispielen kabellose Nutzergeräte ein Nutzerinformationenprofil, das die medizinische Vorgeschichte beinhalten kann. Das Fahrzeug kann auf dieses Profil zugreifen und die relevanten Informationen auf den Server hochladen. Alle diese Systeme können dazu dienen, Fahrzeuginsassen zu identifizieren und zumindest einen vorläufigen Notfalldatensatz, der Fahrzeuginsassen betrifft, anzulegen. Der Server kann dann einige oder alle Daten in diesem Datensatz an eine Notrufzentrale senden, falls ein Unfall geschieht.
  • 2 stellt ein Beispiel für einen Passagieridentifikationsprozess dar. In diesem beispielhaften Beispiel verwendet der Prozess ein oder mehr Identifikationssubsysteme, mit denen das Fahrzeug versehen ist, um spezifische Passagierpositionen und/oder -identitäten zu identifizieren. Diese Systeme können, ohne darauf beschränkt zu sein, Folgendes umfassen:
    Sichtsysteme – bestimmte Kameras können sowohl Insassenposition als auch – identitäten zuvor gesehener oder bekannter Insassen identifizieren. Die Identifikation kann lokal oder durch ein Cloud-basiertes System, auf das das Fahrzeug Innenraumbilder hochlädt, erfolgen.
    Kabellose Geräteidentifikationssysteme – Fahrzeuge können mit einem oder mehreren kabellosen Sendeempfängern versehen sein, die es dem Fahrzeug erlauben, Geräte auf Grundlage der Signalstärke zu lokalisieren. Diese Systeme können auch in der Lage sein, spezifische Geräte durch eine in Gerätesignalen enthaltene Identifikation zu identifizieren. Falls bekannt ist, dass ein Gerät nur einen einzelnen oder üblichen Nutzer hat, kann das Identifizieren eines Geräts und/oder einer Geräteposition die Nutzer- und/oder Nutzerpositionsidentifikation erleichtern.
    Sitzsensoren – Fahrzeuggewichtssensoren können die Nutzung oder zumindest die Tatsache, dass sich an einer Sitzposition ein merkliches Gewicht befindet, identifizieren. Die Insassenidentität kann auf Grundlage spezifischer Insassengewichte, die zuvor für übliche Insassen festgestellt wurden, ermittelt werden. Diese gewichtsbasierten Informationen können auch mit einer zusätzlichen Quelle gekoppelt werden, um die Identifikationsgenauigkeit und -verlässlichkeit zu verbessern (z. B. ein Gerät weist zwei bekannte Nutzer auf, von denen einer etwa 120 Pfund wiegt und einer etwa 200 Pfund wiegt – falls das Gerät an einer Sitzposition erkannt wird, an der etwa 200 Pfund erkannt werden, kann angenommen werden, dass sich der schwerere Nutzer an dieser Position befindet).
    Biometrik – ein oder mehr biometrische Lesegeräte können in Fahrzeugsitzen, Armlehnen, Zündungssystemen etc. enthalten sein. Die Nutzung eines lokalisierten biometrischen Lesegeräts durch einen Insassen kann einen Insassen an einer Sitzposition, die dem lokalisierten biometrischen System zugeordnet ist, identifizieren.
  • Bei dem Beispiel von 2 identifiziert, sobald die Fahrt begonnen hat 201, der Prozess so viele Fahrzeuginsassen wie möglich 203. Der Prozess kann iterativ sein und unterschiedliche Insassen innerhalb des Fahrzeugs unter Nutzung unterschiedlicher Methodologien identifizieren. Das Fahrzeug kann, wie allgemein oben beschrieben, ein oder mehr Systeme und Strategien allein oder in Kombination nutzen, um so viele Insassen wie möglich spezifisch zu identifizieren. Das Fahrzeug kann die Identifikation eines Insassen anfordern 207, der anders nicht identifiziert werden kann 205. Dies kann durch Interaktion mit einer Mensch-Maschine-Schnittstelle (HMI – Human Machine Interface) oder auf eine andere für die Eingabe einer Insassenidentifikation geeignete Art geschehen.
  • Sobald das Fahrzeug alle Insassen spezifisch identifiziert oder zu identifizieren versucht hat, sendet das Fahrzeug die Insassenposition/-identifikation an einen entfernten Server 209. Bei einigen Beispielen können ein oder mehr Insassengeräte insassenbezogene medizinische Informationen speichern, die das Fahrzeug durch Anfordern der Informationen vom Gerät erhalten kann. Bei anderen Beispielen kann das Fahrzeug diese Informationen zusammen mit einem zuvor erstellten Nutzerprofil speichern. Falls das Fahrzeug Zugriff auf relevante medizinische Informationen hat, kann das Fahrzeug diese Informationen auch zum Server senden. Bei einem weiteren Beispiel kann der Server die aktuellsten medizinischen Informationen des Fahrers zusammen mit den zuvor vom Fahrer an den Server gesendeten Fahrzeugdaten aufbewahren, möglicherweise unter Nutzung weitere Mittel wie beispielsweise mittels der TAE oder zum Beispiel eines Webportals. Bei einem weiteren Beispiel kann das Fahrzeug das Gerät anweisen, die Insassen-/Geräteidentifikation und medizinische Insasseninformationen an den entfernten Server zu senden. Bei dem in 2 dargestellten Beispiel speichert jedoch das Fahrzeug die relevanten medizinischen Informationen über einige oder alle Insassen 211. Somit kann das Fahrzeug diese Informationen auf gegenwärtigen oder zukünftigen Reisen mit einem oder mehreren derselben Insassen nutzen.
  • 3 stellt ein Beispiel für einen Notfallereignisabwicklungsprozess dar. Falls ein Unfall oder ein anderen Notfallereignis geschieht 301, ruft das Fahrzeug (oder ein anderes den Prozess ausführendes Gerät) eine Notrufzentrale, auch bekannt als ein öffentlicher Sicherheitsantwortpunkt (PSAP – public safety answering point; Notrufzentrale) an. Dies erlaubt eine zügige Erstkommunikation mit dem PSAP. In einigen Fällen kann der PSAP sowohl Sprache als auch Daten mit dem Fahrzeug kommunizieren und das Fahrzeug kann lokal gespeicherte medizinische Insassendaten nutzen, um den PSAP direkt über den Gesundheitszustand der Insassen zu informieren. Außerdem können bei diesem Beispiel die Fahrzeugkameras und -sensoren unfallbezogene Daten 305 sammeln, wenn der Unfall geschieht.
  • Bei dem in 3 dargestellten Beispiel sendet das Fahrzeug fahrzeugbezogene Unfalldaten (Kamerabilder, Sensordaten, Positionsdaten, weitere am Unfallort gesammelte Daten) an den Backend-Cloud-Server 307. Zu diesem Zeitpunkt kann das Fahrzeug auch medizinische Insasseninformationen an den Backend-Server übertragen, falls das Fahrzeug diese Informationen noch nicht gesendet hat und/oder falls der Backend-Server diese Informationen nicht auf eine andere Weise erhalten kann (beispielsweise aus entfernt gespeicherten Profilen). Während die Datenübertragung stattfindet oder sobald die Datenübertragung abgeschlossen ist, kann das Fahrzeug auch ein Auslösesignal (oder Unfallindizien) an den Backend-Server senden, um die unfallbezogenen Daten (medizinisch, fahrzeugbezogen etc.) an den PSAP zu übertragen 309. Als Reaktion auf dieses Signal kann der Server die unfallbezogenen Daten an den PSAP übertragen. Das Fahrzeug kann einen PSAP auf Grundlage eines an den Backend-Server gesendeten Signals explizit identifizieren oder der Backend-Server kann empfangene Fahrzeugpositionsdaten oder andere Informationen nutzen, um einen speziellen PSAP zu identifizieren.
  • Es kann zum Zeitpunkt des Unfalls unklar sein, ob ein spezieller PSAP Daten direkt von einem Fahrzeug empfangen kann. Durch Senden der Daten an den entfernten Server erreicht der Prozess zumindest eine Redundanz für die Datenübertragung. Der entfernte Server kann genutzt werden, um die Daten zu senden, da er schneller ist, da über den Sprach- oder einen weiteren Datenkanal weitere Daten zwischen dem Fahrzeug und dem PSAP übertragen werden, da der entfernte Server Zugriff auf mehr sekundäre Informationen hat etc. Die beispielhaften Ausführungsformen stellen zwar durch das Senden von Unfall- und/oder Insassendaten an den entfernten Server für die nachfolgende Weiterleitung an den PSAP ein Maß an Redundanz bereit, es kann jedoch verschiedene Gründe geben, warum es angebracht ist, den Backend-Server zu nutzen, um ebenfalls unfall- und insassenbezogene Daten an den PSAP zu übertragen.
  • 4A stellt ein Beispiel für einen Profilerfassungsprozess dar. Bei dem beispielhaften Beispiel legt das Fahrzeug ein medizinisches Insassenprofil zur Speicherung an. Das Fahrzeug kann dieses Profil zu einem späteren Zeitpunkt immer dann nutzen, wenn das Fahrzeug die speziellen Insassen als anwesend identifiziert. Das Fahrzeug kann diese Informationen auch auf einen Backend-Server hochladen und/oder diese Informationen nach dem Hochladen löschen, falls eine Profilspeicherung nur an einem entfernten Ort angebracht ist.
  • Zunächst empfängt das Fahrzeug Insassen identifizierende Daten 401. Diese können zum Beispiel Geräteidentifikationsdaten, Insassenname, Insassengewicht, biometrische Insassendaten etc. beinhalten. Falls diese Daten wiederholt erkennbar sind, kann das Fahrzeug dieselben Daten zu einem zukünftigen Zeitpunkt erkennen und die Daten nutzen, um den Insassen zu identifizieren. Es ist nicht notwendig, einen Insassennamen zu kennen, da das Fahrzeug alle Daten, die den Insassen eindeutig identifizieren oder beim eindeutigen Identifizieren des Insassen helfen können, nutzen kann.
  • Das Fahrzeug erstellt auf Grundlage der identifizierenden Daten ein Profil für den Insassen 403. Dieses Profil kann lokal, auf einem Mobilgerät für späteren Fahrzeugzugriff und/oder in der Cloud gespeichert sein. Sobald es erstellt ist, erhält das Fahrzeug auch alle relevanten Daten mit medizinischem Bezug 405, die den Insassen betreffen. Ein Nutzer kann diese Informationen in das Fahrzeug eingeben (zum Beispiel unter Nutzung einer HMI). Bei weiteren Beispielen kann ein Mobilgerät diese Informationen zunächst speichern und das Fahrzeug kann die Informationen durch Anforderung vom Mobilgerät erhalten. Das Fahrzeug ordnet die medizinischen Informationen dem Profil für die gegenwärtige und zukünftige Nutzung zu. Bei einigen Beispielen, besonders falls die gespeicherten Informationen auf einen nichtpersistenten Zustand (z. B. Schwangerschaft) hinweisen, kann das Fahrzeug die Informationen nur für die Dauer einer Reise speichern und das Profil neu anlegen, wenn neue Reisen stattfinden. Bei einigen Beispielen kann das Fahrzeug einige Informationen persistent speichern (z. B. Diabetiker) und einige Informationen vorübergehend (z. B. Grippe).
  • Außerdem fragt bei diesem Beispiel das Fahrzeug von einem Mobilgerät (oder einer lokalen fahrzeuginternen Kontaktdatenbank) dem Nutzer zugeordnete Notfallkontakte ab. Dieses Fahrzeug kann diese Kontakte auch im Hinblick auf das Nutzerprofil speichern 407.
  • 4B stellt ein Beispiel für einen Datensammlungs- und -zustellungsprozess dar. Bei diesem Beispiel sendet ein auf dem entfernten Server ausgeführter Prozess relevante Notfalldaten an einen PSAP, von dem bekannt oder zu erwarten ist, dass dies der vom Fahrzeug kontaktierte PSAP ist. Wenn ein Unfall geschieht, kann das Fahrzeug einen Auslöser an den entfernten Server senden, um die Übertragung von Informationen an den PSAP anzufordern. Bei diesem Beispiel beginnt der Prozess, wenn der Server den Auslöser vom Fahrzeug empfängt 411.
  • Sobald der Auslöser empfangen wurde, ermittelt der Server, ob für das spezielle Fahrzeug ein Insassenprofil existiert 413. Dies beinhaltet zum Beispiel einige oder alle Insassen, die als im Fahrzeug befindlich identifiziert wurden, sowie alle relevanten oder erhältlichen medizinischen Informationen, die die identifizierten Insassen betreffen. Es ist auch möglich, dass medizinische Daten, die Insassen betreffen, möglicherweise keinem spezifischen Insassen zugeordnet sind. Zum Beispiel kann der Server über Informationen verfügen, dass eine der Insassinnen schwanger ist, ohne dass eine spezifische Insassenidentifikation erstellt ist.
  • Falls der Server und das Fahrzeug nicht bereits ein Profil für die Insassen erstellt haben 413, fordert der Prozess medizinische Daten vom Fahrzeug an 415. Es ist zwar häufig wünschenswert, diese Daten während des normalen Fahrzeugbetriebs weit vor einem Unfall zu übertragen, jedoch können Kommunikationsprobleme oder andere Fehler verhindert haben, dass die Daten vorher übertragen wurden, sodass für einen oder mehrere Insassen noch kein Profil erstellt wurde. Zusätzlich oder alternativ dazu kann die Auslöseanforderung selbst Teil eines größeren Datenpakets sein, das relevante medizinische Insasseninformationen enthält.
  • Der Server sendet die erhaltenen relevanten medizinischen Daten an den PSAP 417. Das Fahrzeug kann den PSAP explizit als Teil der Auslöseanforderung identifizieren oder der Server kann auf Grundlage einer bekannten Fahrzeugposition einen wahrscheinlichen PSAP bestimmen. Typischerweise wird ein einzelner PSAP zugewiesen, um eine spezielle geografische Region abzudecken, sodass der Server die Identität des zugeordneten PSAP und die Kontaktinformationen auf Grundlage der Fahrzeugposition ermitteln kann.
  • Bei dem Beispiel von 4B ermittelt der Server, ob es Notfallkontaktinformationen, die einem oder mehreren der Insassen zugeordnet sind, gibt 419. Falls auf dem Server keine Notfallkontaktinformationen gespeichert sind, kann der Server versuchen, diese Informationen durch eine Anforderung an das Fahrzeug zu erhalten 421. Sobald der Server Notfallkontaktinformationen erhalten hat (sofern verfügbar), sendet der Server eine Mitteilung an die Notfallkontakte 423. Dies kann zum Beispiel das Senden einer Textnachricht, das Senden einer E-Mail, das Senden einer Sprachnachricht etc. beinhalten. Da das Fahrzeug sich zu diesem Zeitpunkt wahrscheinlich gerade in einem Telefonanruf mit dem PSAP befindet, kann die Nachricht auch eine Erinnerung beinhalten, dass der Fahrzeuginsasse möglicherweise derart beschäftigt und nicht verfügbar ist, um auf Nachrichten zu antworten. Die Nachricht an den Notfallkontakt kann auch weitere unfallbezogene Informationen enthalten, was für einen Freund oder ein Familienmitglied eine Gelegenheit bieten kann, zum Unfallort (oder einem Krankenhaus) zu eilen.
  • Der Server kann außerdem ermitteln, ob ein oder mehrere unfallbezogene Kamera- oder Sensorbilder empfangen wurden 425. Falls der Server keine Kamera-/Sensordaten empfangen hat, kann der Prozess die Daten vom Fahrzeug anfordern 427. Das Fahrzeug kann diese Daten anfangs als Reaktion auf die Auslöseanforderung senden. Falls auf dem Server bereits die relevanten Kamera-/Sensordaten gespeichert sind oder sobald der Server die Daten als Antwort auf die Anforderung empfängt 429, sendet der Prozess die Kamera- und/oder Sensorbilder an den PSAP 431.
  • 5 stellt ein Beispiel für einen weiteren Datensammlungsprozess dar. Dieser beispielhafte Prozess ist ein detaillierteres Beispiel für das anfängliche Datensammeln, das das Fahrzeug zum Erstellen von Profilen mit medizinischen Informationen für auf Grundlage erkannter Geräte erkannte Insassen durchführen kann. Bei diesem Beispiel erkennt das Fahrzeug ein oder mehrere Geräte 501. Diese Geräte können, ohne darauf beschränkt zu sein, Smartphones, Wearables, Tablets, medizinische Geräte etc. beinhalten. Viele Wearables, insbesondere medizinische Geräte, können einige insassenspezifische Zustandsinformationen und/oder biometrische Maße enthalten. Das Fahrzeug kann einige oder alle dieser Daten zur Nutzung beim Erstellen detaillierter Profile mit medizinischen Informationen von Insassen zur Nutzung im Melden erweiterter Zusammenstoßinformationen sammeln.
  • Das Fahrzeug wählt eines der erkannten Geräte aus 503 und ermittelt, ob ein dem Gerät zugeordneter Insasse bekannt ist 505. Falls der Insasse bekannt ist, sammelt das Fahrzeug lokal gespeicherte Daten, die den Insassen betreffen 511. Da Insassenprofile lokal bestehen, kann das Fahrzeug bei zumindest einem Beispiel zur Nutzung beim Anlegen von Profilen mit medizinischen Informationen für erkannte Insassen auf diese Profile zugreifen. Das Fahrzeug kann sich auch mit dem Gerät verbinden 513 und gerätespezifische Daten vom Gerät sammeln 515. Dies kann auf dem Gerät gespeicherte zusätzliche medizinische Informationen, vom Gerät gesammelte Biofeedback-Informationen, auf dem Gerät gespeicherte Notfallkontaktinformationen, vom Gerät gespeicherte Arztinformationen etc. beinhalten. Der Prozess wiederholt sich für jedes zusätzliche Gerät 517 und das Fahrzeug sendet die gesammelten Profil- und Geräteinformationen zur Nutzung/Speicherung an den Backend-Server 519.
  • Falls der dem Gerät zugeordnete Insasse unbekannt ist und/oder das Gerät nicht erkannt wird, versucht das Fahrzeug, sich mit dem Gerät zu verbinden 507. Falls das Fahrzeug fähig ist, mit dem Gerät zu kommunizieren, kann das Fahrzeug spezifische Informationen vom Gerät anfordern. Dies kann Eigentümeridentifikationsdaten, auf dem Gerät gespeicherte medizinische Daten, Biofeedback-Daten, Arztdaten etc. beinhalten. Der Datensammlungsprozess sowohl für bekannte als auch für unbekannte Geräte kann auch das Anfordern von Informationen direkt von Fahrzeuginsassen durch Fahrzeugschnittstellen beinhalten. Das Fahrzeug kann durch Nutzereingaben Insassenidentitäten, den Gesundheitszustand und weitere nützliche Informationen sammeln. Alle diese Informationen können kombiniert werden, um ein medizinisches Versorgungsprofil für Insassen zu bilden, falls ein Unfall geschieht. Das Fahrzeug kann nachfolgend diese Informationen zur Nutzung und Lang- und/oder Kurzzeitspeicherung an den entfernten Server übertragen.
  • Durch die Nutzung der beispielhaften Ausführungsformen und ähnlicher Strategien können zusätzliche medizinische Informationen an einen PSAP weitergeleitet werden, wenn ein Unfall geschieht. Durch das Bereitstellen eines Backend-Servers mit Datenübertragungsfähigkeit kann der PSAP relevante Informationen erhalten, selbst wenn eine direkte Datenkommunikation mit dem Fahrzeug nicht möglich ist.
  • Obwohl vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Patentbeschreibung verwendeten Worte eher Worte zur Beschreibung als zur Begrenzung und selbstverständlich können verschiedene Änderungen vorgenommen werden, ohne vom Gedanken und Schutzbereich der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener implementierter Ausführungsformen auf logische Arten kombiniert werden, um situationsbezogen geeignete Variationen von hier beschriebenen Ausführungsformen zu erzeugen.
  • 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 Nicht-Patentliteratur
    • IEEE-802-PAN-Protokolle [0022]
    • IEEE-802-LAN-Protokolle [0022]
    • IEEE 802 PAN [0022]
    • IEEE 1394 [0025]
    • IEEE 1284 [0025]
    • IEEE-802. 11 [0027]

Claims (16)

  1. System, das Folgendes umfasst: einen Prozessor, der dazu ausgelegt ist: als Reaktion auf das Erkennen eines Fahrzeugunfalls kabellos eine Anweisung an einen entfernten Server zu senden, medizinische Daten von Fahrzeuginsassen an einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale) zu übertragen.
  2. System nach Anspruch 1, wobei der Prozessor dazu ausgelegt ist: eine Identität und Position innerhalb eines Fahrzeugs eines Fahrzeuginsassen zu ermitteln; medizinische Daten, die einen identifizierten Fahrzeuginsassen betreffen, zu erhalten; und die Insassenidentifikation und die erhaltenen betreffenden medizinischen Daten an den entfernten Server zu senden.
  3. System nach Anspruch 2, wobei der Prozessor dazu ausgelegt ist, medizinische Daten durch Zugreifen auf zuvor gespeicherte medizinische Daten, die den identifizierten Fahrzeuginsassen betreffen, zu erhalten.
  4. System nach Anspruch 2, wobei der Prozessor dazu ausgelegt ist, medizinische Daten durch Anfordern medizinischer Daten von einem identifizierten Gerät, das dem Fahrzeuginsassen zugeordnet ist, zu erhalten.
  5. System nach Anspruch 1, wobei der Prozessor dazu ausgelegt ist: als Reaktion auf das Erkennen des Fahrzeugunfalls fahrzeugbezogene Unfalldaten zu erhalten; und die fahrzeugbezogenen Unfalldaten der Anweisung beizufügen, wobei die Anweisung ferner eine Anweisung, die fahrzeugbezogenen Unfalldaten an den PSAP zu übertragen, umfasst.
  6. System nach Anspruch 5, wobei die fahrzeugbezogenen Unfalldaten ein Kamerabild eines Fahrzeuginnenraums beinhalten.
  7. System nach Anspruch 5, wobei die fahrzeugbezogenen Unfalldaten Fahrzeugsensordaten beinhalten.
  8. System, das Folgendes umfasst: einen Prozessor, der dazu ausgelegt ist: kabellos Unfallindizien von einem Fahrzeug zu empfangen; auf ein Insassenprofil mit medizinischen Daten, die einen Insassen des Fahrzeugs betreffen, zuzugreifen; einen öffentlichen Sicherheitantwortpunkt (PSAP – public safety answering point; Notrufzentrale) zu identifizieren; und die medizinischen Daten als Reaktion auf die Unfallindizien an den identifizierten PSAP zu senden.
  9. System nach Anspruch 8, wobei der Prozessor dazu ausgelegt ist, die medizinischen Daten vom Fahrzeug zu empfangen und die medizinischen Daten im Hinblick auf das Insassenprofil zu speichern.
  10. System nach Anspruch 8, wobei der Prozessor dazu ausgelegt ist, die den Unfallindizien beigefügten medizinischen Daten zu empfangen.
  11. System nach Anspruch 8, wobei der Prozessor dazu ausgelegt ist, den Unfallindizien beigefügte fahrzeugbezogene Unfalldaten zu empfangen.
  12. System nach Anspruch 11, wobei der Prozessor dazu ausgelegt ist, die fahrzeugbezogenen Unfalldaten an den identifizierten PSAP zu senden.
  13. System nach Anspruch 12, wobei die fahrzeugbezogenen Unfalldaten Fahrzeugkamerabilder beinhalten.
  14. System nach Anspruch 12, wobei die fahrzeugbezogenen Unfalldaten Fahrzeugsensormesswerte beinhalten.
  15. System nach Anspruch 8, wobei der Prozessor dazu ausgelegt ist, den PSAP auf Grundlage einer den Unfallindizien beigefügten Fahrzeugposition zu identifizieren.
  16. System nach Anspruch 8, wobei der Prozessor dazu ausgelegt ist, den PSAP auf Grundlage einer den Unfallindizien beigefügten PSAP-Identifikation zu identifizieren.
DE102017113121.3A 2016-06-16 2017-06-14 Verfahren und Einrichtung für die automatische Übertragung medizinischer Daten Withdrawn DE102017113121A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/184,312 US20170365106A1 (en) 2016-06-16 2016-06-16 Method and apparatus for automatic transmission of medical data
US15/184,312 2016-06-16

Publications (1)

Publication Number Publication Date
DE102017113121A1 true DE102017113121A1 (de) 2017-12-21

Family

ID=60481204

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017113121.3A Withdrawn DE102017113121A1 (de) 2016-06-16 2017-06-14 Verfahren und Einrichtung für die automatische Übertragung medizinischer Daten

Country Status (3)

Country Link
US (1) US20170365106A1 (de)
CN (1) CN107526916A (de)
DE (1) DE102017113121A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021200801A1 (de) 2021-01-29 2022-08-04 Zf Friedrichshafen Ag Fahrzeugmodul zur Bereitstellung von Informationen und Steuergerät, Fahrzeugvorrichtung

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018127365A1 (de) 2018-04-03 2019-10-10 Allianz Partners Sas Niederlassung Deutschland Verfahren zum Unterstützen einer fernmündlichen Kommunikation zwischen einem Benutzer eines Telekommunikationsendgeräts und einer Dienstleistungsstelle sowie Telekommunikationsendgerät und computerlesbares Speichermedium
US10706302B2 (en) * 2018-06-01 2020-07-07 Volvo Car Corporation Real time vehicle occupant emergency health data systems and methods
EP3598396A1 (de) * 2018-07-20 2020-01-22 Rothenbühler, Rudolf Computergestütztes verfahren zum analysieren personenbezogener unfalldaten
GB2583347A (en) * 2019-02-24 2020-10-28 Continental Automotive Gmbh An information processing system for vehicle and a method for processing information for vehicle
US20220153218A1 (en) * 2020-11-16 2022-05-19 Panasonic Automotive Systems Company Of America, Division Of Panasonic Corporation Of North America Car assistance system to activate dispatch and relay medical information
GB2619739A (en) * 2022-06-15 2023-12-20 Continental Automotive Tech Gmbh Method and system for determining and providing information about occupants of a vehicle

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020103622A1 (en) * 2000-07-17 2002-08-01 Burge John R. Decision-aid system based on wirelessly-transmitted vehicle crash sensor information
US8681782B2 (en) * 2005-02-22 2014-03-25 Sprint Spectrum L.P. Method and system for routing a voice-over-packet emergency services call to an appropriate public safety answering point (PSAP)
US20090168974A1 (en) * 2007-12-26 2009-07-02 General Motors Corporation Vehicle emergency call handling and routing to psaps
US8749350B2 (en) * 2010-12-10 2014-06-10 General Motors Llc Method of processing vehicle crash data
US9399430B2 (en) * 2014-12-02 2016-07-26 Honda Motor Co., Ltd. System and method for vehicle control integrating health priority alerts of vehicle occupants
US9522598B2 (en) * 2015-04-16 2016-12-20 Verizon Patent And Licensing Inc. Vehicle occupant emergency system

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
IEEE 1284
IEEE 1394
IEEE 802 PAN
IEEE-802. 11
IEEE-802-LAN-Protokolle
IEEE-802-PAN-Protokolle

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021200801A1 (de) 2021-01-29 2022-08-04 Zf Friedrichshafen Ag Fahrzeugmodul zur Bereitstellung von Informationen und Steuergerät, Fahrzeugvorrichtung

Also Published As

Publication number Publication date
US20170365106A1 (en) 2017-12-21
CN107526916A (zh) 2017-12-29

Similar Documents

Publication Publication Date Title
DE102017113121A1 (de) Verfahren und Einrichtung für die automatische Übertragung medizinischer Daten
DE102014221527B4 (de) Verfahren und Vorrichtung zur visuellen Unfalldetailberichterstattung
EP3555874B1 (de) Vorrichtung, verfahren und computerprogramm für ein fahrzeug zum bereitstellen einer unfallmeldung über einen unfall an eine notrufstelle
DE102017113260A1 (de) Verfahren und vorrichtung zur sicherheitswahrnehmung und warnung zwischen fahrzeugen
DE102015113644A1 (de) Vorrichtung und system zum erzeugen von fahrzeugnotfallaufzeichnungsdaten
DE102020106567B4 (de) Erkennung von fahrzeuginsassen
DE102017123406A1 (de) Telematikbasierte fahrzeugwertberichte
DE102019103819A1 (de) Überwachen der versorgungsqualität am fahrzeug
DE102015107503A1 (de) Verfahren und System zum Starten einer Anwendung
DE102018107755A1 (de) Fahrzeugereigniserkennung und -klassifizierung mithilfe von kontextbezogenen fahrzeugdaten
DE102015107505A1 (de) Verfahren und System zum Starten einer Anwendung
DE102019113707A1 (de) Fernkonfiguration einer fahrzeugelektronik
DE102016105400A1 (de) Verfahren und systeme zur konfiguration eines fahrzeugmerkmals
DE102015208856A1 (de) Verfahren und System für ein Fahrzeugrechensystem, das zu einer Social Media Website kommuniziert
DE102018106548A1 (de) Unfallerfassung unter verwendung von gnss-geschwindigkeitsmessungen und busüberwachung
DE102015215294A1 (de) Bereitstellen von Hilfsmitteln nach einem Fahrzeugunfall
DE102016121893A1 (de) Verfahren und Vorrichtung für Warnungen über interne/externe Fahrzeugumgebung
DE102015103999A1 (de) Belastungsschätzung für Mobilgerät-Funktionsintegration
DE102014118953A1 (de) Verfahren und System für eine Haupteinheit zum Empfangen einer Anwendung
DE102014103790A1 (de) Notfallmitteilungssystem
DE102015207199A1 (de) Verfahren und vorrichtung für fahrzeug-zu-fahrzeug kommmunikation und informationsweiterleitung
DE102019115033A1 (de) Benutzerdefinierte kraftfahrzeugbenachrichtigung
DE102021122366A1 (de) Fahrzeug mit automatischer unfallberichtsfunktion und servervorrichtung
DE102015109295A1 (de) Fahrergeräteerkennung
DE112016004849T5 (de) Begrenzung einer Ablenkung durch in einem Fahrzeug befindliche tragbare Geräte

Legal Events

Date Code Title Description
R083 Amendment of/additions to inventor(s)
R082 Change of representative

Representative=s name: LORENZ SEIDLER GOSSEL RECHTSANWAELTE PATENTANW, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee