Access to health information during emergency calls

Abstract

To provide a system that in the event of an emergency call being made by a first mobile device other than a mobile device of a user who is a victim of the emergency, estimates its location.SOLUTION: In a communication system 100, a mobile device 110 and an emergency entity 120 in a mobile network 130 accommodate emergency calls and couple the network to a medical database 140 comprising electronic health records EHR regarding respective persons. The mobile device obtains an encrypted medical identifier of a user of the device; and, upon establishing that the user may be a victim of the emergency, includes the encrypted medical identifier in an emergency message during the emergency call. The emergency entity retrieves the encrypted medical identifier from the emergency message, and accesses the medical database to retrieve at least one electronic health record on the basis of the encrypted medical identifier for enabling forwarding of information from the electronic health record to an emergency responder.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a mobile device configured for wireless communication in a mobile network, the mobile network providing wireless communication to the mobile device over at least a local area according to a network communication protocol. The network communication protocol enables calls between subscribers of the network, including emergency calls between the mobile device and an emergency entity. The emergency call is initiated when the mobile device performs an emergency action, such as calling an emergency number 112 or 911. The network is coupled to a medical database including an electronic health record (EHR) for each individual, each individual having a medical identifier that links the individual to their corresponding EHR. The present invention also relates to emergency entities and network entities, and methods for use in such devices and entities.

[0002] The present invention relates to the field of core networks, e.g., well-known regional mobile communication systems that may be referred to as 3G, LTE, 4G, or 5G. Access to the core network is managed by so-called providers or mobile network operators (MNOs), which provide access to the core network to subscribers' mobile devices using a set of subscriber data called a subscriber identity (SI). The SI contains subscriber identification data for accessing the core network for each subscriber of the provider. Typically, mobile devices, such as smartphones, are equipped with a dedicated transceiver for communicating with the core network and further include the subscriber identity SI. The SI represents the subscriber's identity and additional data required to access the core network, while the use of the core network is billed by the provider to each subscriber, for example, via a so-called voice and data bundle. For example, the SI may include a subscriber identity code, such as an IMSI (International Mobile Subscriber Identity). Such devices are typically provided with the SI by inserting a physical semiconductor module, called a SIM, into the mobile device. A SIM card is an integrated circuit embedded in a plastic card for the purpose of securely storing an International Mobile Subscriber Identity (IMSI) number and associated keys (used to identify and authenticate subscribers on mobile telephony devices, such as cell phones and computers). Various types of modules or cards are known, such as the Universal Subscriber Identity Module (USIM), which operates on the UMTS (Universal Mobile Telecommunications System), a 3G core network standard. Related physical cards are also known, such as the Universal Integrated Circuit Card (UICC), which is an application that operates on the UICC. Other types of SIMs are called e-SIMs or eSIMs (embedded SIMs) or embedded universal integrated circuit cards (eUICCs).The card is a non-replaceable embedded chip soldered directly to a circuit board. For the time being, all types of devices equipped for wireless communication with a core network and provided with a SIM card or otherwise provided with SI are referred to herein as SIM devices. [Background technology]

[0003] The paper "Mobile SIM-Based Medical Applications" by Michael J. Kleeman, Martin Harris, and James Erasmus, GSMA, February 2015, presents several mechanisms that allow access to medical information stored on a device's SIM card using a standardized SIM toolkit application. However, as the paper shows, only a limited amount of medical information can be stored on the SIM, while controlling access is complex. In particular, privacy can be an issue.

[0004] However, in an emergency, every second counts. It often takes time to identify a patient and provide the patient's relevant medical information (such as medical history, medication use, whether the patient wishes to be resuscitated, etc.) to first responders such as paramedics. It is increasingly common for such information to be stored in a personal electronic health record (EHR) somewhere in a medical database. It would be highly beneficial if such information were immediately available to emergency responders, such as medical personnel or physicians, who arrive at the scene of the emergency.

[0005] The mechanisms and organizational configurations described in the above references for deploying standardized SIM toolkit applications are quite complex. It would be beneficial to have a simpler solution for accessing electronic health records in an emergency to enable the transfer of information from the electronic health records to emergency responders such as police or emergency personnel. Summary of the Invention [Problem to be solved by the invention]

[0006] It would be beneficial to use the time between when an emergency call is placed to an emergency entity and when the first responder (responder) arrives at the scene to retrieve the necessary information from the EHR and provide this information to the first responder before they arrive at the scene of the incident. The aforementioned documents do not describe any mechanism for processing emergency calls. For privacy and confidentiality reasons, it would also be beneficial for the provision of such data not to depend on the MNO having knowledge of or access to the identity or credential information used to access the EHR. It is important to note that while emergency calls are handled differently from regular calls and may be less secure, they may not include user identity information, i.e., anyone should be able to call the emergency number without a subscription. Therefore, security is an important consideration to prevent sensitive information about a person's EHR from falling into the wrong hands.

[0007] Taking the above aspects into consideration, it is an object of the present invention to provide a system for reliable access to EHRs in emergency situations. [Means for solving the problem]

[0008] To this end, there are provided devices and methods as defined in the accompanying claims. According to one aspect of the invention, there is provided a mobile device as defined in claim 1. According to another aspect of the invention, there is provided an emergency entity (Entity) as defined in claim 7 and a network entity (Entity) as defined in claim 12. According to another aspect of the invention, there is provided a method as defined in claims 13 and 14. According to another aspect of the invention, there is provided a computer program product downloadable from a network and / or stored on a computer readable and / or microprocessor executable medium, said product comprising program code instructions for carrying out the method when executed on a computer.

[0009] The mobile device is configured to perform wireless communication within a mobile network. The mobile network provides wireless communication for the mobile device over at least a geographical area according to a network communication protocol. The network communication protocol enables calls between subscribers of the network. The calls include emergency calls between the mobile device and an emergency entity, where the emergency call setup is initiated when the mobile device performs an emergency operation, e.g., the caller dials a local emergency number such as 112 or 911, or a mobile device embedded in a vehicle can dial after detecting an accident based on strong deceleration.

[0010] The network is coupled to a medical database containing respective electronic health records (EHRs) for each individual. The medical database may be provided by a mobile network administrator or on a server coupled to the network, but the medical database may also be accessible via other networks or devices (e.g., operated by emergency entities), for example, via dedicated coupling devices or links.

[0011] Each individual has a corresponding medical identifier that links the individual to the corresponding electronic health record. Note that a medical identifier is different from a subscriber identity (SI), because an SI is essentially public and already known to the network and network administrator. Known SI data, such as a SIM card unique identifier (i.e., International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI), or Globally Unique Temporary User Identity (GUTI)), is not suitable for accessing medical databases as it does not take privacy aspects into account. Such SI data also makes it very difficult for a user to switch to another network administrator. In one embodiment, the medical identifier is encrypted using security credentials unknown to the network administrator, and only emergency entities, healthcare providers, or first responders have access to key material for decrypting the medical identifier. The encrypted medical identifier may include medical credentials for accessing the corresponding individual's electronic health record or a specific electronic health record related to the emergency. Additionally, access to the medical database may be based on a combination of subscriber identification data and an encrypted medical identifier, and may be based on security credential information (e.g., password, pre-shared key, secret key) known by an emergency entity, a user, a network administrator, a medical provider, a first responder, or a combination thereof.

[0012] The emergency entity is adapted to retrieve the encrypted medical identifier from the emergency message, access a medical database, search at least one electronic health record (EHR) based on the encrypted medical identifier, and enable transfer of information from the electronic health record (EHR) to emergency responders. The emergency entity may be adapted to decrypt the encrypted medical identifier, for example, by providing key material to a medical organization. Various systems for encrypting medical identifiers are known, such as using a public key to encrypt the medical identifier while the emergency entity is provided with a corresponding private key. As another example, the key material may be available and processed only in a medical database to which only a limited set of individuals are authorized to access (e.g., via username / password login).

[0013] The mobile device comprises a network communication unit for enabling calls over a network and a secure processor configured to obtain an encrypted medical identifier of a user of the device and, upon determining that the user may be the victim of an emergency situation, include the encrypted medical identifier in an emergency message during the emergency call. For example, the mobile device may access a local secure storage unit within the device (e.g., on a SIM) to retrieve the encrypted medical identifier. The mobile device may also access a secure storage unit over the network, such as a Home Subscriber Server (HSS) at a mobile operator's premises that maintains a database providing subscriber details to other parties in the cellular network. As part of the obtaining, the mobile device may also encrypt the medical identifier to generate an encrypted medical identifier (e.g., by configuring encryption credentials via an application on the phone (e.g., running as part of a SIM toolkit) or a secure out-of-band channel such as NFC or reading a dynamically generated QR code).

