Collection and provision of patient data

Abstract

Computer-implemented method comprising the following: Determine, via a vehicle computing system (VCS), a user account associated with a vehicle occupant; Detect, via the VCS, the presence of at least one active surveillance device; Determine, via the VCS, an association between the active monitoring device and the user account; Periodic downloading of setup information from the active monitoring device to the VCS; Saving downloaded setup information in association with the user account; Receiving a request from a medical service provider to provide recorded facility information; Notifying a vehicle occupant of the request; and Sending the requested facility information to the service provider in response to the vehicle occupant's approval of the request.

Description

[0001] The invention relates to a method for a vehicle data system for recording patient data and for making it available.

[0002] Maintaining accurate records of medical documents and patient health data is often difficult. Patients may visit numerous doctors and frequently neglect to record data they need to keep track of. Furthermore, patients may fail to do so due to the associated effort and time constraints, or simply may not be realistically able to keep track of certain data that could otherwise be helpful for diagnosis and medical care.

[0003] For example, a patient with high blood pressure or a stress-related illness may be required to periodically monitor their blood pressure or heart rate. Since many people's daily lives are filled with numerous activities, it can be difficult or nearly impossible for a patient to monitor this data with the recommended frequency. Even if the patient does take the measurements, they may fail to record all the data accurately. Finally, there is also the possibility that the patient will forget to bring some or all of the data to their doctor's appointment.

[0004] Solutions like Microsoft HealthcareVault and Google Health address some of the challenges associated with tracking patient data. These voluntary data management services allow users to consolidate their patient data into a single, accessible source. Data from various doctors, pharmacies, dentists, opticians, and other healthcare providers can all be combined in one place.

[0005] Furthermore, some of these services offer additional connectivity options for medical monitoring devices. HEALTHVAULT, for example, can store data from heart rate monitors (HRMs), blood pressure monitors (BPMs), wireless scales, and more. Other wireless devices may also be able to connect to HEALTHVAULT.

[0006] In an environment where wireless sensors send collected information to a service like HEALTHVAULT, these sensors typically require a local network over which to transmit the data. While such networks may be readily available at the user's home, locating an accessible network can be challenging when the user is away from home. Furthermore, if the user is not carrying or using a sensor at a particular time, the data simply cannot be measured or recorded.

[0007] In addition to health monitoring devices, various sports and wellness facilities can record data related to physical activity. This data can then be transmitted to a remote location or computer for analysis and tracking, for example, via a wireless home network.

[0008] In a first intuitive embodiment, a computer-implemented method includes determining, via a vehicle computing system (VCS), a user account associated with a vehicle occupant. The intuitive method further includes detecting, via the VCS, the presence of at least one active monitoring device. The intuitive method further includes determining, via the VCS, an association between the active monitoring device and the user account and periodically downloading device information from the active monitoring device to the VCS. Finally, the intuitive method includes storing the downloaded device information in association with the user account.

[0009] In a second illustrative embodiment, a vehicle computing apparatus (VCA) includes determining program logic circuits for identifying a user account associated with a wireless device located in a vehicle, wherein the wireless device corresponds to a user for whom the user account has been set up. The illustrative apparatus further includes detecting program logic circuits for detecting the presence of at least one active monitoring device.

[0010] This illustrative device also includes determining program logic circuits for establishing an association between the active monitoring device and the user account, and downloading program logic circuits for periodically downloading facility information from the active monitoring device to the VCA. This illustrative device also includes storing program logic circuits for storing downloaded facility information in association with the user account, and accessing program logic circuits for accessing a remote user patient profile to download user patient information.

[0011] State of the art: US 2008 / 0 297 336 A1

[0012] The illustrative device also includes updating program logic circuits for updating the user account with the downloaded user-patient information. Finally, the illustrative device also includes uploading program logic circuits for uploading downloaded setup information to the remote user-patient profile.

[0013] In a third illustrative embodiment, a computer-readable storage medium stores instructions which, when executed, cause a vehicle computer system to perform the following procedure: determining a user account associated with a wireless device present in a vehicle, wherein the wireless device corresponds to a user for whom the user account has been set up. The vehicle computer system is also caused to perform the steps of detecting the presence of at least one active monitoring device and determining an association between the active monitoring device and the user account.

