Accessing Health Information During an Emergency Call

The system provides secure, rapid access to EHRs using encrypted medical identifiers on mobile devices, addressing the complexity and privacy concerns of existing emergency access methods, enhancing emergency response efficiency.

CN113767384BActive Publication Date: 2025-07-15KONINKLIJKE PHILIPS NV
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202080032495.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-04-30
Filing Date
2020-04-20
Publication Date
2025-07-15
Estimated Expiration
2040-04-20

AI Technical Summary

Technical Problem

In emergencies, prior art has difficulty accessing individual electronic health records (EHRs) quickly and securely, and relying on mobile network operators (MNOs) may violate privacy protection requirements.

Method used

By using an encrypted medical identifier in a mobile device, a secure processor is used to transmit the encrypted medical identifier to the emergency entity during an emergency call, which then accesses the medical database based on the identifier to obtain EHR information and pass it to the emergency responder.

Benefits of technology

It realizes rapid and secure access to and transmit patients' EHR information in emergencies, reduces information acquisition time, protects privacy, and avoids direct participation of MNO.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113767384B_ABST
    Figure CN113767384B_ABST
Patent Text Reader

Abstract

A mobile device (110) and an emergency entity (120) in a mobile network (130) are adapted for emergency calls. The network is coupled to a medical database (140) including corresponding electronic health records (EHRs) regarding corresponding persons. The mobile device is arranged to obtain an encrypted medical identifier of a user of the device; and, after determining that the user may be a victim of an emergency, include the encrypted medical identifier in an emergency message during an emergency call. The emergency entity is arranged to retrieve the encrypted medical identifier from the emergency message and access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record so as to enable forwarding of information from the electronic health record to a responder to the emergency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a mobile device arranged for wireless communication in a mobile network, which provides wireless communication for the mobile device across at least local areas 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. The emergency call is set to be initiated when the mobile device performs an emergency action, such as calling an emergency phone number 112 or 911. The network is coupled to a medical database, which includes corresponding electronic health records (EHRs) of corresponding persons, and each person has a corresponding medical identifier that links the person to the corresponding electronic health record. The present invention also relates to an emergency entity and a network entity, and methods used in such devices and entities.

[0002] The present invention relates to the field of well-known local area mobile communication systems, which may be referred to as a core network, such as, for example, a 3G, LTE, 4G, or 5G network. Access to the core network is managed by a so-called provider or mobile network operator (MNO), which uses a set of subscriber data called subscriber identity SI to provide access to the core network for a subscriber's mobile device. For a corresponding subscriber of the provider, the SI includes subscriber identity data for accessing the core network. A mobile device, such as a smartphone, is typically equipped with a dedicated transceiver for communicating with the core network and is also provided with the subscriber identity SI. The SI represents the identity of the subscriber and additional data required to access the core network, and the use of the core network is charged by the provider to the corresponding 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). Usually, the SI is provided for such a device by inserting a physical semiconductor module called a SIM into the mobile device. The SIM card is an integrated circuit embedded in a plastic card, which is designed to securely store the International Mobile Subscriber Identity (IMSI) code and its associated keys, which are used to identify and authenticate subscribers on mobile phone devices (such as mobile phones and computers). Various types of modules or cards are known, such as a USIM, which refers to a Universal Subscriber Identity Module and is applicable to the UMTS Universal Mobile Telecommunications System, which is a 3G core network standard. The related physical card is also called a UICC (Universal Integrated Circuit Card), and the USIM is an application running on top of the UICC. Another type of SIM is called an e-SIM or eSIM (Embedded SIM) or an embedded universal integrated circuit card (eUICC). It is an irreplaceable embedded chip directly soldered to the circuit board. Currently, any type of device equipped with wireless communication with the core network and provided with SI via a SIM card or otherwise is referred to as a SIM device in this document. Background Art

[0003] The document "Mobile SIM-based Medical Applications, Michael J. Kleeman, Martin Harris and James Erasmus, GSMA, February 2015" shows some mechanisms that allow access to medical information stored on a device's SIM card by using standardized SIM toolkit applications. However, only a limited amount of medical information can be stored on the SIM, and controlling access is complex, as set out in the document. In particular, privacy may be a concern.

[0004] However, during an emergency, every second counts. It often takes time to identify a patient and provide relevant medical information about that patient (such as medical history, medication use, whether the patient wishes to be resuscitated, etc.) to first responders such as ambulance personnel. It is becoming increasingly common for such information to be stored in the electronic health record (EHR) of an individual somewhere in a medical database. It would be highly beneficial if this information were readily available to emergency responders such as health workers or doctors arriving at the scene of an emergency.

[0005] The mechanisms and organizational structures described in the above document for deploying standardized SIM toolkit applications are very complex. It would be beneficial to have a simpler solution for accessing electronic health records in an emergency to enable forwarding of information from the electronic health record to responders to an emergency such as the police or ambulance personnel. Summary of the Invention

[0006] It would be beneficial to use the time between the moment an emergency call is made to an emergency entity and the moment a first responder arrives at the scene to retrieve the necessary information from the EHR and provide that information to the first responder before the first responder arrives at the accident scene. The above document does not describe any mechanism for handling emergency calls. It would also be beneficial, for privacy and confidentiality reasons, if such data were provided, not to rely on the MNO knowing the identity or credentials used to access the EHR, or for the MNO to be able to access the EHR. Importantly, emergency calls are handled differently from normal calls and may be less secure, and may not involve user identity, i.e., anyone should be able to call an emergency phone number without a subscription. Therefore, security is an important consideration to prevent any sensitive information related to an individual's EHR from falling into the wrong hands.

[0007] An object of the present invention is to provide a system for reliably accessing an EHR in an emergency, taking into account the above aspects.

[0008] For this purpose, there is provided an apparatus and a method as claimed in the appended claims. According to one aspect of the invention, there is provided a mobile device as claimed in claim 1. According to another aspect of the invention, there is provided an emergency entity as claimed in claim 7 and a network entity as claimed in claim 12. According to another aspect of the invention, there are provided methods as claimed 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 storable on a computer-readable medium and / or a microprocessor-executable medium, the product comprising program code instructions for implementing the above methods when executed on a computer.

[0009] The mobile device is arranged for wireless communication in a mobile network. The mobile network provides wireless communication for the mobile device across at least a local 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, and an emergency call setup is initiated in the case of an emergency operation being performed by the mobile device, for example, the caller dials a regional emergency number, such as 112 or 911, or a mobile device embedded in a vehicle may dial after detecting an accident based on a strong deceleration.

[0010] The network is coupled to a medical database including corresponding electronic health records (EHRs) of corresponding persons. The medical database may be provided by a mobile network operator or on a server coupled to the network, but the medical database may also be accessed via another network or device (e.g., operated by the emergency entity), for example, through a dedicated coupling device or link.

[0011] Each person has a corresponding medical identifier that links the person to the corresponding electronic health record. It should be noted that the medical identifier is different from the subscriber identity because the SI is basically public and already known to the network and the network operator. Known SI data, such as the SIM card unique identifier (i.e., the International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI), or Globally Unique Temporary UE Identity (GUTI)), is not suitable for accessing the medical database in this way because privacy aspects cannot be taken into account. It also makes it difficult for the user to switch to another network operator. In an embodiment, the medical identifier is encrypted using a security certificate unknown to the network operator, and only the emergency entity or a healthcare provider or a first responder has access to the key material to decrypt the medical identifier. The encrypted medical identity may include medical credentials for accessing the electronic health record or a specific electronic health record for an emergency of the corresponding person. Moreover, accessing the medical database may be based on a combination of subscriber identity data and the encrypted medical identity, and may be based on security credentials (e.g., passwords, pre-shared keys, private keys) known to the emergency entity, the user, the network operator, the healthcare provider, the first responder, or a combination thereof.