[0014] The above features have the following advantages: EHR identification data is received as part of the setup of a cellular emergency communication session; the EHR of the emergency victim is immediately accessible, so no time is lost between receiving the emergency message and retrieving potentially life-saving patient health information for use by first responders; an advantageous effect requires that the victim has made prior preparations to allow emergency responders to access their EHR information, such as storing their EHR, adding emergency entities and / or emergency response teams (e.g., ambulance personnel) to a list of organizations and / or people that can access their EHR information, exchanging security credentials with the emergency entity, or provisioning their mobile device with an encrypted medical identifier for inclusion in emergency messages during the emergency call. Advantageously, such prior preparations take privacy considerations into account, and the use of dedicated encrypted medical identifiers can avoid potential misuse.

[0015] The network can provide a location service for determining the location of each mobile device within a region, and can be configured to transmit a request message to each mobile device requesting that an encrypted medical identifier of a user of the mobile device be included in an emergency message.

[0016] In one embodiment, when an emergency call is made by a second mobile device other than the user's mobile device that may be a victim of the emergency, the emergency entity can be adapted to locate at least one mobile device near the second mobile device via the location service; and generate a request message for the located mobile device. Thus, the emergency entity can determine which mobile device is likely to be the mobile device of the victim of the emergency, e.g., the device closest to the second mobile device. The caller of the second mobile device can help determine which mobile device belongs to the victim, e.g., by moving the second mobile device toward the victim. The emergency entity can instruct the caller to move or remain in close proximity to the victim (or the victim's phone).

[0017] In one embodiment of the mobile device, the secure processor is configured to receive the request message to determine that the user may be a victim of an emergency. Upon receiving such a message, the mobile device determines that the user may be a victim of an emergency and includes an encrypted medical identifier in the emergency message. Advantageously, EHR identification data can be automatically obtained from the victim's phone even if the caller is not the victim.

[0018] In one embodiment in which the mobile device is configured to perform distance measurements between the mobile device and other mobile devices, the safety processor is configured to enable distance measurements and transmit the measured distances to a network to determine improved location data for the mobile device in the event of an emergency. For example, a location service, an emergency entity, and / or a second device placing an emergency call may be configured to generate at least one distance measurement message. Such distance measurement message requests performing at least one distance measurement between the mobile device and at least one other nearby mobile device and transmitting the at least one measured distance to the location service and / or emergency entity to determine improved location data for the mobile device. In response, the safety processor may be configured to receive the distance measurement message and enable the distance measurements. Advantageously, the location of a victim's mobile device may be determined with increased accuracy through at least one measured distance to the other located device. The improved location data may be forwarded to the responder to improve the victim's location.

[0019] In one embodiment, a network entity to be deployed in a mobile network is adapted to receive identity data from a mobile device involved in an emergency call setup, obtain an encrypted medical identifier corresponding to the identity data, and include the encrypted medical identifier in an emergency message during the emergency call. The emergency message including the encrypted medical identifier is forwarded to an emergency entity. For example, an IMEI can be used as identity data and can be linked to the encrypted medical identifier by, for example, a user registering their device via some kind of registration service provided by a mobile operator and linking the device to the encrypted medical identifier.

[0020] The method according to the invention can be implemented on a computer as a computer-implemented method, on dedicated hardware, or a combination of both. The executable code of the method according to the invention can be stored in a computer program product. Examples of computer program products include memory devices such as memory sticks, optical storage devices such as optical disks, integrated circuits, servers, online software, etc.

[0021] A computer program product in non-transitory form may comprise non-transitory program code means stored on a computer-readable medium for performing the method according to the present invention when the program product is run on a computer. In one embodiment, the computer program comprises computer program code means adapted to perform all the steps or stages of the method according to the present invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer-readable medium. Also provided is a computer program product in transitory form downloadable from a network and / or stored in a volatile computer-readable memory and / or microprocessor-executable medium, which comprises program code instructions for performing the above-described method when the program product is run on a computer.

[0022] Another aspect of the present invention provides a method for making a computer program in a temporary form available for download, which is used when the computer program has been uploaded to a store such as Apple's App Store, Google's Play Store or Microsoft's Windows Store and when the computer program is available for download from such a store.

[0023] Further preferred embodiments of the device and method according to the invention are set forth in the appended claims, the disclosure content of which is incorporated herein by reference.

[0024] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described by way of example in the following description with reference to the accompanying drawings, in which: FIG. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 shows a network for mobile devices, emergency entities and wireless communications. [Figure 2] FIG. 2 illustrates an example of a system including a mobile device, a network entity, an emergency entity, and a network for wireless communication. [Figure 3] FIG. 3 illustrates a method for use in a mobile device arranged for wireless communication within a mobile network. [Figure 4] FIG. 4 shows a method for use in an emergency entity to be located in a mobile network. [Figure 5a] FIG. 5a illustrates a computer readable medium. [Figure 5b] FIG. 5b shows a schematic diagram of the processor system. DETAILED DESCRIPTION OF THE INVENTION

[0026] The figures of the drawings are purely diagrammatic and are not drawn to scale. In the figures, elements that correspond to elements already described may have the same reference numerals.

[0027] FIG. 1 illustrates a mobile device, an emergency entity, and a network for wireless communication. In a communication system 100, a mobile device (MOB-DEV) 110 is configured to communicate wirelessly in a mobile network 130 according to a network communication protocol. The mobile device may be, for example, a mobile phone, a wearable medical device, or a data communication unit embedded in a vehicle. In the communication system, a subscriber identity (SI) includes subscriber identification data of a subscriber for accessing a core network, and the mobile network provides wireless communication for the mobile device over at least a certain geographic area. As explained in the introduction, the mobile network may be a 3G, LTE, 4G, or 5G cellular core network. FIG. 1 schematically illustrates a network 130 for providing a communication channel between an emergency entity EM-ENT 120 and the mobile device MOB-DEV 110. The core network is managed by at least one communication provider, for example, to manage a subscriber database and handle billing. The network is also coupled to an electronic health record (EHR) 140, which may be hosted, for example, on another server on the Internet or provided by a medical institution or emergency entity and coupled to the network wirelessly and / or via a wired or dedicated link.

[0028] The mobile device 110 is configured for wireless communication with a network and includes a transceiver 111 configured for wireless communication and a processor 112 configured to control the communication and provide an interface to a user. The mobile device may include a subscriber identity module (SIM), and may also include a user interface 113 including, for example, a display and one or more user input elements 115. For example, the user input elements may include one or more of a touchscreen, various buttons, a mouse, or a touchpad. The buttons may be traditional physical buttons, touch sensors, or virtual buttons such as icons activated on a touchscreen or via a mouse. The user interface may also be a remote user interface.

[0029] The emergency entity (EM-ENT) 120 has a secure processor 122 configured to perform emergency processing as described below, and a network communication unit 121 configured to communicate with the network either wirelessly or via a wired link.

[0030] The network is coupled to a medical database 140 that includes an electronic health record (EHR) for each individual, with each individual having a medical identifier that links the individual to a corresponding EHR.

[0031] The network communication protocols enable calls between subscribers of the network, including emergency calls between mobile devices and emergency entity 120. Emergency call setup is initiated when a mobile device performs an emergency action.

[0032] A secure processor 122 within the emergency entity is configured to retrieve an encrypted medical identifier from the emergency message. Upon retrieving the encrypted medical identifier, the secure processor accesses the medical database to retrieve at least one electronic health record (EHR) based on the encrypted medical identifier and enables information from the EHR to be transferred to a responder of the emergency. Selection of a responder for the emergency response may be performed automatically based on the responder's circumstances, such as location, expertise, readiness, preferences, etc., derived from corresponding information captured from the responder's mobile device. Transfer of EHR data may be automatically routed to a mobile device of a responder to the emergency, such as an ambulance. Responder selection and transfer of EHR information may also be performed by an operator at the emergency entity, for example, by placing a call to medical staff at an ambulance.

[0033] A secure processor 116 in the mobile device is configured to obtain an encrypted medical identifier of a user of the device and, upon determining that the user may be the victim of an emergency situation, include the encrypted medical identifier in an emergency message during an emergency call. Various practical embodiments are described below.

[0034] In a practical embodiment of the system, device A, which is a mobile device, transmits an encrypted identifier X, which is different from the unique identifier of the SIM card itself (i.e., International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) or Globally Unique Temporary User Identity (GUTI)), as part of a cellular emergency communication session setup with destination device B, which constitutes an emergency entity. Device B is communicatively coupled to a database of patient health records, either directly or via device C. Either device B or device C decrypts (decrypts) the received encrypted identifier X to yield a decrypted identifier Y, which is used to retrieve the patient health record associated with identifier Y.

