Patent Application
20080200156
This disclosure relates generally to communication systems and, more particularly, to methods and apparatus to provide medical information using a communication system.
Recently, medical and emergency services providers have recommended that mobile phone users store an entry for an emergency contact in their mobile phone's address booked labeled as ICE (in case of emergency). Typically, the emergency contact is a relative who is familiar with the mobile phone user and, more importantly, is familiar with the user's medical information. If the mobile phone user is in an emergency situation, a medical provider that locates the user's mobile phone can call the ICE number to alert the contact and/or to get medical information about the mobile phone user.
Of course, using the ICE address book entry is only as good as the emergency contact. If the emergency contact is not available at the time of the emergency or is ill-informed about the user's medical information, the procedure might not be helpful.
The example system 100 of
The mobile phone 102 of the illustrated example allows a user to send and receive mobile telephone calls via the wireless access point 104. The example mobile phone 102 includes a keypad for receiving user input such as, for example, a telephone number, a pin number, an access number, etc. The example mobile phone 102 additionally includes a microphone for receiving audible user input (e.g., spoken words) and a speaker for outputting audible output. Persons of ordinary skill in the art will recognize that the mobile phone 102 may additionally include any other desired feature(s) such as, for example, a display screen, indicators (e.g., light emitting diodes (LEDs), directional pad input controls, a joystick input control, one or more switches, a touchscreen user input, etc. While a mobile phone 102 is illustrated, the mobile phone 102 may alternatively be replaced with a voice over internet protocol (VoIP) telephone, a public switched telephone network (PSTN) telephone, a wireless network telephone (e.g., a telephone that operates according to the 802.11 protocol), a personal digital assistant (PDA), a laptop computer, a desktop computer, a smart phone, a gaming device, etc. In addition to enabling a user to send and/or receive mobile telephone calls, the mobile phone 102 may additionally or alternatively enable a user to send and/or receive text messages, to send and/or receive webpage information (e.g., to send requests for a webpage and to receive a webpage), to send and/or receive communication pages, to store and/or play audio data (e.g., music files), to receive and/or execute applications, to send and/or receive walkie-talkie communications, to take, send, and/or receive pictures and/or video, etc.
The wireless access point 104 of the illustrated example communicatively couples the mobile phone 102 with the wireless network 106. The example wireless access point 104 is communicatively coupled to the wireless network 106. The wireless access point 104 of the illustrated example is coupled to the mobile phone 102 via a past, present, and or future mobile phone communication protocol such as, for example, the code division multiple access (CDMA) protocol; the global system for mobile (GSM) communication protocol; the time division multiple access (TDMA) protocol; the personal communication service (PCS) protocol; any first generation (1G), second generation (2G), third generation (3G), and/or fourth generation (4G) communication protocol; the integrated digital enhanced network (iDEN) protocol, the general packet radio service (GPRS) protocol, the 1× evolution-data optimized (EV-DO) service; the universal mobile telecommunications system (UTMS) protocol; the advanced mobile phone system (AMPS) protocol, etc. Alternatively, the wireless access point 104 may be a central office (CO) for a PSTN, a wireless data access point (e.g., an access point for a wireless network that operates according to an 802.11 communication protocol), a voice over internet protocol (VoIP) access point, etc.
The wireless network 106 of the illustrated example enables communication between two or more devices connected to the wireless network 106 (e.g., the mobile phone 102, which is connected to the wireless network 106 via the wireless access point 104). The wireless network 106 may operate according to any past, present, and/or future protocol including for instance, one or more of the mobile communication protocols listed above in conjunction with the wireless network access point 104. Alternatively, the wireless network 106 may be replaced with a PSTN, a wireless data network, a VoIP network, etc.
The wireless network 106 includes components for receiving and routing mobile communications. When the wireless network 106 receives a telephone call, the wireless network 106 may query the dialing number database 108 to determine how to route the telephone call. For example, if the call is directed to an 800 number, a three digital dialing code (e.g., 411), a three digit access code or star (*) code (e.g., *423), or any other number, the wireless network 106 may query the dialing number database 108 to determine how to route the call. The wireless network 106 of the illustrated example is communicatively coupled to the medical information provider 112 (e.g., directly and/or via the wireline network 110).
The dialing number database 108 of the illustrated example provides information describing how telephone calls should be routed to a destination. The dialing number database 108 may be a line information database (LIDB), an 800 number database, a three-digit dialing code database, an access code (*) database, and/or any other type of database. In response to a query with a dialing number, the dialing number database 108 provides information for routing a call to the destination associated with the dialing number (e.g., a ten digit routing number).
The wireline network 110 of the illustrated example may optionally connect the wireless network 106 to the medical information provider 112. The wireline network 110 may be any type of network for communicatively coupling devices such as, for example, a local area network (LAN), a wide area network (WAN), another wireless network, the internet, the PSTN, etc. While the wireline network 110 and the data network 114 are illustrated as discrete components, the wireline network 110, the data network 114, and/or the wireless network 106 may alternatively be integrated as a single network.
The medical information provider 112 of the illustrated example receives requests for personal medical information (e.g., medical information associated with a specific person) and sends the medical information to the source of the request. In the illustrated example, the medical information provider 112 receives a request for medical information from the mobile phone 102 (e.g., via the wireless access point 104, the wireless network 106, and, in some implementations, through the wireline network 110). In response to the request, the example medical information provider 112 verifies the identity of the mobile phone 102 and/or the user of the mobile phone 102 and sends medical information associated with the mobile phone 102 and/or the user of the mobile phone 102 back to the mobile phone 102. The example medical information provider 112 is also capable of allowing administration (e.g., inputting medical information, deleting stored medical information, modifying access settings, etc.). The medical information provider 112 of the illustrated example is described in further detail in conjunction with
The data network 114 of the illustrated example communicatively couples the medical information provider 112 with the computer 116. The data network 114 may be any type of data network or communication connection such as, for example, a LAN, a WAN, a cable communication connection, a DSL communication connection, the internet, etc. As previously described, the data network 114 may be integrated with the wireline network 110. Persons of ordinary skill will recognize that further devices (other than the computer 116 and the medical information provider 112) may additionally or alternatively be connected to the data network such as, for example, additional computers.
The computer 116 of the illustrated example allows a user to connect to the medical information provider 112 to create, delete, and/or edit medical records. The computer 116 may be any device that allows a user to work with the medical records such as, for example, a laptop computer, a desktop computer, a PDA, a mobile phone, a smart phone, etc.
The communication device 202 of the illustrated example communicatively couples the medical information provider 112 of
The IVR engine 204 of the illustrated example provides an interactive voice menu to a caller (e.g., a user of the mobile phone 102) to allow the caller to interact with the medical information provider 112 without the need for a screen. For example, the IVR engine 204 may greet a calling user with a recorded message when the user calls the medical information provider (e.g., using a specified 800 number, three digit access code, etc.). The IVR engine 204 may then read a menu of options to the user and ask the user to press a button or say a name corresponding to a desired menu. While an IVR engine is illustrated in
When the example IVR engine 204 receives spoken inputs (e.g., a user of the mobile phone 102 speaking requests), the IVR engine 204 works with the speech recognition engine 206 of the illustrated example to identify the user's request. The example speech recognition engine 206 receives spoken words and converts the words to computer readable data. The example speech recognition engine 206 may additionally be capable of using speech patterns to identify a user's voice. For example, upon receiving an incoming request for information, the IVR engine 204 may instruct the user to speak a certain phrase (e.g., a password) and the speech recognition engine 206 may compare the spoken words to stored information to identify the user.
To identify the source of incoming calls requesting information, the IVR engine 204 works with the caller ID receiver 208 of the illustrated example to identify the caller ID number associated with the source of the incoming call (e.g., the mobile phone 102). The caller ID receiver 208 receives caller ID information from the communication device 202 and/or the IVR engine 204 and determines a caller ID number associated with the incoming call. For example, the caller ID receiver 208 may receive caller ID information from an automatic number identification (ANI) system, a calling number identification (CNID) system, a calling line identification (CLI) system, a calling line identification presentation (CLIP) system, a calling line identification (CLID) system, etc. The caller ID receiver 208 of the illustrated example then transmits the caller ID number to the IVR engine 204. The caller ID receiver 204 may alternatively identify other identifying information associated with the mobile phone 102 and/or a user of the mobile phone 102. For example, the caller ID receiver 204 may identify a serial number associated with the mobile phone 102, an account number/name associated with the mobile phone 102, etc.
The example IVR engine 204 works with the authentication server 210 of the illustrated example to identify and/or authenticate users requesting information from the medical information provider 112. The IVR engine 204 transmits identifying information for the source of the information request to the authentication server 210. The example authentication server 210 compares the information received from the IVR engine 204 to information stored in the authentication database 212 to determine if the medical information provider has stored information associated with the user. In addition, the example authentication server 210 may determine if any received information can be used to authenticate the user. For example, the IVR engine 204 may send the authentication server 210 one or more of a caller ID number (e.g., identified by the caller ID receiver 208), a user identifier/password/personal identification number (PIN) (e.g., received from the mobile phone via the input keypad or received from the speech recognition engine 206), an identified serial number for the mobile phone 102, etc.
The authentication server 210 of the illustrated example determines if the received identification information matches to one or more corresponding records in the authentication database 212. For example, the authentication server 210 may determine if a received caller ID number and a PIN match a set of records, which would indicate that the correct PIN has been entered for the caller ID source. Additionally or alternatively, the authentication engine 210 may determine if a first subset of the received identifying information indicates that the source of the request is authorized to access information associated with a second subset of the received identifying information. For example, a received caller ID number may be used to identify the medical information records that are to be retrieved from the information database 216 and a received user identifier and PIN may identify the user as a medical provider that is authorized to access medical information about the owner of the mobile phone 102 (e.g., medical information associated with the caller ID number).
The authentication database 212 of the illustrated example stores authentication information for verifying the authority of requests for medical information. The authentication database 212 may be any type of data storage such as, for example, a database, a hard drive, a file, etc. The authentication database 212 may be accessed for modification by the administration server 218 to allow the creation, removal, and/or modification of authentication records.
The text-to-speech engine 214 of the illustrated example receives requests for information from the IVR engine 204, retrieves the requested information from the information database 216, and converts the requested information to spoken words. The text-to-speech engine 214 may be excluded from the medical information provider 112 when information is transmitted to users via text or when the information is stored in the information database 216 as spoken words.
The information database 216 of the illustrated example stores medical information. The medical information may be any type of information that a user of the medical information provider 112 may desire to store such as, for example, information about one or more prescriptions assigned to the user, information about one or more allergies associated with the user, information about one or more medical conditions associated with the user, information about one or more previous medical procedures associated with the user, information about medical personnel associated with the user (e.g., preferred doctors and/or hospitals), information about one or more emergency contacts associated with the user, etc. The information database 216 of the illustrated example may be any type of data storage such as, for example, a database, a hard drive, a file, etc.
The administration server 218 of the illustrated example provides webpage information that allows users to manage the medical and/or authentication information used by the medical information provider 112. The administration server 218 may receive an administration request from the communication device 202 (e.g., a request from the mobile phone 102) and/or the data network 114 of
After receiving the access code, the authentication server 210 queries the authentication database 212 with the received user identifier and/or access code to determine if the received user authorization credentials match a valid record (block 310). If the user authorization credentials do not match a valid record, the IVR engine 204 sends an error message (e.g., a spoken message, a text message, etc.) to the mobile phone 102. Control then proceeds to block 308 to give the user another opportunity to input the access code or the machine readable instructions of
If the user authorization credentials match a valid record, the IVR engine 204 and/or the text-to-speech engine 214 retrieve the requested information associated with the valid record from the information database 216 (block 312). The example text-to-speech engine 214 then converts the retrieved information to spoken words (block 314). Persons of ordinary skill in the art will recognize that the conversion will not be performed if the retrieved information is already in the form of spoken words and/or if a text response is more appropriate. The IVR engine 204 then sends the retrieved information (e.g., to spoken words) to the mobile phone 102 for presentation (block 316). Then, the machine readable instructions of
If the caller does not indicate that they are a medical provider (e.g., a different tone is received or no tone is received), the IVR engine 204 queries the caller for an access code (e.g., a password, a PIN, etc.) (block 410). The IVR engine 204 then receives the access code (block 412). In an alternate implementation block 406 and block 408 may be eliminated if no access code is desired.
After receiving the access code, the authentication server 210 queries the authentication database 212 with the received authorization credentials (e.g., the user identifier and access code) to determine if the user authorization credentials match a valid record (block 414). If the user authorization credentials do not match a valid record, the IVR engine 204 sends an error message (e.g., a spoken message, a text message, etc.) to the mobile phone 102 (block 422). Control then proceeds to block 408 to give the user another opportunity to input an appropriate access code or, if a number of access attempts (
If the authorization credentials match a valid record, the IVR engine 204 and/or the text-to-speech engine 214 retrieve the requested information associated with the valid record from the information database 216 (block 416). The example text-to-speech engine 214 then converts the retrieved information to spoken words (block 418). Persons of ordinary skill in the art will recognize that the conversion will not be performed if the retrieved information is already in the form of spoken words or if a text response is to be used. The IVR engine 204 then sends the retrieved information (e.g., converted to spoken words) to the mobile phone 102 for presentation (block 420). Then, the machine readable instructions of
Returning to block 408, if the caller indicates that they are a medical provider, the IVR engine 204 queries the user for a medical provider identifier (block 424). For example, a medical provider may be assigned a user identifier (e.g., a number, username, etc.) that provides authorization to access any user's medical records. The IVR engine 204 then receives an input medical provider identifier from the mobile phone 102 (block 426). The IVR engine 204 then queries the user for a medical provider access code (block 428). For example, the medical provider may be assigned a password associated with the medical provider identifier. The IVR engine 204 then receives the medical provider access code from the mobile phone 102 (block 430).
After receiving the medical provider identifier and the medical provider access code, the authentication server 210 determines if the received medical provider identifier and medical provider access code match a valid record in the authentication database 212 (block 432). If the medical provider identifier and the medical provider access code match a valid record in the authentication database 212, control proceeds to block 416 to retrieve information associated with the user identifier received in block 404. If the medical provider identifier and/or the medical provider access code do not match a valid record, the IVR engine 204 sends an error message to the mobile phone 102 (block 434). Control then returns to block 424 to request the medical provider information again or the machine readable instructions of
The computer platform 1000 of the instant example includes a processor 1012 such as a general purpose programmable processor. The processor 1012 includes a local memory 1014, and executes coded instructions 1016 present in random access memory 1018, coded instruction 1017 present in the read only memory 1020, and/or instructions present in another memory device. The processor 1012 may execute, among other things, the machine readable instructions represented in
The processor 1012 is in communication with a main memory including a volatile memory 1018 and a non-volatile memory 1020 via a bus 1022. The volatile memory 1018 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1020 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1018, 1020 is typically controlled by a memory controller (not shown) in a conventional manner.
The computer 1000 also includes a conventional interface circuit 1024. The interface circuit 1024 may be implemented by any type of well known interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a third generation input/output (3GIO) interface.
One or more input devices 1026 are connected to the interface circuit 1024. The input device(s) 1026 permit a user to enter data and commands into the processor 1012. The input device(s) can be implemented by, for example, a keyboard, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.
One or more output devices 1028 are also connected to the interface circuit 1024. The output devices 1028 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT), a printer and/or speakers). The interface circuit 1024, thus, typically includes a graphics driver card.
The interface circuit 1024 also includes a communication device such as a modem or network interface card to facilitate exchange of data with external computers via a network (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).
The computer 1000 also includes one or more mass storage devices 1030 for storing software and data. Examples of such mass storage devices 1030 include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives.
At least some of the above described example methods and/or apparatus are implemented by one or more software and/or firmware programs running on a computer processor. However, dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement some or all of the example methods and/or apparatus described herein, either in whole or in part. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the example methods and/or apparatus described herein.
It should also be noted that the example software and/or firmware implementations described herein are optionally stored on a tangible storage medium, such as: a magnetic medium (e.g., a magnetic disk or tape); a magneto-optical or optical medium such as an optical disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; or a signal containing computer instructions. A digital file attached to e-mail or other information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the example software and/or firmware described herein can be stored on a tangible storage medium or distribution medium such as those described above or successor storage media.
Although this patent discloses example systems including software or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware or in some combination of hardware, firmware and/or software. Accordingly, while the above specification described example systems, methods and articles of manufacture, persons of ordinary skill in the art will readily appreciate that the examples are not the only way to implement such systems, methods and articles of manufacture. Therefore, although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