[0012] The emergency entity is arranged to retrieve an encrypted medical identifier from an emergency message and access a medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR) to enable forwarding of information from the electronic health record (EHR) to emergency responders. The emergency entity can be arranged to decrypt the encrypted medical identifier, for example, by providing key material to the medical entity. Various systems for encrypting medical identifiers are known, such that, for example, a public key is used to encrypt the medical identifier while the corresponding private key is provided to the emergency entity. Alternatively, the key material may only be available and processed at the medical database and only a limited group of people are given access to it (e.g., by username / password login).

[0013] The mobile device includes a network communication unit for enabling a call via a network and a security processor arranged to obtain an encrypted medical identifier of a user of the device; and, in the case where it is determined that the user may be a victim of an emergency, include the encrypted medical identifier in an emergency message during an emergency call. For example, the mobile device can access a local secure storage in the device, such as on a SIM card, to retrieve the encrypted medical identifier. Also, the mobile device can access a secure storage via the network, such as a home subscriber server (HSS) resident at the mobile operator that maintains a database that provides subscriber details to other entities within the cellular network. Also, as part of the obtaining, the mobile device can encrypt the medical identifier to generate an encrypted medical identifier (e.g., by configuring encryption credentials on the phone by virtue of an application (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 effects. HER identification data is received as part of a cellular emergency communication session setup. Immediate access to the EHR of the victim of an emergency is enabled, such that no time is wasted between receiving the emergency message and obtaining life-saving patient health information for use by first responders. The beneficial effects require that the person in distress has previously prepared to allow emergency responders access to their EHR information, such as storing the HER, adding the emergency entity and / or the emergency response team (such as ambulance personnel) to the list of organizations and people who can access the EHR information, exchanging security credentials with the emergency entity and providing the above elements for his / her mobile device to include the encrypted medical identifier in the emergency message during an emergency call. Advantageously, making such preparations in advance enables privacy considerations to be taken into account while using a dedicated encrypted medical identifier to avoid possible misuse.

[0015] The network can provide location services for determining the corresponding location of a corresponding mobile device in a local area. Moreover, the network can be arranged to implement the transmission of a request message to the corresponding mobile device, the request message requesting an encrypted medical identifier of the user of the corresponding mobile device to be included in an emergency message.

[0016] In an embodiment, in the case of an emergency call made by a second mobile device outside the mobile device of a user who may be a victim of an emergency, the emergency entity can be arranged 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. The emergency entity can now determine which mobile device may be the mobile device of the victim of the emergency, for example, the device closest to the second mobile device. The caller at the second mobile device can assist in determining which mobile device belongs to the victim, for example, by moving the second mobile device towards the victim. The emergency entity can instruct the person making the call to move to the victim (or his / her phone) or stay very close to the victim (or his / her phone).

[0017] In an embodiment of the mobile device, to determine that the user may be a victim of an emergency, the security processor is arranged to receive the request message. In the case of receiving such a message, the mobile device determines that the user may be a victim of an emergency and includes the encrypted medical identifier in the emergency message. Advantageously, even in the case where the person making the call is not the victim, EHR identification data may be automatically retrieved from the victim's phone.

[0018] In an embodiment, wherein the mobile device is arranged to perform distance measurements between the mobile device and another mobile device, the security processor is arranged to implement distance measurements in an emergency and transmit the measured distances to the network for determining enhanced location data of the mobile device. For example, the location service and / or the emergency entity and / or the second device making the emergency call can be arranged to generate at least one distance measurement message. Such a distance measurement message requests at least one distance measurement to be performed between the mobile device and at least one other mobile device located nearby and transmits at least one measured distance to the location service and / or the emergency entity for determining enhanced location data of the mobile device. In addition, the security processor can be arranged to receive the distance measurement message and implement the distance measurement. Advantageously, due to at least one measured distance to other located devices, the location of the victim's mobile device can be determined with enhanced accuracy. The enhanced location data can be forwarded to the responder to improve the location of the victim.

[0019] In an embodiment, a network entity arranged in a mobile network is arranged to receive identity data from a mobile device participating in an emergency call setup 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. The emergency message including the encrypted medical identifier is transmitted to an emergency entity. For example, the IMEI may be used as the identity data and may be linked to the encrypted medical identifier, for example, by the user registering his device through some kind of registration service provided by the mobile operator and linking it to the encrypted medical identifier.

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

[0021] A non-transitory form of the computer program product may include non-transitory program code modules stored on a computer-readable medium for performing the method according to the invention when the program product is executed on a computer. In one embodiment, the computer program includes computer program code modules adapted to perform all steps or stages of the method according to the invention when the computer program runs on a computer. Preferably, the computer program is embodied on a computer-readable medium. There is also provided a transient form of the computer program product, which can be downloaded from a network and / or stored in a volatile computer-readable memory and / or a microprocessor-executable medium, and the product includes program code instructions for implementing the above method when executed on a computer.

[0022] Another aspect of the invention provides a method for making a computer program available for download in a transient form. This aspect is used when the computer program is uploaded to, for example, the Apple App Store, the Google Play Store, or the Microsoft Windows Store, and when the computer program is available for download from such stores.

[0023] Further preferred embodiments of the device and method according to the invention are given in the appended claims, the disclosure of which is incorporated herein by reference. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1Shows a mobile device and an emergency entity as well as a network for wireless communication,

[0026] Figure 2 Shows an example of a system having a mobile device, a network entity, an emergency entity, and a network for wireless communication,

[0027] Figure 3 Shows a method used in a mobile device arranged for wireless communication in a mobile network,

[0028] Figure 4 Shows a method used in an emergency entity to be arranged in a mobile network,

[0029] Figure 5a Shows a computer-readable medium, and

[0030] Figure 5b Shows a schematic representation of a processor system.

[0031] These figures are purely illustrative and not drawn to scale. In the drawings, elements corresponding to elements already described may have the same reference numerals. Detailed Description

[0032] Figure 1 Shows a mobile device and an emergency entity as well as a network for wireless communication. In communication system 100, mobile device 110 is arranged to perform wireless communication in mobile network 130 according to a network communication protocol. For example, the mobile device may be a mobile phone, a wearable medical device, or a data communication unit embedded in a vehicle. In this communication system, subscriber identity SI includes subscriber identity data for a subscriber to access the core network, and this mobile network provides wireless communication for the mobile device across at least one local area. As elaborated in the introduction, the mobile network may be a 3G, LTE, 4G, or 5G cellular core network. Figure 1 Schematically shows network 130 for providing a communication channel between emergency entity EM-ENT 120 and mobile device MOB-DEV 110. The core network is managed by at least one telecommunications provider, for example for managing subscriber databases and billing. The network is also coupled to medical database EHR 140, for example provided on a separate server on the Internet, or provided by a healthcare organization or an emergency entity, and is coupled to the network in a wireless and / or wired manner or via a dedicated link.

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

[0034] The emergency entity 120 has a security processor 122 arranged to perform the emergency operations set forth below and a network communication unit 121 arranged for wireless communication with the network or communication via a wired link.

[0035] The medical database 140 contains corresponding electronic health records (EHRs) for corresponding persons, with each person having a corresponding medical identifier that links the person to the corresponding electronic health record. The network is coupled to the medical database.

[0036] The network communication protocol enables calls between subscribers of the network, which includes emergency calls between the mobile device and the emergency entity 120. The emergency call setup is initiated in the case of the mobile device performing an emergency action.

[0037] The security processor 122 in the emergency entity is arranged to retrieve the encrypted medical identifier from the emergency message. In the case where the encrypted medical identifier is retrieved, the security processor proceeds to access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR) in order to enable forwarding of information from the electronic health record (EHR) to the responder to the emergency. The selection of the responder to the emergency may occur automatically based on the responder's situation, such as location, expertise, availability, preferences, etc., which is derived from corresponding information retrieved from the responder's mobile device. The forwarding of the HER data may be automatically routed to the mobile device of the responder to the emergency, such as an ambulance. Also, the selection of the responder and the forwarding of the EHR information may be performed by a human operator presented at the emergency entity, such as by calling the medical staff on an ambulance.

[0038] The security processor 116 in the mobile device is arranged to obtain the encrypted medical identifier of the user of the device and also include the encrypted medical identifier in the emergency message during an emergency call in the case where it is determined that the user may be a victim of an emergency. Various practical embodiments are set forth below.

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

[0040] In another practical embodiment, a second mobile device D makes an emergency call instead of the victim's mobile device. In this case, the system with devices A, B, and C is the same as described above. Thus, the second mobile device D establishes a cellular emergency communication session with destination device B (the emergency entity). Device B is communicatively coupled to a location service S operating in the mobile operator core network. The location service S is capable of determining which mobile device is closest to the device making the call. Device B requests service S to determine the mobile device A that is closest to the device making the call, and in the event of the determination of mobile device A, and subsequently issues a request for device A to send the encrypted identifier X as part of the cellular emergency communication session setup to device B. Alternatively or additionally, an additional communication session with service T or device D can be used, and service T or device D in turn forwards the encrypted identifier X to device B. Device B receives and processes the encrypted identifier X as described above.

[0041] In an embodiment, to determine that a user may be a victim of an emergency, a security processor is arranged to perform one or more of the following options. Optionally, the security processor can determine that an emergency call is being made via the network communication unit, for example, by detecting that a regional emergency number is being called or receiving data indicating that an emergency call is set from the processor 112 of the mobile device.

[0042] Optionally, the security processor can detect one of the following situations to determine that a user may be a victim of an emergency, and if it is not possible to detect automatically, the emergency entity may require some additional checks or procedures, which may be different (e.g., asking different questions or requiring the user to perform a specific action on the device), depending on whether the device that made the emergency call supports the ability to include a medical identifier. To this end, a message or an attribute / flag as part of the message can be sent to the emergency entity via the emergency communication, which indicates the device's ability to include a medical identifier and possibly sensor information or other information about a situation that the device is unable to detect.

[0043] Optionally, after detecting any of the following situations, the victim's mobile phone can broadcast some messages (e.g., via Wi-Fi) indicating that it is the victim's mobile phone. If another device makes a call to an emergency number, the other device may start listening for these messages from other nearby phones (e.g., via Wi-Fi) and use this to determine whether the user of the other device is a victim of an emergency or someone else nearby.

[0044] Optionally, the security processor can detect a decelerating acceleration above a predetermined limit, such as detecting a car accident or the user falling or being hit. Additionally, if a fall is detected by the mobile device just before calling an emergency number, the user of the mobile device may be the victim, and thus the mobile device can automatically include an encrypted medical identifier. Moreover, if a car that has just been in an accident makes an automatic emergency call (eCall), the mobile unit in the car may automatically include the encrypted medical identifier of the driver. Also, the car control system can be arranged to determine who the driver is and possibly other passengers, and include one or more encrypted medical identifiers.

[0045] Optionally, the security processor can detect an abnormality in the user's vital sign sensors. The vital sign sensors on the mobile device can detect major health problems (e.g., a heart attack). Usually, this may generate an alert or warning condition. Thus, if this occurs before calling an emergency phone, the mobile device may automatically include an encrypted medical identifier. Therefore, optionally, the security processor can detect an alert condition as generated by another processor in the mobile device or an external source. The external source can be a car.

[0046] Optionally, the security processor can receive user input regarding an emergency. For example, the UI on the mobile device can show whether the user is a victim of an emergency or questions about the nature of the emergency. For example, the question may be whether the caller or bystander is the victim. Also, the mobile device may have voice recognition, such as distinguishing whether the caller says "I was in an accident" or "I saw an accident". Based on the result, the security processor can automatically include or not include the encrypted identifier. Also, the mobile device may have some pre-configured rule sets (e.g., set by the user). For example, the rule can be to include the encrypted identifier only when calling an emergency number if the user does not press the "Do not include identifier" button within 10 seconds after starting the call.

[0047] Optionally, the security processor may receive user input regarding including an encrypted medical identifier in an emergency message. For example, the user may indicate so or confirm the transmission of medical data to an emergency entity, such as a device may present a question asking whether the caller wants to include an encrypted medical identifier. Also, the mobile device may tell the user via voice communication to press a key (e.g., press "1") to include an encrypted medical identifier. Optionally, the user may give a general "user consent", i.e., the user may consent to always include an encrypted medical identifier, not only when being a victim of an emergency.

[0048] Optionally, the security processor may be arranged to receive a message from an emergency entity. Such a message may request entry of additional data regarding the emergency or the victim. Optionally, the emergency entity may send a special message regarding whether to include or not include an encrypted medical identifier, for example, within 20 seconds. The mobile device may be arranged to wait until it receives the message before sending the encrypted medical identifier. To this end, the emergency dispatcher may press different buttons on the screen when evaluating the situation regarding the caller and the victim, and then send the corresponding special message. Based on whether the caller is the victim, the special message may include different authentication credentials, which may be used as a trigger for sending the encrypted medical identifier.

[0049] Optionally, the security processor may receive a message from the network that no other mobile phone is within the bystander range. For example, the network may detect that there is no one else within 100 meters except the caller. If so, then the caller is likely to be the victim, and thus an identifier needs to be included, which may be passed to the mobile device. In the case where the user of the mobile device is determined to be the victim, the mobile device may automatically turn on accurate location services, such as GPS, for example, the GPS of the mobile device in the user's vehicle, on the mobile device or on another mobile device near the user, to identify the accurate location of the user and automatically include the location information of the user in the emergency call. Optionally, other location services on the mobile device that can help accurately locate the user, such as Wi-Fi assisted GPS, may be turned on and automatically used to identify the accurate location of the user, such as less than 10 meters.

[0050] The network may provide location services for determining the corresponding location of the corresponding mobile device in the local area. Also, the network may be arranged to implement the transmission of a request message to the corresponding mobile device, which requests including the encrypted medical identifier of the user of the corresponding mobile device in the emergency message.

[0051] In an embodiment, the mobile device 110 is arranged to perform distance measurements between the mobile device and another mobile device; and the security processor 116 is arranged to implement distance measurements in an emergency situation and transmit the measured distance to the network for determining enhanced location data of the mobile device. By receiving one or more distance measurement results between the mobile device and other positioning devices, the location service and / or the emergency entity are enabled to enhance the accuracy of the location data of the mobile device. In fact, the location data transmitted based on reception from the mobile device is not very accurate, for example having a tolerance of 100 m. In contrast, local distance measurements are much more accurate, for example having a tolerance of 1 m. Combining the locations of multiple mobile devices with the distances between such positioned devices can increase the accuracy of the location data.

[0052] 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 running in the core network of the mobile operator. Service T is capable of determining a set of mobile devices {D0,..., Dn} located near device A and capable of performing wireless distance measurements and / or angle estimations. Service T sends a message Mx (0 ≤ x ≤ n) to each of the mobile devices Dx in the set of mobile devices {D0,…,Dn}, the message Mx containing instructions and optionally also authorization credentials to participate in performing distance measurements with mobile device A, and also sends a message N to mobile device A, containing instructions and optionally also authorization credentials to participate in performing distance measurements with the mobile devices {D0,…,Dn}. Mobile device A and the mobile devices {D0,…,Dn} then perform distance measurements and / or angle estimations and send the results of the distance and / or angle measurements to service T. Service T (or the core network to which T is communicatively coupled or some other function in device A) 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 communication session setup with the emergency entity.

[0053] In an embodiment, in order to obtain an encrypted medical identifier, the security processor 116 in the mobile device is arranged to perform one or more of the following options.

[0054] Optionally, the security processor is arranged to encrypt medical identifier data based on key data during an emergency call. The key data can be stored in a secure storage memory in the device, for example in the SIM card.

[0055] Optionally, the security processor is arranged to receive authentication data for verifying a request from a trusted party to send the encrypted identifier. For example, the emergency entity can first send its authentication data to the mobile device.

[0056] Optionally, the security processor is arranged to retrieve medical identifier data or encrypted medical identifiers from a remote server accessible via the network communication unit by the security processor. For example, in an emergency situation, a subscriber may have pre-stored medical identifier data or encrypted medical identifiers on the HSS.

[0057] In an embodiment, in order to obtain an encrypted medical identifier, the security processor in the mobile device is arranged 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 time period. This re-encryption avoids malicious parties reusing the initially encrypted medical identifier.

[0058] In an embodiment, the emergency entity may be arranged to, in the case of an emergency call made by a second mobile device outside the mobile device of a user who may be a victim of an emergency situation, locate at least one mobile device near the second mobile device via a location service; and generate a request message for the located mobile device. The emergency entity can now determine which mobile device may be the mobile device of the victim of the emergency situation, for example, the device closest to the second mobile device. The caller at the second mobile device can assist in determining which mobile device belongs to the victim, for example, by moving the second mobile device towards the victim. The emergency entity may instruct the person making the call to move to the victim (or his / her phone) or stay very close to it. Optionally, the security processor in the emergency entity may be arranged to select one of the at least one located mobile devices based on the position of the selected mobile device being closest to the second mobile device. Moreover, the security processor in the emergency entity may be arranged to select one of the at least one located mobile devices based on the positions of a plurality of located mobile devices constituting a bystander pattern around the selected mobile device.

[0059] In an embodiment, the security processor 122 in the emergency entity may be arranged to select one of the at least one located mobile devices based on a request for the operator of the second mobile device to move the second mobile device closer to the mobile device of the victim while other mobile devices are further away. Moreover, the security processor 122 in the emergency entity may be arranged to send a call setup request to the selected mobile device to generate a call signal from the selected mobile device so that the operator of the second mobile phone can confirm that the selected mobile device phone is at the victim.

[0060] In an embodiment, the security processor 122 in the emergency entity is arranged to select one of the at least one located mobile devices based on sending biometric property data to a second mobile phone, so that the operator of the second mobile phone can confirm that the biometric data corresponds to a victim having the selected mobile phone. Additionally, the security processor 122 in the emergency entity may be arranged to request the operator of the second mobile phone to obtain biometric property data of the victim for transmission of the obtained property data to the emergency entity.

[0061] For example, if the person calling via the second mobile device is not the victim, then regardless of using one or more location mechanisms to determine that the nearest device within range is the victim, additional checks may still be required to determine whether the correct person's EHR information is being processed. Of course, if the person consciously checks the person's name and the person's name is part of the patient's EHR information, that would be sufficient. If the person is unconscious, the additional checks can include sending information about physical characteristics based on the patient's EHR information, such as gender, age, hair color, eye color, size, weight, and may also include pictures stored as part of the patient's HER to the second mobile device. Now, the caller or the first responder arriving at the scene can use the received information / pictures to determine whether the victim is indeed the person corresponding to the information / pictures. Alternatively, the person making the call can send pictures of the victim and / or bystanders to the emergency entity to check whether the pictures in the EHR correspond to the victim. Thus, the pictures are sent to the dispatcher of the emergency entity and the dispatcher makes the identification. Alternatively, if the person is unconscious, the caller or the first responder arriving at the scene can be required 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), and then the fingerprint is cross-checked with the fingerprint stored as part of the HER to check whether the fingerprint indeed corresponds to the victim. As yet another alternative, the caller or the first responder can be instructed to find other information at the scene (e.g., by checking the victim's wallet) to identify the victim and see whether the name matches the patient name in the EHR information. As yet another alternative, the nearest device in the vicinity will issue an alert (e.g., start making a specific noise or display a message) and the device will call the emergency entity, including an encrypted identifier X for accessing the corresponding EHR information.

[0062] Figure 2 An example of a system having mobile devices, network entities, an emergency entity, and a network for wireless communication is shown. In the communication system 200, the mobile device MOB-DEV 110, the mobile network 130, and the emergency entity EM ENT 120 are as described above with reference to Figure 1 as described. The medical database EHR 240 is similar to Figure 1in the medical database 140, but is now directly coupled to the emergency entity. Alternatively, the medical database can be accessed via another network, such as via a local network coupled to the emergency entity or via another device coupled to the emergency entity.

[0063] Figure 2 Also shown is a network entity 210 coupled to the network. The network entity is arranged to receive identity data from a mobile device participating in an emergency call setup. Subsequently, the network entity is arranged 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, as further described below, the network entity can retrieve the encrypted medical identifier from an HSS (Home Subscriber Server; not shown). In an emergency situation, the subscriber may have pre-stored medical identifier data or the encrypted medical identifier on the HSS.

[0064] In the next section, a system for providing information from an electronic health record (EHR) to responders to an emergency is discussed. The system consists of the following devices:

[0065] · Device A is a mobile device operated by the victim. This could be a mobile phone, but could also be a vital signs monitoring device, a telemetry / ECG monitoring device, a smartwatch, a fall detector, or other types of portable devices. Alternatively, Device A could be a cellular network unit within a vehicle that is capable of making an emergency call (eCall) after a car accident.

[0066] · Device B is a telephone, laptop, or server device in the emergency entity, operated by an emergency medical dispatcher to receive and process a specific emergency call from Device A.

[0067] · Device C is an optional other device (such as a computer used by the emergency medical dispatcher, or a gateway or server device) to which Device B is connected and which provides access to a database with relevant patient health data.

[0068] In an embodiment, Device A has some local non-volatile storage that is secure and protected from general access by a general-purpose application processor, such as secure Micro-SD storage, or secure storage within the SIM or eSIM (also known as UICC and eUICC, respectively) of a mobile device, or a portion of a secure element in the device. Generally, these types of secure storage solutions are capable of hosting a set of applications and services in one or more secure domains (e.g., as specified in the GlobalPlatform Card Specification v2.2). For mobile devices, it is common to be equipped with an (e)SIM to enable access to cellular networks. According to the provisions of ETSI TS 102.221 and 3GPP TS 31.101, the secure storage of the (e)SIM is constructed according to a specific file structure and can be accessed using a set of standardized interface commands. The (e)SIM is typically also equipped with its own secure processor capable of performing encryption / decryption and other types of security functions.

[0069] Device B or Device C is associated with a database containing electronic health records. Given that such databases typically contain the health records of many different people, a person-specific identifier is required to access the records of a specific person. For security purposes, these records are protected by one or more passwords or security credentials. In one embodiment, an application (such as a website) associated with the database generates an identifier Y and a corresponding security credential S to allow access to the person's electronic health records in case of an emergency. In one embodiment, the identifier Y and the security credential S can be used to obtain access to all the information stored as part of the EHR. In another embodiment, the identifier and the corresponding credential can only be used to access a subset of the EHR information for emergency access, without having full access to all the data in the EHR.

[0070] In a further 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 an embodiment, the mechanism described in US8627103 is used for encryption and decryption, whereby a healthcare provider only gains access to the data decryption key (e.g., the credential S as described above) after an emergency proxy has been provided to it. The resulting encrypted identifier X and encrypted credential S' are stored in 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 the encryption key T.

[0071] In an embodiment, the encrypted identifier X and optionally also the encrypted credential S' are provided to the mobile network operator (MNO) subscribed to by the person to whom the EHR data belongs and are then stored by the MNO on the SIM, which is sent to the person, or provided remotely by the MNO as part of the MNO's eUICC profile, which is downloaded to the eSIM of the person's mobile device A, or securely transmitted over the air by the MNO using a proprietary interface. As specified in 3GPP TS 31.102, the encrypted identifier X is preferably stored as a basic file readable by the USIM application running on the (e)SIM. Similarly, for the encrypted credential S'. In an alternative embodiment, the encrypted identifier X and optionally also the encrypted credential S' are stored by another application running on the (e)SIM as part of the SIM toolkit within the same security domain as the USIM application, as specified, for example, in 3GPP TS 31.111. For example, the other application can be an application capable of reading a dynamic QR code containing the encrypted identifier X, which is generated by the network interface of the EHR database. For the encrypted credential S', this can be done in a similar manner.

[0072] In another embodiment, the encrypted identifier X is stored as a basic file in the (e)UICC under a non-network security domain (such as ECASD) instead of the security domain of the MNO used to connect to the mobile network. The interface application on the (e)UICC will access the encrypted identifier X through a secure channel established using a set of access rules (as specified in Globalplatform Card Specifications v2.3.1) between the security domains and will ensure that no network-related information (such as IMSI, PLMN) is accessible between the security domains (network access) (as specified, for example, in Applet isolation and object sharing in the Java Card 2.2x runtime environment). For the encrypted credential S', this can be done in a similar manner.

[0073] In another embodiment, the encrypted identifier X is stored as a basic file in the security domain of MNO.X instead of the security domain of MNO.Y, which is used to connect to the mobile network (such as a dual-SIM device, where one of the SIM cards has the encrypted identifier X and the other does not). The interface application on the (e)UICC will access the encrypted identifier X through a secure channel established using a set of access rules between different security domains (network access) and will ensure that no network-related information (such as IMSI, PLMN) is accessible between the security domains (network access). For the encrypted credential S', this can be done in a similar manner.

[0074] In an alternative embodiment, the encrypted identifier X is stored as a basic file in a secure element under a trust root different from the trust root of the (e)UICC. In the case of initiating an emergency call, the interface application on the (e)UICC will access the encrypted identifier X using the security parameters (such as a PIN code) of the secure domain (no network access), which is stored in the secure element under a trust root different from the trust root of the (e)UICC. (For example, the PIN code of the secure element provided by the owner of device A during initial setup). For the encrypted credential S', this can be done in a similar manner.

[0075] In another embodiment, the encrypted identifier X is stored as a basic file in a secure domain of the (e)UICC itself, which has not been provided with an MNO profile to connect to the mobile network (such as a blank (e)UICC). The interface application on the (e)UICC will access the encrypted identifier X stored under the secure domain of the (e)UICC and transmit it across the network. (For example, equivalent to an emergency call without a mobile subscription). For the encrypted credential S', this can be done in a similar manner.

[0076] In another embodiment, device A has an NFC interface and uses the NFC communication channel to transfer the encrypted identifier X and optionally also the encrypted credential S' from device W to device A, thereby using the NFC function of the (e)UICC (for example, as specified in the RSP architecture V2.2) for storing the encrypted identifier X and optionally also the encrypted credential S' on the (e)UICC under the MNO secure domain or in a secure domain hierarchy with authorization management privileges. It should be required that the interface application on the (e)UICC ensures that the NFC application storing the encrypted identifier X and optionally also the encrypted credential S' under a specific secure domain is trusted and authorized to modify the content under the specific secure domain on the (e)UICC (for example, based on the certificate authority of the secure domain).

[0077] In an embodiment, a cellular network unit in a vehicle is capable of making an eCall in the event of a vehicle accident. The cellular network unit may be equipped with multiple identifiers, such as those of all family members using the vehicle. When the vehicle's cellular unit makes an eCall to an emergency entity, since multiple family members may be involved in a vehicle accident, multiple encrypted identifiers may be sent to the emergency entity simultaneously as part of the eCall. Alternatively, once the eCall has been received by the emergency entity, the location of the vehicle making the eCall is matched with the location of one or more mobile devices in the immediate vicinity of the vehicle (e.g., mobile phones carried by one or more persons in the vehicle). If the location match is within a small error range (e.g., 2 meters), the mobile device(s) whose location matches that of the vehicle is considered to be owned by the victim(s). Alternatively, the emergency center may find the phone number of the mobile device(s) very close by through a service provided by the MNO and make a call to confirm what has happened and how many victims there are.

[0078] In another embodiment, Device A makes an emergency call to an emergency entity using GSM / CSMA / HSDP / LTE / 5G NR, which is routed / forwarded in the emergency entity to Device B. An emergency call is typically a call made to a national emergency number, such as 112 in Europe and 911 in the United States. Basically, the national emergency telephone number is stored and recognized by the mobile device, based on which the mobile device and the network can initiate special protocol operations related to the emergency call. The MNO has specific mechanisms in place to handle calls in emergency situations, such as those specified in Section 4.3.12 of 3GPP TS 23.401 (for 4G) and Section 5.16.4 of 3GPP TS 23.501 (for 5G), and generally specified in Section 10 of 3GPP TS 22.101). In this document, the emergency call is not limited to calling the national emergency number, but can also be other types of calls, such as a call to a hospital, where quick access to important patient health information is important and can be so identified. This can be achieved, for example, by providing the MNO with a set of specific telephone numbers (if a call is made to one of these telephone numbers, the encrypted identifier X should be sent to the said telephone number), or by having additional authentication / authorization steps as part of the telephone call (e.g., if the recipient can authorize itself to the MNO or the source device, only the encrypted identifier X is sent, or if the source device provides credentials to access a specific (private) network slice operated by, for example, a hospital, or by connecting to the network exposure function and / or policy control function (i.e., the NEF and PCF specified in 3GPP TS 23.501) via a secure API or by an application (i.e., the application function (AF) in 3GPP TS 23.501) through the lawful interception framework (e.g., as specified in 3GPP TS 33.106) to provide the necessary credentials.

[0079] In a further embodiment, as part of the emergency communication session setup, the encrypted identifier X is sent as a separate message or as an attribute or information element / sub-field within an existing message. The identifier can be inserted in the USIM application as part of the call setup procedure. If the Session Initiation Protocol (SIP) is used for call setup, then this can be done, for example, by using a field within the SIP invite or SIP registration message for the emergency service (as specified in 3GPP TS 23.167). The identifier can also be added as an additional URI parameter in the emergency SIP address, serving as the destination for the SIP invite / registration message. Alternatively, 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). In the case where the PLMN circuit switched network is used for call setup, then this can be added to a field within an attribute included, for example, in the emergency call, as specified in section A.1.2 of 3GPP TS 22.003.