[0035] In another practical embodiment, a second mobile device D makes the emergency call, but is not the victim's mobile device. In this situation, the system involving devices A, B, and C is the same as described above. Accordingly, the second mobile device D sets up a cellular emergency communication session with destination device B (emergency entity). Device B is communicatively coupled to a location service S operating in a mobile administrator's core network. The location service S can determine which mobile device is closest to the calling device. Device B requests service S to determine which mobile device A is closest to the calling device, and upon determining mobile device A, subsequently issues a request to device A to send an encrypted identifier X to device B as part of the cellular emergency communication session setup. Alternatively or additionally, service T or another communication session with device D can be used to transfer the encrypted identifier X to device B. Device B receives and processes the encrypted identifier X as described above.

[0036] In one embodiment, the safety processor is configured to perform one or more of the following options to determine that the user may be the victim of an emergency situation: Optionally, the safety processor can determine that the emergency call is being placed via the network communication unit, for example, by detecting that a local emergency number has been dialed or by receiving data from the processor 112 of the mobile device on which the emergency call is being placed.

[0037] Optionally, the safety processor may detect one of the conditions described below to determine that the user may be the victim of an emergency situation, and if not automatically detected, additional checks or procedures may be required by the emergency entity, which may vary depending on whether the device to which the emergency call was made supports the ability to include a medical identifier (e.g., asking different questions or asking the user to perform a particular operation on the device). To this end, a message or an attribute / flag as part of a message may be sent to the emergency entity via emergency communication indicating that the device supports the ability to include a medical identifier and possibly sensor information or other information about what situation the device was unable to detect.

[0038] Optionally, the victim's phone can broadcast some message (e.g., over Wi-Fi®) that it is the victim's phone after detecting any of the following situations: If another device calls the emergency number, the other device can start listening for these messages from other nearby phones (e.g., over Wi-Fi®) and use this to determine if the user of the other device is the victim of the emergency or someone nearby.

[0039] Optionally, the safety processor can detect deceleration exceeding a predetermined limit, for example, to detect a vehicle accident or a user falling or being struck. Also, if a fall is detected by the mobile device immediately before dialing an emergency number, the user of the mobile device is likely the victim, and the mobile device can therefore automatically include an encrypted medical identifier. Also, if an automated emergency call (eCall) is made from a vehicle that has just been involved in an accident, the mobile unit in the vehicle can automatically include the driver's encrypted medical identifier. Also, the vehicle control system can be configured to determine who the driver and possibly other passengers are, and include one or more encrypted medical identifiers.

[0040] Optionally, the safety processor can detect abnormalities in a user's vital sign sensor. A vital sign sensor on a mobile device can detect a major health issue (such as a heart attack). Typically, this can generate an alarm or warning condition. Thus, if this occurs before placing an emergency call, the mobile device can automatically include an encrypted medical identifier. Optionally, the safety processor can therefore detect warning conditions generated by other processors within the mobile device or by an external source, such as a vehicle.

[0041] Optionally, the safety processor can receive user input regarding the emergency. For example, the UI of the mobile device can present a question regarding whether the user is a victim of an emergency or the nature of the emergency. For example, the question can be whether the caller or a bystander is a victim. The mobile device can also have voice recognition to distinguish between a caller saying, for example, "I caused the accident" and "I saw the accident." Based on the result, the safety processor automatically includes or does not include the encrypted identifier. The mobile device can also have some pre-configured set of rules (e.g., set by the user). For example, one rule can be that when calling an emergency number, the encrypted identifier is included only if the user does not press a "Do not include identifier" button within 10 seconds of starting the call.

[0042] Optionally, the secure processor can receive user input regarding the inclusion of an encrypted medical identifier in the emergency message. For example, the user can indicate so or confirm that they wish to forward the medical data to the emergency entity; for example, the device can prompt the user with a question about whether the caller wants to include the encrypted medical identifier. The mobile device can also prompt the user via voice communication to press a key (e.g., press "1") to include the encrypted medical identifier. Optionally, the user can provide blanket "user consent," i.e., the user can agree to always include the encrypted medical identifier, not just when they are the victim of an emergency.

[0043] Optionally, the secure processor can be configured to receive a message from an emergency entity. Such a message can request the entry of additional data related to the emergency or the victim. Optionally, the emergency entity can send a special message, for example within 20 seconds, that may or may not include an encrypted medical identifier. The mobile device can be configured to wait until it receives this message before sending the encrypted medical identifier. To this end, the emergency dispatcher can press another button on the screen as they assess the situation regarding the caller and the victim, after which a corresponding special message is sent. The special message can include different authentication credentials based on whether the caller is a victim, which can be used as a cue whether or not to send the encrypted medical identifier.

[0044] Optionally, the safety processor can receive a message from the network that no other mobile phones are within bystander range. For example, the network can detect that no one other than the caller is within 100 meters. If so, the caller is likely a victim, so an identifier needs to be included, and this can be notified to the mobile device. Once it is determined that the user of the mobile device is a victim, the mobile device can automatically turn on precise location services on the mobile device (e.g., GPS) or on other mobile devices near the user (e.g., GPS on a mobile device in the user's vehicle) to pinpoint the user's precise location and automatically include the user's location information in the emergency call. Optionally, other location services on the mobile device that may help pinpoint the user, such as Wi-Fi®-assisted GPS, can be turned on and automatically used to pinpoint the user's precise location (e.g., less than 10 meters).

[0045] The network can provide a location service for determining the location of each mobile device within a region, and can be configured to enable transmission of a request message to each mobile device requesting that an encrypted medical identifier of the user of each mobile device be included in an emergency message.

[0046] In one embodiment, mobile device 110 is configured to perform distance measurements between the mobile device and other mobile devices, and safety processor 116 is configured to enable distance measurements and forward the measured distances to a network in the event of an emergency to determine improved location data for the mobile device. Receiving one or more distance measurements between the mobile device and other located devices allows a location service and / or emergency entity to improve the accuracy of the mobile device's location data. In practice, location data based on receiving transmissions from a mobile device is not very accurate, for example, with a tolerance of 100 m. In contrast, local distance measurements are much more accurate, for example, with a tolerance of 1 m. Combining multiple locations of multiple mobile devices with the distances between such located devices can improve the accuracy of the location data.

[0047] In a practical embodiment of the system, device A sets up an emergency call with emergency entity B. Device B is communicatively coupled to a service or function T operating in a core network of a mobile administrator. Service T can determine a group of mobile devices {D0, ..., Dn} located near device A and capable of performing wireless distance measurements and / or angle estimation. Service T sends a message Mx to each mobile device Dx (0≦x≦n) in the group of mobile devices {D0, ..., Dn}, where message Mx includes instructions and optional authentication credentials for participating in performing distance measurements with mobile device A, and further sends a message N to mobile device A, where message N includes instructions and optional authentication credentials for participating in distance measurements with mobile devices {D0, ..., Dn}. Mobile device A and mobile devices {D0, ..., Dn} then perform distance measurements and / or angle estimation and transmit the results of the distance measurements and / or angle measurements to service T. Service T (or some other functionality in the core network or device A to which T is communicatively coupled) can use the received distance and / or angle measurements to improve the location estimate of device A and insert the improved location estimate as part of the cellular emergency communications session setup with the emergency entity.

[0048] In one embodiment, the secure processor 116 in the mobile device is configured to obtain the encrypted medical identifier and perform one or more of the following options:

[0049] Optionally, the secure processor is configured to encrypt the medical identifier data during the emergency call based on key data, which may be stored in a secure storage memory within the device, for example in a SIM.

[0050] Optionally, the secure processor is configured to receive authentication data to verify that a trusted party is requesting the encrypted identifier be transmitted, for example, an emergency entity may first transmit its authentication data to the mobile device.

[0051] Optionally, the secure processor is configured to retrieve medical identifier data or an encrypted medical identifier from a remote server accessible to the secure processor via the network communication unit, for example, a subscriber may store medical identifier data or an encrypted medical identifier in the HSS in advance for use in an emergency.

[0052] In one embodiment, the secure processor in the mobile device is configured to retrieve the encrypted medical identifier to re-encrypt the medical identifier data after the encrypted medical identifier has been used as part of an emergency call or after a predetermined period of time, such re-encryption preventing a malicious third party from reusing the original encrypted medical identifier.

[0053] In one embodiment, when an emergency call is made by a second mobile device other than the user's mobile device that may be a victim of an emergency, the emergency entity may be configured to locate at least one mobile device in the vicinity of the second mobile device via the location service and generate a request message for the located mobile device. Thus, the emergency entity may determine which mobile device is likely to be the mobile device of the emergency victim, e.g., the device closest to the second mobile device. The caller of the second mobile device may assist in determining which mobile device belongs to the victim by moving the second mobile device toward the victim. The emergency entity may instruct the caller to move or remain in close proximity to the victim (or the victim's phone). Optionally, a safety processor within the emergency entity may be configured to select one of the at least one located mobile device based on the proximity of the selected mobile device's location to the second mobile device. The safety processor within the emergency entity may also be configured to select the one of the at least one located mobile device based on positions of a plurality of located mobile devices forming a spectator pattern around the selected mobile device.