[0014] The illustrative embodiment is further prompted to perform the steps of periodically downloading setup information from the active monitoring device to the VCA and storing downloaded setup information in association with the user account.

[0015] The illustrative embodiment also prompts the user to perform the steps of accessing a remote user patient profile to download user patient information and updating the user account with the downloaded user patient information.

[0016] Finally, the illustrative embodiment is prompted to perform the step of uploading downloaded setup information to the remote user patient profile. Fig. Figure 1 shows a clear example of a vehicle computer system and a remote network; Fig. Figure 2 shows a clear example of a process for saving patient data and updating a remote profile; Fig. Figure 3 shows a clear example of a process for notifying a patient about a dangerous condition; Fig. 4 shows a clear example of a patient warning of an emergency condition; and Fig. Figure 5 shows a clear example of a data transfer request process.

[0017] Although the following describes the invention in the form of illustrative embodiments, these examples are provided for illustrative purposes only and are not intended to limit the scope of the invention.

[0018] Fig. Figure 1 illustrates an exemplary block topology for a vehicle-based computing system (VCS) for a vehicle 31. The SYNC system manufactured by THE FORD MOTOR COMPANY is an example of such a vehicle-based computing system 1. A vehicle equipped with the vehicle-based computing system may include a visual front-end interface 4 located in the vehicle. The user may also be able to interact with the interface if, for example, it is equipped with a touch-sensitive screen. In another illustrative embodiment, interaction occurs through button presses, audible speech, and speech synthesis.

[0019] At the in Fig. In the illustrative embodiment 1 shown, a processor 3 controls at least part of the operation of the vehicle-based computing system. The processor is located in the vehicle and allows onboard processing of instructions and routines. Furthermore, the processor is connected to both non-persistent 5 and persistent storage 7. In this illustrative embodiment, the non-persistent storage is random access memory (RAM) and the persistent storage is a hard disk drive (HDD) or flash memory.

[0020] The processor is also equipped with a number of different inputs through which the user can interact with the processor. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between different inputs.

[0021] Inputs to both the microphone and auxiliary connectors are converted from analog to digital by a converter 27 before being forwarded to the processor. Although not shown here, numerous vehicle components and auxiliary components can use a vehicle network (such as a CAN bus) to communicate with the VCS and transmit data to and from the VCS (or its components).

[0022] Outputs to the system can include, without limitation, the following: a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs can also be made to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation system 60 along the bidirectional data streams, as shown at 19 and 21, respectively.

[0023] In one exemplary embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 with a user's mobile device 53 (e.g., a mobile phone, smartphone, PDA, medical device, wellness device, or other device with wireless remote network connectivity). The mobile device can then be used, for example, to communicate 59 with a network 61 outside the vehicle 31 via communication 55 with a cell tower 57. In some embodiments, the tower 57 may be a WiFi access point.

[0024] Example communication between the mobile device and the BLUETOOTH transmitter / receiver is represented by signal 14.

[0025] Pairing a mobile device 53 and the BLUETOOTH transceiver 15 can be initiated by a button 52 or a similar input. Accordingly, the CPU is informed that the onboard BLUETOOTH transceiver is being paired with a BLUETOOTH transceiver in a mobile device.

[0026] Data can be transmitted between the CPU 3 and the network 61, for example, using a data plan, data-over-speech, or DTMF tones associated with the mobile device 53. Alternatively, it may be desirable to provide an onboard modem 63 with antenna 18 to transmit data between the CPU 3 and the network 61 via the voice band 16. The mobile device can then be used, for example, to communicate with a network 61 outside the vehicle 31 by means of communication 55 with a cellular mast 57 59. In some embodiments, the modem 63 can establish communication 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem and the communication 20 can be cellular communication.

[0027] In a simplified embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to establish wireless communication with a remote Bluetooth transceiver (such as one found in a mobile device).

[0028] In another embodiment, the movable device 53 comprises a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency-division multiplexing can be implemented when the owner of the movable device can speak over the device while data is being transferred. At other times, when the owner is not using the device, the data transfer can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz).