[0080] In a further embodiment, the credential S or the encrypted credential S’ is also stored in the secure storage device of device A and is sent together with the encrypted identifier X as part of the emergency communication session.

[0081] In an alternative embodiment, the encrypted identifier X is sent to the Mobility Management Entity (MME), the Access and Mobility Function (AMF), or the Packet Data Network PDN Gateway, for example, as part of a field / attribute of a NAS attach request or NAS attach accept message and / or a PDN connection request for an emergency bearer. The respective 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).

[0082] In another alternative embodiment, the encrypted identifier X is not stored on device A itself, but in the core network, for example, as part of the Home Subscriber Server (HSS, as specified in TS 23.002) or of the generic 5G user identity service provided by the network operator. Once device A registers itself to the network, the MME obtains the information from the HSS and passes it during the connection setup with 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). This can of course only be used if the SIM is correctly registered to the core network (i.e., a valid UE according to section 4.3.12 of 3GPP TS23.401). Also, if the device is not fully registered to the network in an emergency situation, the network can still provide services where the user has previously linked the IMEI of their device or other identity to the encrypted identifier to access the EHR data.

[0083] In another alternative embodiment, the unencrypted identifier Y is stored in the secure storage device of device A. The identifier Y is encrypted using the secure processor in the (e)SIM of device A with credentials securely stored on the mobile phone itself (e.g., credentials that are part of the MNO security domain or part of the credentials of a separate security domain). This should of course only be used when the SIM is correctly registered to the core network and the NAS and AS security contexts are in place (i.e., a valid UE according to section 4.3.12 of 3GPP TS 23.401). Alternatively, a separate IPSec or HTTPS communication channel can be set up (e.g., using a pre-shared key or the public key from an X.509 certificate received from an emergency entity and signed by a trusted certificate authority). Otherwise, encryption will not occur and the identifier Y will be sent in plain text, which can make it vulnerable to security hackers.