[0054] In one embodiment, the safety processor 122 in the emergency entity can be configured to select the one of the at least one located mobile device based on requesting an operator of a second mobile device to move the second mobile device closer to the victim's mobile device while the other mobile devices remain far away, and the safety processor 122 in the emergency entity can be configured to send a call setup request to the selected mobile device, causing a ringing signal to originate from the selected mobile device, allowing the operator of the second mobile phone to verify that the selected mobile device is the victim.

[0055] In one embodiment, the safety processor 122 in the emergency entity is configured to select the one of the at least one located mobile device based on transmitting biometric characteristic data to a second mobile phone to enable an operator of the second mobile phone to verify that the biometric data corresponds to the victim holding the selected mobile phone. The safety processor 122 in the emergency entity can also be configured to request the operator of the second mobile phone to obtain the victim's biometric characteristic data and forward the obtained characteristic data to the emergency entity.

[0056] For example, if the person making the call via the second mobile device is not the victim, even if one or more positioning mechanisms are used to determine the closest device within range that should be the victim, additional checks may be required to determine whether the correct person's EHR information is being addressed. Of course, if the person is conscious, checking the person's name against their name as part of the patient's EHR information may be sufficient. If the person is unconscious, the additional checks may include sending information about physical characteristics based on the patient's EHR information, such as gender, age, hair color, eye color, height, weight, and perhaps a photograph stored as part of the patient's EHR, to the second mobile device. Thus, the caller or a first responder arriving at the scene can use the received information / photograph to determine whether the victim is indeed the person corresponding to the information / photograph. Alternatively, the caller could send photographs of the victim and / or bystanders to an emergency entity to check whether the photograph in the EHR corresponds to the victim. The photograph would then be sent to a dispatcher at the emergency entity, who would then make the identification. As another example, if the person is unconscious, the caller or first responder arriving at the scene may be asked to verify the victim's fingerprint by placing the victim's finger on a fingerprint scanner (e.g., using an app on the first responder's phone), which is then matched with fingerprints stored as part of the EHR to check that the fingerprint indeed corresponds to the victim. As yet another alternative, the caller or first responder may be instructed to find other information at the scene (e.g., by checking the victim's wallet) to identify the victim and confirm that their name matches the patient's name in the EHR information. As yet another example, the nearest nearby device may sound an alert (e.g., start making a particular noise or display a message) that it is about to call an emergency entity, including an encrypted identifier X for accessing the corresponding EHR information.

[0057] Figure 2 shows an example of a system including a mobile device, a network entity, an emergency entity, and a network for wireless communication. In communication system 200, mobile device (MOB-DEV) 110, mobile network 130, and emergency entity (EM-ENT) 120 are as described above with reference to Figure 1. Medical database (EHR) 240 is similar to medical database 140 in Figure 1, but here it is directly coupled to the emergency entity. Alternatively, the medical database can be accessed via another network, for example, via a local network coupled to the emergency entity, or via another device coupled to the emergency entity.

[0058] 2 also shows a network entity (NE) 210 coupled to the network. The network entity is configured to receive identity data from a mobile device involved in setting up an emergency call. The network entity is further configured to obtain an encrypted medical identifier corresponding to the identity data and include the encrypted medical identifier in an emergency message during the emergency call. For example, the network entity may retrieve the encrypted medical identifier from an HSS (Home Subscriber Server; not shown), as described further below. A subscriber may store the medical identifier data or the encrypted medical identifier in the HSS in advance for use in an emergency.

[0059] In the following sections, a system for providing information from an electronic health record (EHR) to emergency responders is described, which comprises the following devices: Device A is a mobile device operated by the victim. This device is likely to be a mobile phone, but could also be a vital signs monitor, telemetry / ECG monitor, smart watch, fall detector, or other type of portable device. As another example, Device A could be an in-car cellular network unit capable of making an emergency call (eCall) after the car is involved in an accident. Device B is a phone, laptop, or server device within the emergency entity operated by an emergency medical dispatcher to receive and process the particular emergency call from Device A. Device C is optionally another device (e.g., a computer or gateway or server device used by an emergency medical dispatcher) to which device B is connected and which provides access to a database with relevant patient health data.

[0060] In one embodiment, device A has some local non-volatile storage that is secure and protected from general access by a general application processor, such as a smart microSD storage, or a secure storage within the mobile device's SIM or eSIM (also known as UICC and eUICC, respectively) or part of the device's secure element. Typically, these types of secure storage solutions can host a set of applications and services in one or more security domains (e.g., as specified in the GlobalPlatform Card Specification v2.2). For mobile devices, it is very common to equip the (e)SIM with access to cellular networks. As specified in ETSI TS 102.221 and 3GPP TS 31.101, the (e)SIM's secure storage is structured according to a specific file structure and can be accessed using a set of standardized interface commands. The (e)SIM is also typically equipped with its own security processor capable of performing encryption / decryption and other types of security functions.

[0061] Device B or device C is associated with a database containing an electronic health record. Given that such a database typically contains health records for many different people, accessing a particular individual's record requires an individual's unique identifier. For security purposes, these records are protected with one or more passwords or security credentials. In one embodiment, an application (e.g., a website) associated with the database generates an identifier Y and corresponding security credentials S to allow access to an individual's electronic health record in an emergency. In one embodiment, the identifier Y and security credentials S can be used to access all information stored as part of the EHR. In other embodiments, the identifier and corresponding credentials can be used to access only a subset of the EHR information for emergency access, rather than to gain complete access to all data in the EHR.

[0062] In another embodiment, the identifier Y and the credential S are encrypted with an encryption key T, thereby generating an encrypted identifier X and an encrypted credential S'. In one embodiment, a mechanism such as that described in US8627103 is used for encryption and decryption, whereby the healthcare provider only accesses the data decryption key (e.g., credential S above) after it has been provided by an emergency agent. The resulting encrypted identifier X and encrypted credential S' are stored on device B or C, or in a secure database accessible by device B or C. Device B or C also has access to the decryption key associated with encryption key T.

[0063] In one embodiment, the encrypted identifier X and, optionally, the encrypted credential S' are provided to the mobile network operator (MNO) to which the person to whom the EHR data pertains subscribes, and then sent by the MNO to the individual or downloaded to the individual's mobile device A's eSIM or stored on the SIM remotely pre-configured by the MNO as part of the MNO's eUICC profile, which is securely transmitted over the air by the MNO using a proprietary interface. The encrypted identifier X is preferably stored as a basic file readable by a USIM application running on the (e)SIM, as specified in 3GPP TS 31.102. The same is true for the encrypted credential S'. In an alternative embodiment, the encrypted identifier X and, optionally, the encrypted credential S' are stored as part of a SIM toolkit within the same security domain as the USIM application by other applications running on the (e)SIM, as specified in 3GPP TS 31.111. For example, the other application may be an application that is able to read a dynamic QR code containing an encrypted identifier X, the QR code being generated by a web interface to an EHR database. This can be done in a similar way for the encrypted credential S'.

[0064] In another embodiment, the encrypted identifier X is stored as a primitive file on the (e)UICC under a non-network security domain (e.g., ECASD) rather than the security domain of the MNO used to connect to the mobile network. An interface application on the (e)UICC accesses the encrypted identifier X through a secure channel established between security domains using a set of access rules (e.g., as specified in Globalplatform Card Specifications v2.3.1) to ensure that network-related information (e.g., IMSI, PLMN) is not accessible (network access) between security domains (e.g., as specified in Applet Isolation and Object Sharing in Java Card 2.2x Runtime Environments). This can be done in a similar way for the encrypted credential S'.

[0065] In other embodiments, the encrypted identifier X is stored as a primary file in the security domain of MNO.X rather than in the security domain of MNO.Y used to connect to the mobile network (e.g. a dual SIM device where one of the SIM cards has the encrypted identifier X and the other does not). (e) An interface application on the UICC accesses the encrypted identifier X (network access) via a secure channel established using a set of access rules between the different security domains, ensuring that network related information (e.g. IMSI, PLMN) cannot be accessed (network access) between security domains. This can be done in a similar way for the encrypted credential S'.

[0066] In an alternative embodiment, the encrypted identifier X is stored as a basic file in the secure element under a different root of trust than that of the (e)UICC. When initiating an emergency call, the interface application on the (e)UICC accesses the encrypted identifier X using the security parameters (e.g., PIN code) of the security domain (no network access) stored in the secure element under a different root of trust than that of the (e)UICC (e.g., a PIN code of the secure element provided by the owner of device A during initial setup). This can be done in a similar way for the encrypted credential S'.

[0067] In another embodiment, the encrypted identifier X is stored as a basic file in the security domain of the (e)UICC itself, which has not yet been pre-configured with an MNO profile for connecting to a mobile network (e.g., a blank (e)UICC). An interface application on the (e)UICC accesses the encrypted identifier X stored under the security domain of the (e)UICC and transmits it over the network (e.g., equivalent to an emergency call made without a mobile subscription). This can be done in a similar way for the encrypted credential S'.

[0068] In another embodiment, device A has an NFC interface, and the encrypted identifier X and optional encrypted credential S' are transferred from device W to device A using an NFC communication channel, thereby (e) using the NFC capabilities of the UICC (e.g., as specified in RSP Architecture V2.2) to store the encrypted identifier X and optional encrypted credential S' under the MNO security domain or in a security domain hierarchy with authorized administrative privileges. (e) It should be required that an interface application on the UICC ensures that the NFC application storing the encrypted identifier X and optional encrypted credential S' under a specific security domain is trusted and (e) authorized to modify content under the specific security domain on the UICC (e.g., based on the authentication rights of that security domain).

[0069] In one embodiment, a cellular network unit in a vehicle can make an eCall if the vehicle is involved in an accident. The cellular network unit may include multiple identifiers, for example, for each family member using the vehicle. When the vehicle's cellular unit places an eCall to an emergency entity, multiple encrypted identifiers may be simultaneously transmitted to the emergency entity as part of the eCall, since multiple family members may be involved in the car accident. As another example, when the eCall is received by the emergency entity, the location of the vehicle making the eCall is matched with the locations of one or more mobile devices (e.g., mobile phones carried by one or more people in the vehicle) closest to the vehicle. If the locations match within a small margin of error (e.g., two meters), the mobile device (or devices) whose location matches the vehicle's location is considered to be owned by the victim. As another example, an emergency center, via a service provided by an MNO, can find the phone numbers of nearby mobile devices and call them to determine what happened and how many people are involved.

[0070] In another embodiment, device A places an emergency call to an emergency entity using GSM / CSMA / HSDP / LTE / 5G NR, and the call is routed / forwarded within the emergency entity to device B. The emergency call is typically an emergency call made to a national emergency number, such as 112 in Europe or 911 in the United States. Essentially, the national emergency number is stored and recognized by the mobile device, and for that number the mobile device and network can initiate special protocol operations related to the emergency call. MNOs have specific mechanisms for handling calls in an emergency, as specified, for example, in 3GPP TS 23.401 section 4.3.12 for 4G, 3GPP TS 23.501 section 5.16.4 for 5G, and 3GPP TS 22.101 section generally. In this specification, emergency calls are not limited to calls to national emergency numbers, but can also be other types of calls, such as to a hospital, where rapid access to critical patient health information is important and can be identified as such. This can be achieved, for example, by providing the MNO with a specific set of phone numbers to which an encrypted identifier X should be sent when a call is made to one of these phone numbers, by having an additional authentication / authorization step as part of making the call (e.g., sending the encrypted identifier X only if the recipient is able to authenticate itself to the MNO or the originating device, or if the originating device provides credentials to access a specific (private) network slice, e.g., operated by a hospital), or by providing the necessary credentials, for example, via an application (i.e., an Application Function (AF) in 3GPP TS 23.501) connected to a network publishing function and / or policy control function (i.e., an NEF and PCF as specified in 3GPP TS 23.501) via a secure API, or via a lawful interception framework (e.g., as specified in 3GPP TS 33.106).

[0071] In another embodiment, the encrypted identifier X is sent as part of the emergency communication session setup, either as a separate message or as an attribute or information element / subfield in an existing message. The identifier can be inserted as part of the call setup procedure in the USIM application. If the Session Initiation Protocol (SIP) is used for the call setup, this can be done, for example, using a field in the SIP Invite or SIP Register message for emergency services (as specified in 3GPP TS 23.167). The identifier can also be added as an additional URI parameter to the emergency SIP address used as the destination of the SIP Invite / Register message. As another example, the identifier can be added as an additional message or as part of an additional data field in the eCall MSD message (as specified in 3GPP TS 26.267). If a PLMN circuit-switched network is used for the call setup, it can be added to a field in an attribute included in the emergency call, for example, as specified in 3GPP TS 22.003 section A.1.2.

[0072] In another embodiment, the credentials S or encrypted credentials S' are also stored in a secure storage unit of device A and transmitted together with the encrypted identifier X as part of the emergency communication session.

[0073] In an alternative embodiment, the encrypted identifier X is sent to a Mobility Management Entity (MME), Access Mobility Function (AMF) or a packet data network PDN gateway, e.g. as part of a field / attribute in a NAS Attach Request or NAS Attach Accept message and / or a PDN connection request for an emergency bearer, and the corresponding MME / AMF, PDN gateway forwards the identifier X to the emergency entity (e.g. as part of a SIP message for IMS connection setup or as part of a message for circuit switched network connection setup).

[0074] In another alternative embodiment, the encrypted identifier X is not stored on device A itself, but rather in the core network, e.g., as part of a generic 5G user identity service provided by a Home Subscriber Server (HSS, as specified in TS 23.002) or a network administrator. When device A registers itself with the network, the MME retrieves the information from the HSS and passes it during connection setup with the emergency entity (e.g., as part of a SIP message for IMS connection setup or as part of a message as part of setting up a circuit-switched network connection). This can, of course, only be used if the SIM is properly registered with the core network (i.e., is a valid UE according to 3GPP TS 23.401 section 4.3.12). Also, even if the device is not fully registered with the network during an emergency, the network can still provide services if the user has previously linked their device's IMEI or other ID to the encrypted identifier in order to access EHR data.

[0075] In another alternative embodiment, the unencrypted identifier Y is stored in the secure memory of device A. Using a security processor in device A's (e)SIM, the identifier Y is encrypted using credentials securely stored in the mobile phone itself (e.g., credentials that are part of the MNO's security domain or credentials part of another security domain). This should, of course, only be used if the SIM is properly registered in the core network and in NAS and AS security state (i.e., a valid UE according to 3GPP TS 23.401 section 4.3.12). Alternatively, a separate IPSec or HTTPS communication channel can be set up (e.g., using a pre-shared key or using the public key from an X.509 certificate received from the emergency entity and signed by a trusted certificate authority). Otherwise, no encryption is performed and the identifier Y is sent in the clear, which may make it vulnerable to security hacks.