[0029] If the user has a data plan associated with the mobile device, it is possible that the data plan allows broadband transmission and the system could use a much greater bandwidth (thereby accelerating data transfer). In yet another embodiment, the mobile device 53 is replaced by a (not shown) cellular communication device attached to the vehicle 31. In yet another embodiment, the mobile device 53 can be a wireless local area network (LAN) device capable of communication via, for example (without limitation), an 802.11g network (i.e., WiFi) or a WiMAX network.

[0030] In one embodiment, incoming data can be routed via a data-over-speech or data plan through the movable device, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, on the HDD or other storage media 7 until the data is no longer needed.

[0031] Additional sources that can interact with the vehicle include a personal navigation device 54, which, for example, has a USB connection 56 and / or an antenna 58; or a vehicle navigation device 60, which has a USB connection 62 and / or other connection, an onboard GPS device 24 or a remote navigation system (not shown) with connectivity to the network 61.

[0032] Furthermore, the CPU could be in communication with various other auxiliary devices 65. These devices can be connected via a wireless connection 67 or a wired connection 69. Alternatively, or in addition, the CPU could be connected to a vehicle-mounted wireless router 73 using, for example, a WiFi transceiver 71. This would allow the CPU to connect to remote networks within range of the local router 73. Auxiliary devices 65 include, among others, personal media players, wireless healthcare devices, portable computers, and the like.

[0033] Wireless technology is becoming increasingly affordable and provides a viable solution for transferring information from numerous point sources to other receiving sources. A wide range of devices are equipped with Bluetooth or other wireless technology, and these wireless connections can be used to transmit data between the equipped devices and other devices that are also equipped with Bluetooth or other wireless communication technologies.

[0034] A common source of wireless transceivers (or wired connections) are personal medical devices. These devices can monitor various patient information, such as blood pressure, heart rate, blood sugar, etc. When connected to a network, these devices can be used to transmit data to a storage device.

[0035] In addition to medical monitoring devices, other "health" devices include so-called wellness devices. These include, among others, pedometers, sports heart rate monitors and personal fitness equipment, GPS and MPH meters for sports, etc. These devices may have wireless connectivity, but are usually wired to a PC for analysis and data upload.

[0036] In the illustrated embodiments, data from these or other healthcare facilities can be wirelessly transferred to a vehicle computer system for local storage and / or remote uploading. Additionally, this information can be further transferred to a secondary wireless device, such as a mobile phone, for easy access and analysis.

[0037] Additionally or alternatively, this data can be analyzed by the vehicle's computer system and used to enhance the driving experience. For example, elevated blood pressure or heart rate could trigger a warning, or even a suggestion for calming music or reduced driving aggression. Another illustrative example would be suggesting a route with less traffic, which could likely lead to improved driving comfort.

[0038] In at least one illustrative embodiment, the vehicle itself is equipped with one or more medical monitoring devices. These could include, among other things, a heart rate monitor, for example, integrated into the steering wheel or seat. Another example would be a seat scale that tracks, measures, and / or reports weight changes for a specific driver / passenger.

[0039] Stored data can be added to and / or enriched with remotely stored data. For example, certain companies like Microsoft and Google offer patient data compilation services. These data repositories can hold a collection of patient information such as doctor's reports, current prescriptions, and so on. An account holder could grant the vehicle "right" to access this data. The data can be downloaded, viewed in the vehicle, added to stored and recorded vehicle data, used for potential drug interactions, to locate preferred healthcare providers, and so forth.

[0040] For example, a patient could be instructed to wear a remote blood pressure monitor (BPM) and track their health status. While driving, a BPM or heart rate monitor (HRM) could detect a potentially dangerous condition. Based on data obtained from a remote health data location, a vehicle computer system could access preferred parameters for the specific patient and compare these parameters with the tracked data. If a warning or emergency condition is detected, the vehicle could notify the patient of a potentially imminent problem. Additionally, contact information, such as that of a healthcare provider, could be retrieved from the remote location and provided in conjunction with the alert.

[0041] Using the contact information, the vehicle's computer system could offer the patient the option to call the doctor directly. If the doctor is unavailable, other medical contact information could be provided.