[0084] The user can allow the encrypted identifier X to be included in each emergency call, and / or provide some policy information (e.g., stored in the PCF) regarding which situations and / or which phone numbers are allowed to have the encrypted identifier X sent as part of the emergency call, e.g., via an application on the mobile device (e.g., running as part of the SIM toolkit environment) or via the MNO's website. The logic for when to include the encrypted identifier X can also be programmed as part of the USIM application.

[0085] For additional security, only when device A (or a core network function such as the MME) is provided with special credentials (e.g., emergency credentials sent from device B to device A as part of an X.509 certificate signed by a specific certificate authority), device A can send the encrypted identifier X to device B, and its authenticity can be verified by device A (or a core network function such as the MME) before sending the encrypted identifier X. This can be part of the above process where the mobile device is arranged to wait for a special message (possibly including such emergency credentials) before it sends the encrypted medical identifier. Additionally, for additional security, the encrypted identifier X should be re-encrypted with a new hash or credentials after being used as part of an emergency call (or after a predefined time). Optionally, for additional security, the encrypted identifier X can be sent via a separate IPSec or HTTPS protected communication channel between device A and device B.

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

[0087] In one embodiment, the person making the call or the first responder may be required to pick up the victim's mobile phone to make an emergency call, such that an encrypted identifier X is sent to the emergency entity to access the EHR information. This scenario is further covered above.