[0076] The user may give permission to include the encrypted identifier X in all emergency calls and / or may provide some policy information (e.g. stored in the PCF), for example via an application on the mobile device (e.g. running as part of the SIM toolkit environment) or via the MNO's website, about what circumstances and / or for what phone numbers the encrypted identifier X is allowed to be sent as part of an emergency call. The logic of when to include the encrypted identifier X may also be programmed as part of the USIM application.

[0077] For enhanced security, device A can send encrypted identifier X to device B only if device A (or a core network function such as an MME) is provided with special credentials (e.g., emergency credentials sent by device B to device A as part of an X.509 certificate signed by a specific certificate authority), the authenticity of which can be verified by device A (or a core network function such as an MME) before sending encrypted identifier X. This can be part of the procedure described above if the mobile device is configured to wait for a special message (which may include such emergency credentials) before sending the encrypted medical identifier. Furthermore, for enhanced security, encrypted identifier X should be re-encrypted with new hash or credentials after it has been used as part of an emergency call (or after a specific predetermined time). Optionally, for enhanced security, encrypted identifier X can be sent between device A and device B over a separate IPSec or HTTPS-secured communication channel.

[0078] In another embodiment, the system consists of the following devices: Devices A, B and C are as above, while Device D is a mobile device used to make emergency calls, but is operated by a bystander or family member of the victim, rather than the victim themselves. This could also be a first responder who has just arrived at the scene. This is typically a mobile phone.

[0079] In one embodiment, the caller or first responder is asked to place an emergency call with the victim's mobile phone, which results in an encrypted identifier X being sent to the emergency entity to access the EHR information. This scenario is covered further above.