[0042] The system could also provide the patient with potential drug interaction information. For example, if the aforementioned patient is unable to reach a doctor but is inclined to take aspirin as a possible preventative measure to avoid a potential heart attack, the patient could enter (for example) TYLENOL into an "intended use" field, and the system could, based on data from the remote patient information provider, inform the patient whether a potential interaction exists. The patient could then determine whether, given the severity of the reported condition, the risk is worth taking.

[0043] If the patient's condition worsens, the system could even make an emergency call for them, or provide an easily accessible option for dialing emergency services (such as a large display) should their condition suddenly escalate. Even if the condition is not so serious, a patient might still appreciate receiving a warning that their heart rate or blood pressure is rising, allowing them to take preventative measures.

[0044] Fig. Figure 2 shows a clear example of a process for storing patient data and updating a remote profile. In this illustrative embodiment, a vehicle computer system first establishes communication with a wireless device. Based on the connection with the device, an associated user account is identified.

[0045] For example, a personal HRM or BPM can transmit an associated identifier. If this device has been associated with a user account, the vehicle can "assume" that the respective account holder is present as a passenger when the device is detected. Additionally or alternatively, the system can request which account the device should be associated with whenever the device is detected.

[0046] In another illustrative example, the presence of a cellular or other wireless device associated with the user account, together with the presence of the previously associated medical device, may be sufficient to indicate the presence of a particular passenger. Again, the vehicle's computer system can ask passengers about the intended storage location for the data.

[0047] In yet another illustrative embodiment, a medical monitoring device such as an HRM could be present in the vehicle. If the device is activated, the driver can be asked about an associated account to which data should be stored (or whether data should be stored at all).

[0048] If the existence of a user account is detected (201), the vehicle computer system checks for the presence of an existing remote profile (203) (stored on an associated website, such as GOOGLE HEALTH or MICROSOFT HEALTHVAULT). If no profile exists, the system checks for the existence of one or more medical facilities (209) (provided such facilities are not already connected to the system).

[0049] If the user has an associated remote patient and / or wellness profile, the vehicle computer system accesses the remote location where this profile is stored 205 and updates a local data store 207. In this embodiment, this update places the remote data in local storage for easy access when needed. This also creates a redundant local copy of the data, which can be useful for backup purposes. In at least one illustrative embodiment, the vehicle computer system does not access and / or download the remote data until it is needed. The system then proceeds to detect medical facilities.

[0050] Although the above example provides the identification of a single account and associated entities, it is equally possible to access, monitor, record the data of, etc., multiple entities associated with multiple accounts.

[0051] In this illustrative embodiment, the system periodically (or continuously) checks for monitoring events 211 and time intervals 213.

[0052] In this embodiment, two different instances are responsible for recording and / or analyzing data 213, 217. When an event occurs (high blood pressure, irregular heartbeat, arrival at the vehicle after completing sports exercises, etc.), the data from this event are recorded 213, analyzed 213, and any necessary action, such as a warning or notification, can also take place.

[0053] Additionally or alternatively, data for each periodic interval 215 are similarly recorded and analyzed 217.

[0054] In addition to checking for data recording points, the vehicle computer system also checks whether a recording period has ended (219). If the period has not ended, the system continues to check for recording points. If the period ends (device deactivated, ignition off, vehicle in park, etc.), the vehicle computer system saves the data (221). This data could be stored on local or remote storage.

[0055] After the data is saved (or instead of saving the data), the intuitive process determines whether a remote profile is associated with the user account. For example, a Microsoft HealthcareVault, Google Health, or similar account. If there is a profile associated with the account that needs updating, the vehicle's computer system updates user profile 225 and closes the application. If there is no associated account to update, the system simply closes the application.

[0056] Fig. Figure 3 shows a clear example of a process for warning a patient of a dangerous condition. In this clear example, this process corresponds to an “event” 211 of Fig. 2, but it could also be an independent or other consideration.

[0057] In this exemplary embodiment, the vehicle computer system checks a preset range for a device 301 (BPM, HRM, blood glucose monitor (BGM), etc.). This range could be determined by an associated patient profile or it could be a generically recommended medical range for all people, for a specific weight / height, etc.