[0088] In another embodiment, the emergency entity (e.g., device B) receives the location of the device D making the emergency call, as is typically provided during an emergency call (e.g., as specified in section 7.6 of TS 23.167), since this is a mandatory legislative 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 may request service S to provide information about the nearest mobile device in the vicinity of device D making the emergency call. For this purpose, device B may send the received location information to service S or service S may request this information from a location service / entity in the core network (e.g., GMLC or E-SMLC, see for example 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 may issue a request to the eNB to which device D is connected, i.e., the eNB measures the locations of all mobile devices connected to the eNB (e.g., via the LTE positioning protocol (LPP), mobile location protocol (MLP), and / or secure user plane location (SUPL)), and then estimates the distance between the mobile devices and the location of device D, and in such a case selects the device with the nearest estimated distance. Additional background information may be used, such as by detecting a group formed around the victim, e.g., the shape of a circle. The victim's phone may be located at the center of the circle.

[0089] In an embodiment of the system, to further reduce the response time, the emergency entity may select the nearest first responder before dispatching. Here, the term first responder is used in the following sense: a medical professional who provides first aid in an emergency situation. Such professionals are typically the ones to whom the emergency entity dispatches the EHR data. However, the term "responder" mentioned in this document may also refer to a person already at the accident scene, e.g., a caller who is not the victim but is able to provide first aid.

[0090] In the case where the user of device A is determined to be a victim and the medical and location information of the victim is exported, device B can search for responders near the victim based on the information exported from the mobile device of the first responder. In this embodiment, the mobile device of the responder must share the location information with device B of the emergency entity. In addition, the first responder should provide additional information about their readiness at a given time, such as participating in the emergency or being available for new requests to device B of the emergency entity. Moreover, the level of expertise of the first responder in dealing with specific medical conditions can be updated regularly and should be provided to device B of the emergency entity. In this embodiment, device B of the emergency entity should be able to automatically select a suitable first responder based on the information obtained from the first responder in real time. In the case of selecting a first responder, device B of the emergency entity should confirm with the first responder the acceptance of the emergency request. After accepting the emergency request, device B should share the location and medical information of the victim with the first responder.

[0091] In an embodiment of the system, to better detect the distance between device D and device A, a special mode can be requested on device A or D to measure the distance between A and D, such as by using Wi-Fi Fine Time Measurement as specified in IEEE 802.11-2016, or by the LTE ProSe function authorized on both device A and D by the MNO (as specified in 3GPP TS 23.303 and TS 24.334), so that they can discover each other using the LTE sidelink D2D communication channel and perform distance measurement or proximity detection, such as by PC5 or Wi-Fi Aware ranging. Alternatively, NFC or Qi can be used, for example, by having the emergency medical dispatcher in the 911 / 112 emergency entity instruct the person making the call or the first responder to pick up the victim's phone and keep it very close to their own phone to ensure that the nearest nearby device is addressed. The NFC or Qi communication channel can be used to send a message to device A to trigger it to send the encrypted identifier X. Such a message can incorporate a special credential (e.g., an emergency credential, as part of an X.509 certificate signed by a trusted certificate authority), and its authenticity can be verified by device A before sending the encrypted identifier X. More specifically, the NFC function of the (e)UICC of device A (e.g., as specified in the RSP architecture V2.2) can be used to transmit (e.g., push) the encrypted identifier X to the enabled NFC (e)UICC of the device Q of the first responder. The interface application on the (e)UICC of device A will ensure that the application of the enabled NFC (e)UICC of device Q cannot access network-related information (e.g., IMSI, PLMN) through the NFC channel. Device Q, device B, or device C will decrypt the identifier X to obtain the decrypted identifier Y, and then use the decrypted identifier Y to retrieve a set of patient health records associated with the identifier Y.

[0092] In a further embodiment, the distance information and / or information about which device is closest to the proximity device D is passed to device B via service S or device D. In the case where this information is received and it is determined that device A is the closest device to the proximity device D, device B may issue a request (e.g., via service S or other core network services) to device A to indicate that the encrypted identifier X is to be sent to device B. For this purpose, service S may send a paging message with this special request to device A (which may be encrypted with special emergency credentials and include the destination IP address or call destination information). In the case where the special request is received, device A may send the encrypted identifier X as part of an emergency call to device B. Alternatively, device A may send the encrypted identifier X to service S or other core network services (e.g., as part of an RRC message or an (emergency) call setup message or as a user plane message to a certain destination IP address), after which service S or other core network services forward the encrypted identifier X to device B.

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

[0094] In a third embodiment, the system consists of the following devices. Devices A and B have the same roles as described above, but may or may not include encryption credentials as part of an emergency call. Additional mobile devices {D0, …, Dn} are capable of performing wireless distance measurements and / or angle detection, for example using time difference of arrival on a ProSe sidelink channel (e.g., PC5 of Wi-Fi Aware) and / or using Wi-Fi fine time measurement (e.g., as part of Wi-Fi Aware ranging) and / or using Bluetooth angle of arrival detection and / or using distance measurements with wireless signal strength measurements (e.g., using PC5, Wi-Fi, Bluetooth).

[0095] In one embodiment, device B is communicatively coupled to service T running in the core network of a mobile operator. Service T is capable of determining the location and / or requesting location information of device A, e.g., from a location service / entity in the core network (such as a 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 is also capable of determining a set of mobile devices {K0, …, Km} near device A, e.g., by requesting a list of devices connected to the same eNB as device A (e.g., from the eNB itself, MME, GMLC or E-SMLC or other core network services). Service T is also capable of determining the capabilities of the devices {K0, ..., Km} (e.g., from the eNB, MME or other core network services, or by requesting capabilities from the devices {K0, ..., Km} with only the UECapabilityEnquiry RRC message and selecting a subset of devices {D0, ..., Dn} of the devices {K0, ..., Km} that are capable of performing wireless distance measurements and / or angle estimations).

[0096] Service T sends a message Mx (0 ≤ x ≤ n) to each of the mobile devices Dx in the set of mobile devices {D0, …, Dn}, where the message Mx contains instructions and optionally also authorization credentials to participate in performing distance measurements and / or angle estimations of device A, and also sends a message N containing instructions and optionally also authorization credentials to device A to participate in distance measurements and / or angle estimations of the mobile devices {D0, …, Dn}. Optionally, a pop-up window is shown asking the user of the device whether they agree to participate in more accurate distance measurements. Alternatively, when the user is not asked, their distance data is anonymized. Mobile device A and the mobile devices {D0, …, Dn} then perform distance measurements and / or angle estimations and send the results of the distance and / or angle measurements to service T. Service T (or other services in the core network to which T is communicatively coupled or device A) uses the received distance (and possibly angle) measurements to improve the location estimate of device A and inserts the improved location estimate as part of the cellular emergency communication session setup with the destination device B (e.g., via the MME, GMLC, E-SMLC or other core network services / functions).

[0097] In a further embodiment, service T also issues requests to the eNB to which device A is connected and all adjacent eNBs to also participate in distance measurement / angle detection, and preferably to perform distance measurement / angle detection not only with respect to device A but also with respect to the devices {D0, ..., Dn}.

[0098] In an alternative embodiment, the emergency entity (i.e., Device B) receives the location of Device A that makes an emergency call, as is typically provided during an emergency call (e.g., as specified in Section 7.6 of TS 23.167), since this is a mandatory legislative 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 may request Service T to provide a more accurate location estimate of Device A that makes the emergency call. To this end, Device B may send the received location information to Service T, or Service T requests this information from the location service / entity in the core network (e.g., GMLC or E-SMLC, see for example 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 executes the process as described above to perform distance measurements and / or angle estimation using the set of devices {D0, …, Dn} near Device A.

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

[0100] Figure 3shows a method used in a mobile device arranged for wireless communication in a mobile network. The mobile network, medical database, encrypted medical identifier, emergency entity, and mobile device have thus been described above in Figure 1 above.

[0101] In this method, an emergency process is executed and started at node start 501. In the first phase OBT 502, the process obtains the encrypted medical identifier of the user of the device. For example, the medical identifier can be prepared by encrypting the medical identifier in a secure processor (e.g., the (e)SIM card of the mobile device). The encrypted medical identifier can be retrieved from the secure processor (e.g., (e)SIM). Subsequently, in phase VIC? 503, the process determines that the user may be a victim of an emergency, for example by detecting that a call to an emergency number has been made. If not, the process continues by monitoring the emergency indicator as indicated by the upward arrow. If so established, the method proceeds in phase INC 504 by including the encrypted medical identifier in the emergency message during an emergency call. Additionally, other data such as location information and other medical information, such as the heart rate derived from the victim's mobile device, can be included. Then the process terminates at node end 505.

[0102] Figure 4 shows a method used in an emergency entity to be arranged in a mobile network. The mobile network, medical database, encrypted medical identifier, mobile device, and emergency entity have thus been described above in Figure 1 above.

[0103] In this method, an emergency process is executed and started at node start 601. In the first phase EMC 602, an emergency call setup is detected. The method continues to phase DMV 603 to determine the victim's mobile phone. When the victim's mobile phone makes an emergency call, the mobile phone will send the emergency message as described above. Thus, during an emergency call, in phase RCV 604, the emergency message is automatically received from the mobile device, which determines that the user may be a victim of an emergency.

[0104] Alternatively, an emergency call may be arriving at the emergency entity from another mobile device, such as from a bystander, spectator, or emergency responder. In such a case, stage DMV 603 continues by determining which mobile device is the victim's mobile device. Various methods for discovering the victim's mobile device have been discussed above, such as using location services to find the mobile device closest to the mobile device making the emergency call. In the case of determining the victim's mobile device, a request message is transmitted via 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 such a case, in stage RCV 604, an emergency message is received from the mobile device that received the request message.

[0105] In stage REMI 605, the method continues by retrieving the encrypted medical identifier from the emergency message. Then, in stage AMD 606, a medical database is accessed to retrieve at least one electronic health record (EHR) based on the encrypted medical identifier. Subsequently, the method may automatically select a first responder based on real-time information (such as location, availability, expertise of the first responder), and in stage FMI 607, automatically forward information from the electronic health record to the responder to the emergency. Also, the location information of the victim's mobile device may be forwarded. Alternatively, the forwarding may also be performed by a human operator at the emergency entity, as schematically indicated by arrow 610. The method terminates in node end 608.

[0106] As will be apparent to those skilled in the art, many different ways of implementing these methods are possible. For example, the order of stages or steps may be changed, or some stages may be performed in parallel. In addition, other method steps may be inserted between the steps. The inserted steps may represent a refinement of the methods such as those described herein, or may be unrelated to the method.

[0107] A computer program product is provided that can be downloaded from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium, which includes program code instructions for implementing the above methods, connection sequences, security processes, and further operations when executed on a computer device. Thus, the methods according to the present invention can be performed using software, which includes instructions for causing a processor system to perform the corresponding methods.

[0108] Typically, a mobile device and an emergency entity device that perform an interactive emergency call each include a processor coupled to a memory that contains appropriate software code stored at these devices; for example, the software may have been downloaded and / or stored in the respective memory, such as volatile memory like RAM or non-volatile memory like flash memory (not shown). These devices may be equipped, for example, with a microprocessor and a memory (not shown). Alternatively, these devices may be implemented in whole or in part with programmable logic, such as a field-programmable gate array (FPGA). These devices and servers may be implemented in whole or in part as a so-called application-specific integrated circuit (ASIC), an integrated circuit (IC) customized for its particular use. For example, the circuitry may be implemented with CMOS (e.g., using a hardware description language such as Verilog, VHDL).

[0109] The software may include only those steps taken by specific sub-entities of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy disk, a memory, etc. The software may be sent as a signal along a wire or wirelessly or using a data network (e.g., the Internet). The software may be made available for download and / or remote use on a server. The method according to the invention may be performed using a bitstream arranged to configure programmable logic (e.g., a field-programmable gate array (FPGA)) to perform the method. It should be understood that the software may be in the form of source code, object code, code intermediate between source code and object code (e.g., a partially compiled form), or any other form suitable for use in an implementation of the method according to the invention. Embodiments involving a computer program product include computer-executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and / or stored in one or more files linked statically or dynamically. Another embodiment involving a computer program product includes computer-executable instructions corresponding to each of the modules of at least one of the systems and / or products set forth.

[0110] Figure 5a A computer-readable medium 1000 having a writable portion 1010 is shown, the writable portion 1010 including a computer program 1020, the computer program 1020 including instructions for causing a processor system to operate as described with reference to Figures 1-4Instructions for performing one or more of the above methods and processes in the described system. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical mark or by magnetization of the computer-readable medium 1000. However, any other suitable embodiments may also be contemplated. Further, it will be appreciated that although the computer-readable medium 1000 is shown herein as an optical disk, the computer-readable medium 1000 may be any suitable computer-readable medium (e.g., hard disk, solid-state memory, flash memory, etc.) and may be non-recordable or recordable. The computer program 1020 includes instructions for causing the processor system to perform the method.

[0111] Figure 5b Shows a schematic representation of a processor system 1100 according to an embodiment of a device or method as described with reference to Figures 1-4 The processor system may include circuitry 1110, e.g., one or more integrated circuits. The architecture of the circuitry 1110 is schematically shown in the figure. The circuitry 1110 includes a processing unit 1120 (e.g., a CPU) for running computer program components to execute a method according to an embodiment and / or implement its modules or units. The circuitry 1110 includes a memory 1122 for storing programming code, data, etc. A portion of the memory 1122 may be read-only. The circuitry 1110 may include communication elements 1126, e.g., antennas, transceivers, connectors, or both, etc. The circuitry 1110 may include an application specific integrated circuit 1124 for performing part or all of the processing defined in the method. The processor 1120, the memory 1122, the application specific IC 1124, and the communication elements 1126 may be connected to each other via an interconnection 1130, such as a bus. The processor system 1110 may be arranged for wired and / or wireless communication using a connector and / or an antenna, respectively.

[0112] It will be appreciated that, for clarity, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable functional allocation 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. Thus, the reference to specific functional units is only to be regarded as a reference to a suitable module for providing the described function, rather than indicating a strict logical or physical structure or organization. The invention may be implemented in any suitable form including hardware, software, firmware, or any combination of these items.

[0113] Note that, in this document, the verb "comprise" does not exclude the presence of elements or steps other than those listed, and the words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. When used in front of a list of elements, expressions such as "at least one" represent the selection of all or any subset of elements from that list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, 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 means of both hardware and software. A number of "modules" or "units" can be represented by the same item of hardware or software, and a processor can implement the functions of one or more units (possibly in cooperation with hardware elements). Furthermore, the present invention is not limited to the embodiments, and the present invention lies in each novel feature or combination of features described above or in mutually different dependent claims.

[0114] In summary, a mobile device and an emergency entity in a mobile network adapt to an emergency call. The network is coupled to a medical database including corresponding electronic health records regarding corresponding persons. The mobile device is arranged to obtain an encrypted medical identifier of a user of the device; and, in the case where it is determined 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 arranged to retrieve the encrypted medical identifier from the emergency message and access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record for forwarding information from the electronic health record to a responder to the emergency.

Claims

1. A mobile device (110) arranged for wireless communication in a mobile network (130), the mobile network providing wireless communication for the mobile device across at least a local area according to a network communication protocol, - the network communication protocol enabling calls between subscribers of the network, - the calls including emergency calls between the mobile device and an emergency entity (120), the emergency call setup being initiated in case of an emergency action being performed by the mobile device, - the network being coupled to a medical database (140), the medical database including corresponding electronic health records (EHRs) of corresponding persons, each person having a corresponding medical identifier linking the person to the corresponding electronic health record, The emergency entity is arranged to: - retrieve an encrypted medical identifier from an emergency message, and - access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR), to enable forwarding of information from the electronic health record (EHR) to responders to the emergency, Among them, The mobile device includes: a network communication unit (111) for enabling calls via the network, and a security processor (116) arranged to: - obtain the encrypted medical identifier of the user of the device; and, in case it is determined that the user can be a victim of the emergency, - include the encrypted medical identifier in the emergency message during an emergency call, wherein the network provides location services for determining the corresponding location of a corresponding mobile device in the local area and enables transmission of a request message to the corresponding mobile device, the request message requesting inclusion of the encrypted medical identifier of the user of the corresponding mobile device in the emergency message, The emergency entity (120) is arranged, in case the emergency call is made by a second mobile device other than the mobile device of the user who can be a victim of the emergency: - locate at least one mobile device near the second mobile device via the location services; and - generate the request message for the located mobile device, wherein, in order to determine that the user can be a victim of the emergency, the security processor (116) is arranged to receive the request message.

2. The mobile device according to claim 1, wherein, In order to determine that the user can be a victim of the emergency, the security processor (116) is arranged to perform at least one of the following operations: - determine that the emergency call is being made via the network communication unit; - detect a decelerating acceleration above a predetermined limit; - detect an anomaly in a sensor of the user's vital signs; - detect an alert condition generated by another processor or an external source in the mobile device; - receive user input regarding the emergency; - receive user input regarding inclusion of the encrypted medical identifier in the emergency message; - receive a message from the emergency entity; - receive a message from the network regarding no other mobile phones being within the bystander range.

3. The mobile device according to claim 1 or 2, Among them, The mobile device (110) is arranged to perform a distance measurement between the mobile device and another mobile device; and The security processor (116) is arranged to implement a distance measurement in an emergency situation and transmit the measured distance to the network for determining enhanced location data of the mobile device.

4. The mobile device according to any one of claims 1 to 3, wherein, To obtain the encrypted medical identifier, the security processor (116) is arranged to perform at least one of the following operations: - Encrypt medical identifier data based on key data during the emergency call; - Receive authentication data for verifying a request from a trusted party to send an encrypted identifier; - Retrieve medical identifier data or the encrypted medical identifier from a remote server accessible to the security processor via the network communication unit.

5. The mobile device according to any one of claims 1 to 4, wherein, To obtain the encrypted medical identifier, the security processor is arranged 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 time period.

6. The mobile device according to any one of claims 1 to 5, wherein, The emergency entity includes: A network communication unit (121) for communicating via the network, and A security processor (122) arranged to: - Retrieve the encrypted medical identifier from the emergency message, and - Access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR), To enable forwarding of information from the electronic health record (EHR) to the responder to the emergency situation.

7. The mobile device according to claim 6, Among them, The security processor (122) in the emergency entity is arranged to select one of the at least one located mobile devices based on at least one of the following: - The location of the selected mobile device is closest to the second mobile device; - The locations of the multiple located mobile devices form a bystander pattern around the selected mobile device.

8. The mobile device according to claim 6 or 7, Among them, The security processor (122) in the emergency entity is arranged to select one of the at least one located mobile devices based on at least one of the following: - Request the operator of the second mobile device to move the second mobile device closer to the mobile device of the victim, while other mobile devices are further away; - Send a call setup request to the selected mobile device to generate a call signal from the selected mobile device, so that the operator of the second mobile phone can confirm that the selected mobile phone is at the victim; 9. The mobile device according to any one of claims 6-8, Among them, The security processor (122) in the emergency entity is arranged to select one of the at least one located mobile devices based on at least one of the following: - Send biometric property data to the second mobile phone so that the operator of the second mobile phone can confirm that the biometric data corresponds to the victim having the selected mobile phone; - Request the operator of the second mobile phone to obtain biometric property data of the victim for transmission of the obtained property data to the emergency entity.

10. The mobile device according to any one of claims 1-9, Among them, The network entity is arranged to: - Receive identity data from a mobile device participating in an emergency call setup; - Obtain an encrypted medical identifier corresponding to the identity data; and - Include the encrypted medical identifier in the emergency message during an emergency call.

11. A method used in a mobile device arranged for wireless communication in a mobile network (130), the mobile network providing wireless communication for mobile devices across at least a local area according to a network communication protocol, - The network communication protocol enables calls between subscribers of the network, - The call includes an emergency call between the mobile device and an emergency entity (120), and the emergency call setup is initiated in the case of an emergency action performed by the mobile device, - The network is coupled to a medical database (140), the medical database including corresponding electronic health records (EHRs) of corresponding persons, each person having a corresponding medical identifier linking the person to the corresponding electronic health record, The emergency entity is arranged to: - Retrieve the encrypted medical identifier from the emergency message, and - Access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR), to enable forwarding of information from the electronic health record (EHR) to responders to the emergency, Among them, The method includes: - Obtain the encrypted medical identifier of the user of the device; And, in the case of determining that the user can be the victim of the emergency, - Include the encrypted medical identifier in the emergency message during an emergency call, wherein the network provides a location service for determining the corresponding location of the corresponding mobile device in the local area and enables transmission of a request message to the corresponding mobile device, the request message requesting inclusion of the encrypted medical identifier of the user of the corresponding mobile device in the emergency message, wherein, in the case where the emergency call is made by a second mobile device other than the mobile device of the user who can be the victim of the emergency: - The emergency entity (120) locates at least one mobile device near the second mobile device via the location service; and - The emergency entity (120) generates the request message for the located mobile device, wherein, in order to determine that the user can be the victim of the emergency, the security processor (116) of the mobile device is arranged to receive the request message.