[0080] In another embodiment, the emergency entity (e.g., device B) receives the location of device D making the emergency call as typically provided during an emergency call (e.g., as specified in TS 23.167 section 7.6) because this is a mandatory legal requirement in many countries, such as the FCC's E911 Directive (see https: / / www.fcc.gov / general / 9-1-1-and-e9-1-1-services). After receiving the location of device D, device B can request service S to provide information about the nearest mobile devices in the vicinity of device D making the emergency call. For this purpose, device B can send the received location information to service S, or service S can request this information from a location service / organization in the core network (e.g., GMLC or E-SMLC, see, e.g., https: / / www.cisco.com / c / en / us / td / docs / wireless / asr_5000 / 20 / MME / b_20_MME_Admin / b_20_MME_Admin_chapter_011110.pdf). For this purpose, service S can issue a request to the eNB to which device D is connected to measure the locations of all mobile devices connected to the eNB (e.g., via LTE Positioning Protocol (LPP), Mobile Location Protocol (MLP), and / or Secure User Plane Location (SUPL)), after which the distances between said mobile devices and the location of device D are estimated and the device with the closest estimated distance is selected. Additional contextual information can be used, for example, by detecting a group, e.g., in the shape of a circle, forming around the victim. The victim's phone is likely to be located at the center of the circle.

[0081] In one embodiment of the system, to further reduce response time, the emergency entity can select the nearest first responder before dispatching. Here, the term first responder is used to mean a medical professional who provides first aid in an emergency. Such a professional is typically the professional to whom the emergency entity dispatches EHR data. However, the term "responder" as referred to in this specification can also refer to someone already at the scene of an incident, such as a caller who is not a victim but can provide first aid.

[0082] After determining that the user of device A is a victim and deriving the victim's medical and location information, device B can locate responders near the victim based on information obtained from the first responder's mobile device. In this embodiment, the responder's mobile device must share its location information with emergency entity device B. Furthermore, the first responders must provide additional information regarding their readiness at a given time, such as whether they are currently working on an emergency or making new requests to emergency entity device B. The first responders' level of expertise in handling a particular medical condition can also be periodically updated and provided to emergency entity device B. In this embodiment, emergency entity device B must automatically select an appropriate first responder in real time based on information obtained from the first responder. After selecting a first responder, emergency entity device B must confirm acceptance of the emergency request with the first responder. After accepting the emergency request, device B must share the victim's location and medical information with the first responder.

[0083] In one embodiment of the system, to better detect the distance between device D and device A, a special mode may be required for device A or D to measure the distance between A and D, for example, by using Wi-Fi® fine time measurements as specified in IEEE 802.11-2016, or by the MNO enabling LTE ProSe capabilities (as specified in 3GPP TS23.303 and TS24.334) in both devices A and D so that they can discover each other using an LTE sidelink D2D communication channel and perform distance measurements or proximity detection, for example, via PC5 or Wi-Fi® aware ranging. As another example, NFC or Qi could be used, for example, by having emergency medical dispatchers at a 911 / 112 emergency entity instruct the caller or first responder to pick up the victim's phone and hold it very close to their own phone to ensure that the nearest device is addressed. The NFC or Qi communication channel can be used to send a message to device A to initiate transmission of an encrypted identifier X. Such a message may include special credential information (e.g., emergency credential information as part of an X.509 certificate signed by a trusted certificate authority) whose authenticity can be verified by device A before sending the encrypted identifier X. More specifically, the NFC capabilities (e.g., as specified in RSP Architecture V2.2) of device A's (e)UICC can be used to send (e.g., PUSH) the encrypted identifier X to the NFC-enabled (e)UICC of first responder device Q. The interface application on device A's (e)UICC will ensure that network-related information (IMSI, PLMN, etc.) is not made accessible over the NFC channel to the application on device Q's NFC-enabled (e)UICC. Device Q, device B, or device C decrypts identifier X to generate decrypted identifier Y and then uses the decrypted identifier Y to retrieve the set of patient health records associated with identifier Y.

[0084] In another embodiment, the distance information and / or information about which device is closest to device D is communicated to device B via service S or device D. Upon receiving this information and determining that device A is the closest device to device D, device B can issue a request (e.g., via service S or another core network service) indicating to device A to send encrypted identifier X to device B. For this purpose, service S can send device A a paging message with this special request (which can be encrypted with special emergency credential information and includes a destination IP address or callee information). Upon receiving the special request, device A can send encrypted identifier X as part of an emergency call to device B. As another example, device A can send encrypted identifier X to service S or another core network service (e.g., as part of an RRC message or an (emergency) call setup message, or as a user-plaintext message to a specific destination IP address), which then forwards encrypted identifier X to device B.

[0085] In an alternative embodiment, device B issues a special request to device A via device D, which then forwards the request to device A via an LTE sidelink D2D communication channel or an NFC / Qi communication channel, and device A sends an encrypted identifier X to device D, which forwards the encrypted identifier X to device B.

[0086] In a third embodiment, the system consists of the following devices: Devices A and B have the same roles as above, but may or may not include encrypted credentials as part of the emergency call. The further mobile devices {D0, ..., Dn} can perform wireless ranging and / or angle finding using time difference of arrival (e.g., Wi-Fi® aware PC5) over ProSe sidelink channels, using Wi-Fi® fine time measurements (e.g., as part of Wi-Fi® aware ranging), using Bluetooth® angle of arrival detection, and / or ranging using wireless signal strength measurements (e.g., using PC5, Wi-Fi®, Bluetooth®).

[0087] In one embodiment, device B is communicatively coupled to service T operating in a core network of a mobile administrator. Service T can determine the location of device A and / or request location information, for example, from a location service / organization in the core network (e.g., GMLC or E-SMLC, see, e.g., https: / / www.cisco.com / c / en / us / td / docs / wireless / asr_5000 / 20 / MME / b_20_MME_Admin / b_20_MME_Admin_chapter_011110.pdf). Service T can further determine a set of mobile devices {K0, ..., Km} in the vicinity of device A, for example, by requesting a list of devices connected to the same eNB as device A (e.g., from the eNB itself, the MME, the GMLC, or the E-SMLC, or another core network service). The service T may further determine the capabilities of the devices {K0, ..., Km} (e.g., by requesting capabilities from an eNB, MME, or other core network service, or from the devices {K0, ..., Km} via a UECapabilityEnquiry RRC message) and select a subset {D0, ..., Dn} of the devices {K0, ..., Km} that are capable of performing radio ranging and / or angle estimation.

[0088] Service T sends a message Mx (0≦x≦n) to each mobile device Dx of the set of mobile devices {D0, ..., Dn}, where message Mx includes instructions and optional authentication credentials to participate in performing distance measurements and / or angle estimation with mobile device A, and service T further sends a message N to mobile device A, where the message includes instructions and optional authentication credentials to participate in performing distance measurements and / or angle estimation with mobile device {D0, ..., Dn}. Optionally, a pop-up is displayed, asking the device's user to approve participation in more accurate distance measurements. Alternatively, if the user is not prompted, their distance data is anonymized. Mobile device A and mobile devices {D0, ..., Dn} then perform distance measurements and / or angle estimation and send the results of the distance and / or angle measurements to service T. Service T (or other services of the core network or device A to which T is communicatively coupled) uses the received distance (and possibly angle) measurements to improve the position estimate of device A and inserts the improved position estimate as part of a cellular emergency communications session setup with destination device B (e.g., by an MME, GMLC, E-SMLC or other core network service / function).

[0089] In another embodiment, service T sends a request to the eNB to which device A is connected and all neighboring eNBs to participate in the distance measurement / angle detection, and preferably performs the distance measurement / angle detection not only by device A but also by devices {D0, ..., Dn}.

[0090] In an alternative embodiment, the emergency entity (i.e., device B) receives the location of device A making the emergency call as typically provided during the emergency call (e.g., as specified in TS 23.167 section 7.6) because this is a mandatory legal requirement in many countries, such as the FCC's E911 Directive (see https: / / www.fcc.gov / general / 9-1-1-and-e9-1-1-services). After receiving the location of device A, device B can request service T to provide a more accurate location estimate of device A making the emergency call. For this purpose, device B can transmit the received location information to service T, or service T can request such information from a location service / organization in the core network (e.g. GMLC or E-SMLC, see e.g. https: / / www.cisco.com / c / en / us / td / docs / wireless / asr_5000 / 20 / MME / b_20_MME_Admin / b_20_MME_Admin_chapter_011110.pdf), after which service T performs the above procedure and performs distance measurement and / or angle estimation using the set of devices {D0, ..., Dn} near device A.