[0058] If the device reads a value outside the range 303 (i.e., during a warning or event condition), the system checks whether to deliver a warning 305. If the device remains within the range, the system proceeds with processing at step 215 in this embodiment.

[0059] If a warning is requested, the system proceeds to play the warning before 309 and then, in this illustrative embodiment, provides a delay 311 (to avoid immediately repeating the warning during the next "event check"). Of course, the delay can also be omitted if necessary.

[0060] Warnings can be set automatically by the system or requested by a user. In instances where warnings are not required, this could be because a configuration read does not trigger a warning, or because a warning "off" state or another suitable condition exists.

[0061] Fig. Figure 4 shows a clear example of warning a patient of an emergency condition. In this illustrative embodiment, the vehicle's computer system detects an emergency condition 401. Although this step follows step 209 in this exemplary process, this process could also be a standalone emergency process intended for any medical facility or detection system capable of detecting a critical medical condition in a vehicle occupant.

[0062] Again, the critical medical condition could be defined by predefined parameters for a specific user, or by generalized parameters, or by a combination thereof.

[0063] In this embodiment, the system first determines whether the condition is critical 403 (it may just as well be possible to exercise caution and assume that all conditions which are emergency conditions are critical, although in this illustrative embodiment a distinction is drawn between critical and emergency conditions).

[0064] If the condition is not critical, the system provides a verbal or visual (if possible) warning to a user 415 and displays an emergency quick option 417 or makes it available in some other way.

[0065] In a vehicle environment with a navigation or other touchscreen display, the vehicle's computer system could, for example, provide a large or highly visible emergency call option. This option could be selected immediately, and a 411 call placed, if an emergency situation escalates. Similarly, if no display is present, the system could announce an audible option, such as "Rapid emergency call is now enabled, i.e., emergency call, to make an emergency call immediately."

[0066] If the emergency call option is not selected (or activated), the system checks whether the emergency condition is still ongoing (421). If the condition has ended, the system removes the option to prevent accidental emergency contact (423). However, if the condition persists, the criticality check is performed again (403) in case a previous non-critical emergency condition has escalated to a critical one.

[0067] If a condition is detected as critical, the system, in this embodiment, notifies the user of the detected critical condition 405. In this embodiment, a critical condition includes conditions that pose an immediate driving hazard. Additionally, a critical condition could render a driver unable to react; therefore, in this embodiment, the system is also prepared to place an emergency call.

[0068] Emergency call systems may require that a user be given the option to cancel an otherwise automatically placed call. Therefore, in this embodiment, the system informs the user that an emergency call is about to be placed. If the user does not select 409 to cancel the call, the emergency call will be placed (411). If the user is unconscious, comatose, or otherwise in a state where they cannot respond, in this embodiment the system will automatically place the call because the user will not be able to cancel it (assuming another person in the vehicle does not cancel the call).

[0069] Even if the call is canceled by the user or a passenger, the system can still provide a "rapid emergency call" option (417). For example, the system can check whether the condition status should be lowered (413). This could be due to another user request or a criticality level. Lowering the condition status can prevent repeated, unnecessary attempts to make an automatic emergency call.

[0070] If it is acceptable to lower the condition status, the state is reduced from critical to emergency 414 and yet the “rapid emergency call” option is still displayed 417 (at least in the present embodiment).

[0071] Fig. Figure 5 shows a clear example of a data transfer request process.

[0072] In this illustrative example, the vehicle's computer system is instructed to provide recorded data to a medical service provider. While the automatic provision of recently recorded data (such as data that triggered an emergency call) can accompany an emergency call, it is also possible for medical service providers to request data.

[0073] For example, if a patient is asked to wear a medical device to track a medical condition, the device can submit a report to the vehicle's computer system periodically or once. In this instance, relevant data can only be stored on the vehicle's computer system. A healthcare provider may wish to obtain a copy of the data before a visit, or to track a patient's progress or monitor a condition.

[0074] In this illustrative embodiment, a vehicle computer system receives a data request 501, for example from a medical service provider. This request can include a form of provider identification that automatically provides authorization for the request, or at least identifies the service provider to the vehicle occupant.