12. A method used in an emergency entity to be arranged in a mobile network, the mobile network providing wireless communication for mobile devices across at least a local area according to a network communication protocol, - The network communication protocol enables calls between subscribers of the network. - The calls include emergency calls between a mobile device and the emergency entity, and the emergency call setup is initiated in the case of an emergency action being performed by the mobile device. - The network is coupled to a medical database, which includes corresponding electronic health records (EHRs) of corresponding persons, and each person has a corresponding medical identifier that links the person to the corresponding electronic health record. The mobile device (110) is arranged to: - Obtain the encrypted medical identifier of the user of the device. And, in the case of determining that the user may be a victim of an emergency, - Include the encrypted medical identifier in an emergency message during an emergency call, wherein, The method includes: - Retrieve the encrypted medical identifier from the emergency message, and - Access the medical database based on the encrypted medical identifier to retrieve at least one electronic health record (EHR). To enable forwarding of information from the electronic health record (EHR) to the responder to the emergency. Wherein, the network provides location services for determining the corresponding location of the corresponding mobile device in the local area and enables transmission of a request message to the corresponding mobile device, the request message requesting the encrypted medical identifier of the user of the corresponding mobile device to be included in the emergency message. Wherein, in the case where the emergency call is made by a second mobile device other than the mobile device of the user who may be the victim of the emergency: - The emergency entity (120) locates at least one mobile device near the second mobile device via the location service; and - The emergency entity (120) generates the request message for the located mobile device. Wherein, in order to determine that the user may be the victim of the emergency, the security processor (116) of the mobile device is arranged to receive the request message.

13. A computer program product that can be downloaded from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium, the product including program code instructions that, when executed on a computing device, are used to implement the method according to claim 11 or 12.

Citation Information

Patent Citations

  • Identity-based encryption of data items for secure access thereto

    US8627103B2