[0091] In another alternative, the emergency call may be made via an indirect network connection using one or more relay devices (e.g., ProSe UE-UE relay, UE-Network relay, or multi-hop relay UE), whereby the mobile device making the emergency call acts as a remote UE (as specified in 3GPP TS 23.303). Not all relay devices are within the direct coverage / communication range of the eNodeB base station, but are attached to the network by relaying data between each other until it reaches a relay device (a so-called UE-Network relay) that can reach the network. However, all relay devices and the remote device making the emergency call may be able to participate in location estimation and distance measurement between each other. In one embodiment, these devices (and possibly all other devices reachable via an indirect connection via one or more of the relay devices) are instructed by the network to participate in distance measurement using the mechanism described above. In another embodiment, all devices through which the emergency call passes before reaching the eNodeB automatically turn on their distance measurement capabilities and perform distance measurements between the remote UE and the relay device, and possibly between the relay device and all previous relay devices in the indirect communication path, and this information is then collected and sent, for example together with the emergency call, to a location service in the core network.

[0092] Figure 3 illustrates a method for use with a mobile device configured for wireless communication in a mobile network, the mobile network, the medical database, the encrypted medical identifier, the emergency entity, and the mobile device itself, as described above with reference to Figure 1.

[0093] In the method, an emergency process is performed and begins at node (START) 501. In a first step (OBT) 502, the process obtains an encrypted medical identifier of the device user. For example, the medical identifier can be prepared by encrypting the medical identifier within a secure processor, e.g., the (e)SIM, of the mobile device. The encrypted medical identifier can be retrieved from the secure processor, e.g., the (e)SIM. Then, in step (VIC?) 503, the process determines that the user may be a victim of an emergency, for example, by detecting that a call has been made to an emergency number. If not, the process continues by monitoring for emergency instruction information, as indicated by the upward arrow. If so, the method proceeds to step (INC) 504 by including the encrypted medical identifier in an emergency message during the emergency call. Additionally, location information and other medical information, such as heart rate data obtained from the victim's mobile device, can be included. The process then ends at node (END) 505.

[0094] Figure 4 shows a method for use in an emergency entity to be located in a mobile network, the mobile network, the medical database, the encrypted medical identifier, the mobile device and the emergency entity itself being as described above with reference to Figure 1.

[0095] In the method, emergency processing is performed and begins at node (START) 601. In a first step (EMC) 602, an emergency call setup is detected. The method continues with step (DMV) 603 for determining the victim's mobile phone. If the victim's mobile phone is placing the emergency call, the mobile phone transmits an emergency message as described above. Thus, during the emergency call, in step (RCV) 604, the emergency message is automatically received from the mobile device, which determines that the user may be a victim of an emergency.

[0096] As another example, an emergency call may be coming to the emergency entity from another mobile device, such as a bystander, spectator, or emergency responder. In this case, step (DMV) 603 proceeds by determining which mobile device is the victim's mobile device. Various methods for locating the victim's mobile device have been described above, such as using location services to find the mobile device closest to the mobile device making the emergency call. Once the victim's mobile device is determined, a request message is transmitted over the network to the victim's mobile device. The request message requests that an encrypted medical identifier of the user of the corresponding mobile device be included in the emergency message. In this case, in step (RCV) 604, the emergency message is received from the mobile device that received the request message.

[0097] In step (REMI) 605, the method proceeds by retrieving an encrypted medical identifier from the emergency message. Then, in step (AMD) 606, the medical database is accessed to search at least one electronic health record (EHR) based on the encrypted medical identifier. The method then automatically selects a first responder based on real-time information, such as the first responder's location, readiness, expertise, etc., and automatically forwards information from the EHR to the emergency responder in step (FWD-MI) 607. Location information of the victim's mobile device may also be forwarded. Alternatively, the forwarding may be performed by an operator at the emergency entity, as indicated generally by arrow 610. The method ends at node (END) 608.

[0098] As will be apparent to those skilled in the art, many different ways of implementing the method are possible. For example, the order of the stages or steps can be changed, some stages can be performed in parallel, and further, other method steps can be inserted between stages. Such inserted steps may represent improvements to the method as described herein or may be unrelated to the method.

[0099] A computer program product is provided that is downloadable from a network and / or stored on a computer readable and / or microprocessor executable medium, having program code instructions for performing the above methods, connection sequences, security processes and other processes when executed on a computing device. Thus, the methods according to the present invention can be performed using software having instructions for causing a processor system to perform the respective methods.

[0100] Typically, the mobile device and emergency entity device interacting to perform the emergency call each comprise a processor coupled to a memory containing appropriate software code stored on the device, e.g., the software downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash (not shown). The devices may comprise, for example, a microprocessor and memory (not shown). As another example, the devices may be implemented in whole or in part in programmable logic, e.g., as a field programmable gate array (FPGA). The devices and server may be implemented in whole or in part as so-called application specific integrated circuits (ASICs), i.e., integrated circuits (ICs) customized for their specific application. For example, the circuits may be implemented in CMOS using a hardware description language, e.g., Verilog, VHDL, etc.

[0101] The software may include only steps performed by a particular sub-subject of the system. The software may be stored on a suitable storage medium, such as a hard disk, floppy disk, memory, etc. The software may be transmitted as signals along wires, wirelessly, or using a data network, e.g., the Internet. The software may be available for download and / or for remote use on a server. A method according to the present invention may be implemented using a bitstream arranged to configure programmable logic, e.g., a field programmable gate array (FPGA), to perform the method. It will be understood that the software may be in the form of source code, object code, a code intermediate between source and object code, such as a partially compiled form, or any other form suitable for use in implementing a method according to the present invention. One embodiment of a computer program product includes computer-executable instructions corresponding to each of the processing steps of at least one of the described methods. These instructions may be subdivided into subroutines and / or stored in one or more files, which may be statically or dynamically linked. Another embodiment of a computer program product includes computer-executable instructions corresponding to each of at least one means of the described systems and / or products.

[0102] FIG. 5a illustrates a computer-readable medium 1000 having a writable portion 1010 that includes a computer program 1020, the computer program 1020 including instructions for causing a processor system to perform one or more of the methods and processes described above with reference to FIGS. 1-4. The computer program 1020 may be embodied as a physical mark on the computer-readable medium 1000 or by magnetization of the computer-readable medium 1000. However, any other embodiment is also contemplated. Furthermore, while the computer-readable medium 1000 is illustrated here as an optical disk, it will be understood that the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to perform the methods described above.

[0103] FIG. 5b shows a schematic diagram of a processor system 1100 according to an embodiment of the apparatus or method described with reference to FIGS. 1-4. The processor system may comprise a circuit 1110, e.g., one or more integrated circuits. The architecture of the circuit 1110 is shown schematically in the figure. The circuit 1110 comprises a processing unit 1120, e.g., a CPU, for executing computer program elements for performing a method according to an embodiment and / or for implementing a module or unit thereof. The circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126, e.g., an antenna, a transceiver, a connector, or both. The circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the dedicated IC 1124, and the communication element 1126 may be connected to each other via an interconnect 1130, e.g., a bus. The processor system 1110 may be configured for wired and / or wireless communication using connectors and / or antennas, respectively.

[0104] It will be appreciated that, for clarity, the above description describes embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors may be used without departing from the invention. For example, functions shown to be performed by separate units, processors or controllers may be performed by the same processor or controller. Accordingly, references to specific functional units should be seen only as references to suitable means for providing the described functionality, rather than as indicating a strict logical or physical organization. The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these.

[0105] It should be noted that in this specification, the verb "comprise" or "include" does not exclude the presence of elements or steps other than those listed, and the use of "a" or "an" in the singular does not exclude the presence of a plurality of such elements. When preceding a list of elements, phrases such as "at least one" refer to the selection of all or any subset of the elements from that list. For example, the phrase "at least one of A, B, and C" should be understood to include A only, B only, C only, both A and B, both A and C, both B and C, or all of A, B, and C. Any reference signs do not limit the scope of the claims. The present invention can be implemented by both hardware and software. Several "means" or "units" may be represented by the same item of hardware or software, and a processor, possibly in cooperation with hardware elements, may fulfill the functions of more than one unit. Furthermore, the present invention is not limited to the embodiments, and the invention resides in each and every novel feature or combination of features described above or recited in mutually different dependent claims.

[0106] In summary, a mobile device and an emergency entity within a mobile network respond to emergency calls. The network is coupled to a medical database containing electronic health records for each individual. The mobile device is configured to obtain an encrypted medical identifier of a user of the device and, upon determining that the user may be a victim of an emergency, include the encrypted medical identifier in an emergency message during the emergency call. The emergency entity is configured to retrieve the encrypted medical identifier from the emergency message and access the medical database to retrieve at least one electronic health record based on the encrypted medical identifier and enable transfer of information from the electronic health record to emergency responders.