[0075] Upon receiving the request, the system notifies the vehicle occupant of request 503 (it is also possible that certain service providers with sufficient identification are permitted to automatically access the system, bypassing the manual identification process explained in this illustrative embodiment).

[0076] If the vehicle occupant approves the data request 505, the vehicle computer system may further request that the user enter a PIN or password 507. If available, this could be required for legal reasons to release data, or it could be a user-activated option to further protect potentially sensitive data.

[0077] If the PIN / password is incorrect, the system warns the user (509) and then checks whether too many incorrect passwords have been entered (or whether a certain time has been exceeded, etc.) (511). If the correct identification code has been provided (507), the system sends the requested data to the requesting party (513). Key to symbols

[0078] Fig. 1: 61 Network 4 Display 51 Input selector 52 BT pair 71 Wireless Module 67 Auxiliary facility 54 Persons Navigation Equipment 60 vehicle navigation systems 11 reinforcements Fig. 2: Yes No 201 Detect Associated Account 203 Long-distance profile? 205 accesses to profile 207 Update local data 209 Detect connected device 211th event? Add 213 data 215 Time? Add 217 data 219th period over? 221 data stored 223 Long-distance profile? 225 Update profile Exit = End Fig. 3: Yes No 301 HRM area check 305 Warning? Add 307 data Issue 309 warning Set 311 delay Fig. 4: Yes No 401 Detect Emergency Condition 403 Critical? Notify 405 users Inform 407 users about all calls Cancel? = To cancel? Insert 411 call Lower Condition? = Lower Condition? 414 Lower physical condition 415 users warn Show 417 emergency call options 419 Selected? 421 Condition lasts? 423 Remove emergency call options Fig. 5: Yes No 501 Data Request Received Notify 503 vehicle occupants 505 Approved? Exit 511 Another attempt? 507 PIN / Password? 509 occupants warn 513 Send data

Claims

[1] Computer-implemented method comprising the following: Determine, via a vehicle computing system (VCS), a user account associated with a vehicle occupant; Detect, via the VCS, the presence of at least one active surveillance device; Determine, via the VCS, an association between the active monitoring device and the user account; Periodic downloading of setup information from the active monitoring device to the VCS; Saving downloaded setup information in association with the user account; Receiving a request from a medical service provider to provide recorded facility information; Notifying a vehicle occupant of the request; and Sending the requested facility information to the service provider in response to the vehicle occupant's approval of the request. [2] The method of claim 1, further comprising: Determine that the vehicle occupant is associated with a wireless device located in a vehicle, wherein the wireless device corresponds to a user for whom a user account has been set up to store device information. [3] Method according to claim 2, wherein the wireless device is the at least one active monitoring device. [4] Method according to any of the preceding claims, wherein the at least one active monitoring device includes a monitoring device provided as part of a vehicle. [5] Method according to claim 4, wherein the at least one active monitoring device is a heart rate measuring device. [6] Method according to claim 5, wherein a heart rate measuring device is provided as part of a steering wheel. [7] Method according to claim 5 or 6, wherein a heart rate measuring device is provided as part of a vehicle seat. [8] Method according to any one of claims 4 to 7, wherein the at least one active monitoring device includes a weight sensor. [9] Method according to any of the preceding claims, wherein determining an association further comprises recognizing an existing stored association. [10] A method according to any of the preceding claims, further comprising: Accessing a remote user patient profile to download user patient information; Update the user account with the downloaded user-patient information. [11] The method of claim 10, further comprising: Uploading downloaded setup information to the remote user patient profile. [12] A method according to any of the preceding claims, further comprising: Uploading downloaded setup information to the wireless setup. [13] Method according to any of the preceding claims, wherein the periodic downloading further comprises downloading at least when a signal from the active device indicates that a parameter measured by the active monitoring device exceeds a threshold. [14] The method of claim 13, further comprising: Providing a warning in response to the signal from the active monitoring device indicating that the parameter measured by the active monitoring device exceeds the threshold. [15] The method of claim 14, further comprising: Providing emergency information when the signal from the active monitoring device indicates that the parameter measured by the active monitoring device exceeds the threshold. [16] Method according to claim 15, wherein the emergency information includes an option for the VCS to immediately select an emergency call service.

Images