Claims

1. 1. A method for locating a first mobile device within an area, comprising: an emergency entity operating within a core network and coupled to a location service that determines a location of a mobile device within a geographic area based on a signal received from the mobile device, receiving a call from the first mobile device; requesting performance of a location estimate for the first mobile device; the emergency entity or the location service; determining a set of mobile devices by selecting mobile devices that are capable of performing wireless distance measurements and / or angle estimations in the vicinity of the first mobile device; sending a message to each mobile device of the determined set instructing it to perform wireless distance measurement and / or angle estimation between itself and the first mobile device; The location service: receiving results of the wireless distance measurements and / or angle estimates from each mobile device of the set of mobile devices; and performing a position estimation for the first mobile device using the positions of each mobile device in the set of mobile devices and results of the wireless distance measurements and / or angle estimation.

2. The method of claim 1 , wherein the first mobile device is included in the determined set of mobile devices.

3. The method of claim 1 or 2, wherein determining the set of mobile devices in the vicinity of the first mobile device is by consulting a list of devices connected to the same parent station as the first mobile device.

4. 4. The method of claim 1, wherein determining the set of mobile devices in the vicinity of the first mobile device comprises determining capabilities of the mobile devices by requesting capabilities of the mobile devices via a UECapabilityEnquiry RRC message and selecting a mobile device capable of performing the radio distance measurement and / or angle estimation.

5. an emergency entity operating within a core network and connected to a location service that determines the location of a mobile device within a geographic area based on signals received from the mobile device, a receiver for receiving a call from the first mobile device; a controller that determines a set of mobile devices that are proximate to the first mobile device and that are capable of performing wireless ranging and / or angle estimation; a transmitter configured to transmit a message to each mobile device of the determined set instructing the mobile device to perform wireless distance measurement and / or angle estimation between the first mobile device and the determined set; The receiver receives a result of the location estimate of the first mobile device from the location service.

6. 1. A mobile device, comprising: a transmitter operating within the core network for transmitting a call to an emergency entity connected to a location service that determines the location of the mobile device within a geographic area based on signals received from the mobile device; a receiver for receiving a message from the emergency entity or the location service instructing the mobile device to perform wireless distance measurements and / or angle estimations between the mobile device and a set of nearby mobile devices; a transmitter for transmitting results of the wireless distance measurements and / or angle estimations to the location service for the location service to perform a location estimation of the mobile device.

7. A location service entity operating in a core network, comprising: the location service entity is configured to locate a mobile device within a geographic area based on signals received from the mobile device; receiving a request from an emergency entity coupled to the location service entity to perform a location estimate for a first mobile device; determining a set of mobile devices capable of performing wireless ranging and / or angle estimation in the vicinity of the first mobile device; sending a message to each mobile device of the determined set instructing it to perform wireless distance measurement and / or angle estimation between itself and the first mobile device; receiving results of the wireless distance measurements and / or angle estimates from each mobile device of the set of mobile devices; A location service entity that performs a location estimation for the first mobile device using the positions of each mobile device in the set of mobile devices and the results of the radio distance measurements and / or angle estimations.

8. The location service entity of claim 7, which transmits the result of the location estimation of the first mobile device to the emergency entity.

9. A location service entity operating in a core network, comprising: the location service entity is configured to locate mobile devices and relay devices within a region based on received signals from the mobile devices and relay devices; detecting, via one or more relay devices, a request from an emergency entity coupled to the location service entity to perform a location estimate for the first mobile device; determining a set of relay devices capable of performing wireless ranging and / or angle estimation in the vicinity of the first mobile device; sending a message to each relay device of the determined set instructing it to perform wireless distance measurement and / or angle estimation between itself and the first mobile device; receiving results of the wireless distance measurements and / or angle estimations from each relay device of the set of relay devices; a location service entity that performs a location estimation for the first mobile device using the position of each relay device of the set of relay devices and the results of the radio distance measurements and / or angle estimations;

10. 1. A method for locating a first mobile device within an area, comprising: an emergency entity operating within a core network and coupled to a location service that determines a location of a mobile device within a geographic area based on a signal received from the mobile device, receiving a call from the first mobile device; sending a request to the location service to perform a location estimate of the first mobile device; the emergency entity or the location service; determining a set of mobile devices capable of performing wireless ranging and / or angle estimation in the vicinity of the first mobile device; sending a message to each mobile device of the set of mobile devices instructing it to perform wireless distance measurement and / or angle estimation with the first mobile device; The location service: receiving results of the wireless distance measurements and / or angle estimates from each mobile device of the set of mobile devices; performing a position estimation for the first mobile device using the positions of each mobile device in the set of mobile devices and the results of the wireless distance measurements and / or angle estimations; transmitting a result of the position estimate of the first mobile device to the emergency entity.

11. The method of claim 10 , wherein the first mobile device is included in the determined set of mobile devices.

12. The method of claim 10 or 11, wherein determining the set of mobile devices in the vicinity of the first mobile device includes consulting a list of devices connected to the same parent station as the first mobile device.

13. 13. The method of claim 10, wherein determining the set of mobile devices in the vicinity of the first mobile device comprises determining capabilities of the mobile devices by requesting capabilities of the mobile devices via a UECapabilityEnquiry RRC message, and selecting a mobile device capable of performing the radio distance measurement and / or angle estimation.

14. an emergency entity operating within a core network and connected to a location service that determines the location of a mobile device within a geographic area based on signals received from the mobile device, a receiver for receiving a call from the first mobile device; a controller that determines a set of mobile devices that are proximate to the first mobile device and that are capable of performing wireless ranging and / or angle estimation; a transmitter configured to transmit a request to the location service to perform a position estimation of the first mobile device, and to transmit a message to each mobile device of the set of mobile devices instructing the mobile device to perform wireless distance measurement and / or angle estimation between the first mobile device and the set of mobile devices; The receiver receives a result of the location estimate of the first mobile device from the location service.

15. 1. A mobile device, comprising: a transmitter operating within the core network for transmitting a call to an emergency entity connected to a location service that determines the location of the mobile device within a geographic area based on signals received from the mobile device; a receiver for receiving a message from the emergency entity or the location service instructing the mobile device to perform wireless distance measurements and / or angle estimations between the mobile device and a set of nearby mobile devices; a controller for performing the wireless ranging and / or angle estimation; The transmitter transmits the results of the wireless distance measurements and / or angle estimations to the location service for the location service to perform a location estimate of the mobile device.

16. A location service entity that communicates wirelessly within a mobile network, comprising: the mobile network providing wireless communication for mobile devices according to a network communication protocol over at least a geographical area; the network communication protocol allows an emergency call to be initiated when the first mobile device performs an emergency action; the location service entity is configured to locate a mobile device within the region based on a received signal from the mobile device; upon receiving an emergency call from the first mobile device; determining a set of second mobile devices capable of performing wireless distance measurements and / or angle estimation in the vicinity of the first mobile device; sending a message to each mobile device of the set of second mobile devices instructing them to perform wireless distance measurements and / or angle estimations between the first mobile device and the set of second mobile devices; receiving results of the wireless distance measurements and / or angle estimates from each mobile device in the second set of mobile devices; A location service entity that performs a location estimation for the first mobile device using the position of each mobile device in the set of second mobile devices and the results of the radio distance measurements and / or angle estimations.

17. The location service entity of claim 16, which transmits the result of the location estimation of the first mobile device to an emergency entity.

18. A location service entity operating in a core network, comprising: the location service entity is configured to locate mobile devices and relay devices within a region based on received signals from the mobile devices and relay devices; detecting, via one or more relay devices, a request from an emergency entity coupled to the location service entity to perform a location estimate for the first mobile device; determining a set of relay devices capable of performing wireless ranging and / or angle estimation in the vicinity of the first mobile device; sending a message to each relay device of the determined set instructing it to perform wireless distance measurement and / or angle estimation between itself and the first mobile device; receiving results of the wireless distance measurements and / or angle estimations from each relay device of the set of relay devices; a location service entity that performs a location estimation for the first mobile device using the position of each relay device of the set of relay devices and the results of the radio distance measurements and / or angle estimations; 19. The location service entity of claim 18, which transmits the result of the location estimation of the first mobile device to the emergency entity.

20. A computer program downloadable from a network and / or stored on a computer readable medium, the computer program comprising program code instructions for carrying out the method of any one of claims 1 to 4 and 10 to 13 when the computer program is executed on a computing device.

Images