HK1176306A - Records access and management - Google Patents

Description

Record access and management

This application is a divisional application based on a patent application having an application number of 200880022802.5, an application date of 2008/07/03, and an invention name of "record access and management".

Cross reference to related applications

This application claims priority from U.S. provisional application No.60/947,809 entitled "Records Access and Management" filed on 3.7.2007 and from U.S. provisional application No.60/974,997 entitled "Records Access and Management" filed on 25.9.2007. The entire contents of said prior application are hereby incorporated by reference in their entirety.

Technical Field

The present disclosure relates generally to record access and management.

Background

Medical records may be stored by a particular medical service provider in paper or electronic format. Such delivery and collection can be difficult and time consuming when medical records need to be delivered or collected from multiple medical service providers.

Disclosure of Invention

In one general aspect, techniques and systems for aggregating medical records of a user are described. Initiating a process of aggregating electronic medical records associated with a patient, the process initiated in response to the patient providing user input to an electronic device associated with the patient. Transmitting, from the electronic device to a first communication device, a first request for one or more electronic medical records associated with the patient stored in an electronic memory accessible by the first communication device, the first request including an authentication token stored on the electronic device.

Transmitting, from the electronic device to a second communication device different from the first communication device, a second request for one or more electronic medical records associated with the patient stored in an electronic memory accessible by the second communication device, the second request including the authentication token stored on the electronic device.

Receiving, at the electronic device, the one or more electronic medical records included in the first request from the first communication device, the one or more electronic medical records included in the first request being sent from the first communication device in response to the first communication device receiving the first request and authenticating the first request based on the authentication token.

Receiving, at the electronic device, the one or more electronic medical records included in the second request from the second communication device, the one or more electronic medical records included in the second request being sent from the second communication device in response to the second communication device receiving the second request and authenticating the second request based on the authentication token.

Enabling display of information regarding the one or more electronic medical records received from the first communication device and the one or more electronic medical records received from the second communication device to a medical services provider providing services to the patient.

Implementations may include one or more of the following features. For example, the electronic device associated with the patient may comprise a first electronic device, and may further comprise the operations of: establishing a secure connection between the first electronic device associated with the patient and a second electronic device associated with the healthcare provider, the second electronic device being different from the first electronic device. Transmitting, from the first electronic device to the second electronic device, the one or more electronic medical records received at the first electronic device from the first communication device and the one or more electronic medical records received at the first electronic device from the second communication device over the secure connection.

The first communication device and the second communication device may be configured to: rejecting a request from the second electronic device for an electronic medical record associated with the patient because the second electronic device fails to include the authentication token in the request for a record.

One or more electronic medical records associated with the patient may be accessed from a local memory associated with the electronic device. The step of enabling display of information regarding the one or more electronic medical records to the medical services provider providing services to the patient may comprise: enabling display of the one or more electronic medical records accessed from the local memory.

Filter criteria associated with the services provided by the medical service provider to the patient may be accessed, and transmitting the first request from the electronic device to the first communication device may include transmitting the filter criteria. The step of transmitting the second request from the electronic device to the second communication device different from the first communication device may comprise transmitting the filtering criteria. The step of receiving at the electronic device the one or more electronic medical records from the first communication device may comprise receiving one or more electronic medical records that meet the filter criteria. The step of receiving at the electronic device the one or more electronic medical records from the second communication device may comprise receiving one or more electronic medical records meeting the filter criteria.

The step of enabling display of information regarding the one or more electronic medical records received from the first communication device and the one or more electronic medical records received from the second communication device to a medical services provider providing services to the patient may comprise: displaying the information regarding the one or more electronic medical records received from the first communication device and the one or more electronic medical records received from the second communication device on a display device associated with the electronic device such that the electronic medical records are perceivable by the healthcare provider.

The electronic device associated with the patient may comprise a first electronic device, and the step of enabling display of information regarding the one or more electronic medical records received from the first communication device and the one or more electronic medical records received from the second communication device to a medical services provider providing services to the patient may comprise: transmitting, from the first electronic device to a second electronic device associated with the medical services provider, the one or more electronic medical records received at the first electronic device from the first communication device and the one or more electronic medical records received at the first electronic device from the second communication device to enable display of the one or more electronic medical records received from the first communication device and the one or more electronic medical records received from the second communication device on a display device associated with the second device.

In another general aspect, techniques and systems for accessing medical records are described. Initiating a process of aggregating electronic medical records associated with a patient, the process initiated in response to the patient providing user input to an electronic device associated with the patient. In response to initiation of the process of aggregating electronic medical records associated with a patient, at least a first electronic medical record storage system and a second electronic medical record storage system, each storing electronic medical records associated with the patient, are identified, the second electronic medical record storage system being different from the first electronic medical record storage system.

Identifying first patient authentication information that enables retrieval of an electronic medical record associated with the patient from the first electronic medical record storage system. Identifying second patient authentication information that enables retrieval of an electronic medical record associated with the patient from the second electronic medical record storage system. The second patient authentication information is different from the first patient authentication information.

A first request for a medical record is generated using the first patient authentication information. Generating a second request for medical records using the second patient authentication information. Transmitting the first request from the electronic device to the first electronic medical records storage system.

Transmitting the second request from the electronic device to the second electronic medical records storage system. Receiving, at the electronic device, a first response from the first electronic medical records storage system, the first response including at least a first portion of one or more electronic medical records of the patient stored at the first electronic medical records storage system, the first response being sent from the first electronic medical records storage system in response to the first electronic medical records storage system receiving the first request and authenticating the first request based on the first patient authentication information.

Receiving, at the electronic device, a second response from the second electronic medical records storage system, the second response including at least a second portion of the one or more electronic medical records for the patient stored at the second electronic medical records storage system, the second response being sent from the second electronic medical records storage system in response to the second electronic medical records storage system receiving the second request and authenticating the second request based on the second patient authentication information.

Generating a set of electronic medical records associated with the patient by combining the first portion of one or more electronic medical records for the patient included in the first response with the second portion of one or more electronic medical records for the patient included in the second response, and enabling display of the generated set of electronic medical records associated with the patient.

Implementations may include one or more of the following features. For example, the step of receiving the first response may comprise: receiving a first response comprising a first portion of a first electronic medical record of the patient stored at the first electronic medical record storage system, and receiving the second response may comprise: receiving a second response comprising a second portion of the first electronic medical record of the patient stored at the second electronic medical record storage system. The step of generating the set of electronic medical records may comprise: combining the first portion of the first electronic medical record with the second portion of the first electronic medical record to generate a complete first electronic medical record.

The first response and the second response may be configured to not include identification information associated with the patient. Both the first request and the first response may be configured to not include information identifying the second electronic medical records storage system, such that interception of the first request and the first response does not result in identification of electronic medical records stored in the second electronic medical records storage system. The first electronic medical records storage system and the second electronic medical records storage system may be configured to be unrelated and unaware of each other.

The following steps may all occur automatically without human intervention in response to initiation of the process of aggregating electronic medical records associated with a patient: identifying at least the first electronic medical records storage system and the second electronic medical records storage system, identifying first patient authentication information, identifying second patient authentication information, generating the first request, generating the second request, transmitting the first request, transmitting the second request, receiving the first response, receiving the second response, generating the set of electronic medical records, and enabling display of the generated set of electronic medical records.

The step of identifying the first patient authentication information may comprise: identifying a machine token that enables retrieval of an electronic medical record associated with the patient from the first electronic medical record storage system. The step of identifying the second patient authentication information may include: identifying a password that enables retrieval of the electronic medical record associated with the patient from the second electronic medical record storage system. Generating the first request for medical records using the first patient authentication information may include: a first request is generated that includes the machine token. Generating the second request for medical records using the second patient authentication information may include: a second request is generated that includes the password.

Identifying first patient authentication information may include identifying a first patient identifier and a first password, the combination of the first patient identifier and the first password enabling retrieval of an electronic medical record associated with the patient from the first electronic medical record storage system. The step of identifying second patient authentication information may include identifying a second patient identifier and a second password, the combination of the second patient identifier and the second password enabling retrieval of an electronic medical record associated with the patient from the second electronic medical records storage system, the first patient identifier being different from the second patient identifier and the first password being different from the second password. Generating the first request for medical records using the first patient authentication information may include: generating a first request comprising the first patient identifier and the first password. Generating the second request for medical records using the second patient authentication information may include: generating a second request comprising the second patient identifier and the second password.

In yet another general aspect, emergency service providers are enabled to access medical records of a patient by receiving, at an electronic device of the patient, a request from an emergency service provider to treat the patient to access medical records associated with the patient. In response to receiving the request from the emergency service provider, performing an authentication process on the emergency service provider to determine a status of the emergency service provider based on authentication information provided by the emergency service provider to the electronic device (status).

Accessing, from electronic storage, the patient's preferences regarding access by emergency service providers to the patient's medical records. Determining a level of access to the medical records associated with the patient to provide to the emergency service provider based on the determined condition of the emergency service provider and the accessed preferences of the patient.

Aggregating, at the electronic device of the patient, electronic medical records associated with the patient based on the determined level of access to be provided to the emergency service provider. Enabling display of the aggregated electronic medical records associated with the patient to the emergency service provider.

Implementations may include one or more of the following features. The step of performing an authentication process on the emergency service provider to determine the status of the emergency service provider may comprise: receiving an input from a hardware device issued by an emergency services agency to the emergency services provider to enable authentication of the emergency services provider with the electronic device of the patient, wherein the electronic device of the patient is configured to aggregate electronic medical records associated with the patient; and determining a status of the emergency service provider based on the received input from the hardware device.

The step of performing an authentication process on the emergency service provider to determine the status of the emergency service provider may comprise: receiving input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider; and determining a status of the emergency service provider based on the user identifier and the password.

The step of performing an authentication process on the emergency service provider to determine the status of the emergency service provider may comprise: receiving input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider; receiving an input from a hardware device issued by an emergency services agency to the emergency services provider to enable authentication of the emergency services provider with the electronic device of the patient, wherein the electronic device of the patient is configured to aggregate electronic medical records associated with the patient; and determining a status of the emergency service provider based on the user identifier and the password and the received input from the hardware device.

The step of performing an authentication process on the emergency service provider to determine the status of the emergency service provider may comprise: determining whether the emergency service provider is licensed; and based on the determined condition of the emergency service provider, determining a level of access to the medical record associated with the patient to provide to the emergency service provider may comprise: determining to provide access to at least a portion of the medical record associated with the patient in response to determining that the emergency service provider is licensed, and determining not to provide any access to the medical record associated with the patient in response to determining that the emergency service provider is not licensed.

The step of performing an authentication process on the emergency service provider to determine the status of the emergency service provider may comprise: determining whether the emergency service provider is at least one of an ambulance personnel, an emergency room doctor, and a surgeon performing an emergency procedure; and based on the determined condition of the emergency service provider, determining a level of access to the medical record associated with the patient to provide to the emergency service provider may comprise: in response to determining that the emergency service provider is an ambulance person, determining to provide a first level of access to the emergency service provider, in response to determining that the emergency service provider is an emergency room physician, determining to provide a second level of access to the emergency service provider, the second level of access being different from the first level of access, and in response to determining that the emergency service provider is a surgeon performing an emergency procedure, determining to provide a third level of access to the emergency service provider, the third level of access being non-disruptive to the first level of access and the second level of access.

Based on the determined condition of the emergency service provider and the accessed preferences of the patient, determining a level of access to the medical records associated with the patient to provide to the emergency service provider may include: the access level is determined from at least three access levels, wherein the three access levels include at least a full access level, an unauthorized access level, and an intermediate access level between the full access level and the unauthorized access level.

Based on the determined level of access to be provided to the emergency service provider, aggregating, at the electronic device of the patient, electronic medical records associated with the patient may include: automatically aggregating electronic medical records without further input from the emergency service provider.

The step of performing an authentication process on the emergency service provider may include: the authentication process is performed without receiving input from the patient.

The step of performing an authentication process on the emergency service provider may include: receiving a biometric (biometric) input from the patient indicating that the patient is physically in proximity to the electronic device of the patient as a condition for authenticating the emergency service provider.

Implementations of the described technology may include hardware, methods or processes, or computer software residing on computer-accessible media.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1 is a block diagram of a system configured to perform record access and management.

FIG. 2 is a flow diagram of a process for accessing and presenting records.

FIG. 3 is a flow diagram of a process for accessing and presenting records.

FIG. 4 illustrates an exemplary user interface for requesting a record.

FIG. 5 is a flow chart of a process for adding a record.

FIG. 6 illustrates an exemplary user interface for adding a record.

Fig. 7 is a diagram showing a case where anonymous medical records are aggregated (contextual diagram).

Fig. 8 is a flow chart of a process for anonymously aggregating (aggregate) medical records.

Fig. 9 is a diagram illustrating access to medical records by an emergency service provider.

Fig. 10 is a flow chart of a process for enabling an emergency service provider to access a patient's medical records.

Like reference symbols in the various drawings indicate like elements.

Detailed Description

In some implementations, a mobile device associated with a user is configured to securely aggregate electronic medical records for the user. The mobile device may be configured to act as a real-time, secure channel for receiving electronic medical records from a remote service provider, such that the electronic medical records may be displayed to a medical service provider that provides medical services to the user. For example, if a user attends a doctor's appointment without the doctor having the necessary medical records for the user, the user may use the user's mobile device to quickly access the electronic medical records required by the doctor. In another example, if a user encounters a car accident and the emergency service provider is providing treatment to the user, the user's mobile device may be used to access electronic medical records of those users that may be helpful to the emergency service provider in providing emergency treatment to the user. In these examples, the user's treatment or diagnosis may be improved because the healthcare provider has a complete review of the relevant medical records and has timely access to the relevant medical records.

For example, in one implementation, a user of a mobile device may initiate a request to aggregate medical records associated with the user. In response, the mobile device sends requests to a plurality of different database providers (e.g., hospital databases, medical records database providers, pharmacy databases, etc.) that store the user's electronic medical records. The plurality of database providers transmit the requested medical records of the user to the mobile device, enabling the mobile device to display information related to the received medical records. The user may then present the display to a medical service provider (e.g., a physician) that provides care to the user for review of the medical record. The mobile device may be configured to transmit the received medical record to the electronic device of the medical service provider such that the mobile device acts as a secure channel for the medical record. In this way, by taking advantage of security on the mobile device, medical records may be securely accessed by using the mobile device as a conduit. Moreover, the mobile device may be configured to request only a subset of the user's medical records that are relevant to the therapy being provided by the physician. Further, the mobile device may be configured to enable the user and/or the medical services provider to add medical records to the user.

In some embodiments, the electronic device may function as a distributable, remotely accessible, secure electronic medical records broker, wherein contemplated brokers aggregate separately stored user medical records segments from memory using identifiers, wherein the identifiers are associated with resolved identities of the segments. The parts of the record may then be stored separately in a plurality of locations. The recipient viewing/accessing the proxy perceives a single file. However, the perceived file is a virtual collection of more than one stored portion of the stored user identity and the complete medical record obtained using the public key. This enables data to be aggregated from all over the world. I.e. the receiving party gets a file that looks very simple. However, the recipient (e.g. user/patient) can control what the file contains, and only the recipient knows from which sources it was assembled. Moreover, the recipient can ensure privacy because the recipient's name is broken down from the file, and even in the case of a break, the segmentation of the medical record will prevent complete access by others.

In some examples, an emergency service provider (e.g., 911 service provider, emergency medical personnel, etc.) may obtain a key for a medical record based on reading a code (e.g., a bracelet or key fob) on a person associated with the medical record by a third party that may itself be identified as an emergency personnel. The code may also be provided by an emergency services operator or other service provider that manages emergency access to the recipient's medical records. Two-factor identification may be used to enable emergency access in such situations (e.g., an emergency service provider may need to key in a code and have a specific device or hardware key available only to licensed emergency service providers for accessing medical records). Also, the code of the person associated with the medical record may be hidden (e.g., a security ID and a bracelet code may be required for attempted access).

A user-configurable presence profile may be used to limit information provided to emergency service providers. The online profile may be used to adjust information based on the condition of the emergency personnel (e.g., ambulance driver has a low level; trauma therapist has a higher level, etc.). In particular, the user may choose to grant general doctors access to medications, and to grant trauma therapy providers more access (e.g., full access). The system may also be configured to publish all information to parties with different levels simultaneously (e.g., providing limited information to ambulance drivers while providing further access to local emergency room personnel to allow them time to prepare for incoming patients).

Referring to FIG. 1, a system 100 is configured to perform record access and management. The system 100 includes a user 120, a user electronic device 130, a plurality of record storage systems 140, 150, and 160, a recipient 170, and a recipient electronic device 180. Consumer electronic device 130 may be configured to exchange electronic communications with a plurality of record storage systems 140, 150, and 160 via network 110. The consumer electronic device 130 may also be configured to exchange electronic communications with the recipient electronic device 180 over connection 190.

The network 110 is configured to enable electronic communications to be exchanged between devices connected to the network 110. For example, the network 110 may be configured to enable the exchange of electronic communications between the consumer electronic device 130 and the plurality of record storage systems 140, 150, and 160. Network 110 may include, for example, one or more of the internet, a Wide Area Network (WAN), a Local Area Network (LAN), analog or digital wired and wireless telephone networks (e.g., PSTN, Integrated Services Digital Network (ISDN), cellular networks, and digital subscriber lines (xDSL)), radio, television, cable, satellite, and/or other transmission or tunneling mechanisms for communicating data. Network 110 may include multiple networks or sub-networks, each of which may include, for example, wired or wireless data channels. Network 110 may include a circuit-switched network, a packet-switched data network, or any other network capable of carrying electronic communications. For example, network 110 may include an Internet Protocol (IP) or Asynchronous Transfer Mode (ATM) based network.

The user 120 is a person operating the consumer electronic device. For example, the user 120 may provide user input to the consumer electronic device 130 to perform an operation on the consumer electronic device 130. In some embodiments, the user 120 is a patient receiving treatment from a physician. In these embodiments, the patient may operate the user electronic device 130 to retrieve the electronic medical records of the user 120 to assist in the treatment at or prior to the treatment.

The consumer electronic device 130 is an electronic device configured to communicate over a network to perform electronic record access and management operations. Consumer electronic device 130 may be any type of electronic device configured to exchange communications over network 110 to request electronic records and to receive electronic records. For example, the consumer electronic device 130 may be a personal computer, a server, or a mobile device. For example, the consumer electronic device 130 may be a wireless telephone, a cellular telephone, a mobile Personal Digital Assistant (PDA) with embedded cellular telephone technology, or a smart phone. The consumer electronic device 130 may include an integrated display configured to display the recorded information and/or may be configured to control a separate display to display the recorded information. The consumer electronic device 130 may include a plurality of electronic components and may include a plurality of electronic devices. In some implementations, the consumer electronic device 130 may be configured to access an electronic medical or health record of the user 120 and display the medical or health record on a display associated with the consumer electronic device 130. In these embodiments, the user 120 may present the display to the medical service provider to enable the service provider to view the electronic medical record. In other embodiments, the consumer electronic device 130 may be configured to establish a connection with a device associated with a medical services provider and transmit an electronic medical record to the device to enable the medical services provider to display and/or store the electronic medical record.

The plurality of record storage systems 140, 150, and 160 are electronic systems configured to store electronic data and exchange communications over a network. The plurality of record storage systems 140, 150, and 160 may be electronic systems configured to store electronic records and exchange communications with consumer electronic devices 130 over network 110. For example, the plurality of record storage systems 140, 150, and 160 may include personal computers, servers, or databases. Each of the plurality of record storage systems 140, 150, and 160 includes a memory or storage device configured to store electronic data. The memory or storage device may be configured to store data using, for example, magnetic, optical, and/or solid state technology. For example, the memory or storage devices may include a hard disk, a tape drive, an optical disk, a random access memory ("RAM"), and/or a read-only memory ("ROM"). The plurality of record storage systems 140, 150, and 160 may include a plurality of electronic components and/or a plurality of electronic devices or systems. Although FIG. 1 shows three record storage systems, any number of record storage systems may be connected to network 110. In certain embodiments, the plurality of record storage systems 140, 150, and 160 store electronic medical records associated with the user 120 and are configured to transmit the electronic medical records to the user electronic device 130 upon request. In these embodiments, the plurality of record storage systems 140, 150, and 160 may be associated with one or more of a doctor, a hospital, a pharmacy, an insurance company, a record storage company, another type of medical service provider, or another type of organization that stores electronic medical records.

The recipient 170 is a person operating a recipient electronic device. For example, the recipient 170 may provide user input to the recipient electronic device 180 to perform an operation on the recipient electronic device 180. In some implementations, the recipient 170 may be a medical service provider (e.g., a doctor) that provides therapy to the user 120, and may use the recipient electronic device 180 to access electronic medical records of the user 120 to assist in treating the user 120.

The recipient electronic device 180 is an electronic device configured to communicate with other electronic devices to perform record access and management operations. The recipient electronic device 180 may be any type of electronic device configured to exchange communications over the connection 190. For example, the recipient electronic device 180 may be a personal computer, a server, or a mobile device. For example, the recipient electronic device 180 may be a wireless telephone, a cellular telephone, a mobile Personal Digital Assistant (PDA) with embedded cellular telephone technology, or a smart phone. The recipient electronic device 180 may include an integrated display configured to display the recorded information and/or may be configured to control a separate display to display the recorded information. The recipient electronic device 180 may include a plurality of electronic components and may include a plurality of electronic devices. In some implementations, the recipient electronic device 180 can be configured to receive the medical record of the user 120 from the user electronic device 130 and display the electronic medical record on a display associated with the recipient electronic device 180. The recipient electronic device 180 may be a computer system operated by a medical service provider (e.g., a doctor) in a treatment facility (e.g., a doctor's office or hospital).

The connection 190 is configured to enable electronic communications to be exchanged between devices connected to the connection 190. For example, the connection 190 may be configured to enable exchange of electronic communications between the consumer electronic device 130 and the recipient electronic device 180. The connection 190 may include a wired or wireless data channel. For example, the connection 190 may be a bluetooth connection between the consumer electronic device 130 and the recipient electronic device 180. In another example, the connection 190 is a direct wired connection (e.g., a Universal Serial Bus (USB) connection, an IEEE 1394(Fire Wire) connection, etc.) only between the consumer electronic device 130 and the recipient electronic device 180. In this example, the direct wired connection ensures secure transfer between the consumer electronic device 130 and the recipient electronic device 180 because the other devices cannot intercept communications over the direct wired connection. In some embodiments, connection 190 is a network similar to network 110. In other embodiments, the connection 190 is not required, and the consumer electronic device 130 and the recipient electronic device 180 may exchange electronic communications over the network 110. In certain embodiments, connection 190 facilitates the secure exchange of electronic medical records to maintain the integrity and privacy of electronic medical records exchanged over connection 190. For example, as described above, the connection 190 may be a direct wired connection between only the consumer electronic device 130 and the recipient electronic device 180. In other examples, connection 190 facilitates a Virtual Private Network (VPN) connection or another type of authentication and/or encryption connection sufficient to gracefully protect data exchanged over connection 190.

Fig. 2 is a flow diagram of a process 200 for accessing and presenting electronic medical records. For convenience, process 200 is performed with reference to specific components described with reference to fig. 1. However, a similar approach may be applied in other embodiments where different components are used to define the system structure or where functionality is distributed differently among the components shown in FIG. 1.

The consumer electronic device 130 receives a user input requesting a record (202). In some implementations, the user electronic device 130 can receive user input provided by the user 120 indicating a request for a medical record associated with the user 120. For example, the user 120 may provide a user input to the consumer electronic device 130 indicating that an electronic medical record is requested by selecting an icon presented on a graphical user interface of a display associated with the consumer electronic device 130 that is configured to initiate a request for the electronic medical record. In another example, the user 120 may enter commands into a user interface presented on a display associated with the user electronic device 130 using a keyboard or keypad to request an electronic medical record. In some implementations, the user 120 can submit the request for the electronic medical record by interacting with a user interface (e.g., interface 400 described below with reference to FIG. 4) presented on a display associated with the user electronic device 130. In other implementations, the medical services provider may operate the user electronic device 130 to initiate a request for an electronic medical record associated with the user 120. In these embodiments, the storage system storing the electronic medical records of the user 120 may require input (e.g., authentication credentials) from a medical service provider in order to authenticate or authorize the request for the electronic medical records prior to sending the electronic medical records to the user electronic device 130.

The user electronic device 130 accesses the authentication token (204). For example, the consumer electronic device 130 accesses a hardware-specific machine token stored in electronic memory associated with the consumer electronic device 130. In this example, the hardware-specific machine token may be configured to enable a storage system (e.g., storage systems 140 and 150) to identify and authenticate the electronic device requesting the electronic medical record. The hardware-specific machine token may be specific to the user electronic device 130 so that the storage systems (e.g., storage systems 140 and 150) may verify that a request for an electronic record of a particular patient has been received from the physical device associated with that patient. In this example, a request for an electronic medical record associated with the user 120 may be denied unless it is received from the consumer electronic device 130 associated with the user 120. For example, the user 120 may be receiving a doctor's treatment at a doctor's office. The physician may ask the user 120 questions about the user's medical history without the user knowing the answers. In response, the user 120 may use the user electronic device 130 as a secure channel to access the user's electronic medical records to answer questions posed by a physician. By enabling the user 120 to quickly access his or her electronic medical records, the user 120 may be able to provide accurate information to the physician in real-time that is needed for treatment, or at least without the delays associated with requesting and delivering medical records to the physician's office. Also, in this example, because the request must come from the user electronic device 130, appropriate security measures are provided to ensure privacy of the electronic medical records of the user 120.

In other implementations, the authentication token may include or be capable of determining other types of authentication information, such as authentication credentials (e.g., username and password), cookies, encryption keys, or other types of authentication information. In some examples, the patient (or healthcare provider) may be required to enter authentication credentials, and the authentication credentials may be used as part of the authentication token. In these examples, the authentication credentials may be combined with a hardware-specific machine token, such that a request for an electronic medical record associated with the user 120 may be denied unless the request is received from a physical user electronic device 130 associated with the user 120 and includes valid authentication credentials for the user 120 and/or a healthcare provider.

In certain embodiments, a valid hardware-specific machine token and authentication credentials from an approved or certified medical service provider (rather than a patient) may be sufficient to authenticate a request for an electronic medical record associated with a patient. For example, a storage system storing electronic medical records may include a list of approved or certified medical service providers and authentication credentials associated with the medical service providers. In this example, the medical services provider may submit a request for electronic medical records of the user 120 using the user electronic device 130. The medical service provider may provide authentication credentials with the request and the storage system storing the electronic medical records of the user 120 may authenticate the medical service provider. In response to authenticating that the request is from an approved medical service provider and from a consumer electronic device 130 associated with the user 120, the storage system may provide the requested electronic medical record of the user 120 to the consumer electronic device 130 for display on the consumer electronic device 130. In this example, a medical services provider approved to provide emergency care to the user 120 may be able to quickly access the electronic medical records of the user 120 in the event that the user is unable or unable to request the electronic medical records and the medical services provider has access to the user electronic device 130. For example, the user 120 may be a victim of an accident in which the user 120 is injured and unconscious. In this example, a medical service provider that is providing emergency care to the user 120 at a venue may obtain the user electronic device 130 from the user's 120 body, enter authentication credentials, and access the user's 120 electronic medical records. By enabling the medical service provider to access the electronic medical records of the user 120, the medical service provider may be able to provide more effective and safer treatment to the user 120. Also, in this example, because the request must come from an approved medical service provider and from the user electronic device 130, appropriate security measures may be provided to ensure privacy of the electronic medical records of the user 120.

The user electronic device 130 creates a first request for an electronic medical record based on the accessed authentication token (206). For example, the user electronic device accesses information associated with a first storage system (e.g., storage system 140) that stores the electronic medical record included in the request and generates a request for the electronic medical record stored by the first storage system based on the accessed information and the accessed authentication token. In some examples, the accessed information may include information regarding a network address of the first storage system and format information of the request to the first storage system. In these examples, consumer electronic device 130 may generate a request addressed to the first storage system and having a format used by the first storage system. The consumer electronic device 130 also includes information associated with the accessed authentication token in the first request. For example, the user electronic device 130 may include the authentication token in the first request, or generate a request including information based on the accessed authentication token. For example, the consumer electronic device 130 may encrypt the first request using information included in the authentication token, such that the storage system may decrypt the request only if the request is encrypted with a valid authentication token. The first request may also include information identifying the user and/or the electronic medical record requested in the request.

The user electronic device 130 creates a second request for the electronic medical record based on the accessed authentication token (208). The consumer electronic device 130 may create the second request in a manner similar to the manner in which the first request is created as described above with respect to step 206. The second request may be addressed to a second storage system (e.g., storage system 150) that stores the electronic medical record included in the request. The second storage system may be different from the first storage system. Accordingly, the second request may include a different address and may have a different format than the first request.

Consumer electronic device 130 transmits (210) the first request to storage system 140 and the second request to storage system 150. For example, the consumer electronic device 130 may transmit a first request for an electronic medical record as an electronic communication over the network 110 to the storage system 140, and the consumer electronic device 130 may transmit a second request for an electronic medical record as an electronic communication over the network 110 to the storage system 150. The consumer electronic device 130 may transmit the first request and the second request simultaneously, or may transmit the first request before or after the second request. For example, consumer electronic device 130 may transmit a first request to storage system 140 and wait to receive a response from storage system 140 before transmitting a second request. In this example, the consumer electronic device 130 may analyze the response from the storage system 140, customize or modify the second request to only request electronic medical records that were not received in the response from the storage system 140, and transmit the modified second request to the storage system 150.

The storage system 140 receives a first request (212). For example, the storage system 140 receives a first request for an electronic medical record from the user electronic device 130 over the network 110. The first request may include information sufficient for the storage system 140 to identify the user, identify the requested electronic record of the user, and an authentication token.

The storage system 140 authenticates the first request based on the authentication token (214). For example, in embodiments where the authentication token comprises a hardware-specific machine token, the storage system 140 extracts the hardware-specific machine token from the first request and authenticates the first request based on the hardware-specific machine token. In this example, the storage system 140 may compare the hardware-specific machine token with a token known to be associated with the user 120 associated with the first request and authenticate the first request based on the comparison. Since the hardware-specific machine token is specific to the consumer electronic device 130, the storage system 140 may be configured to only authenticate requests from the consumer electronic device 130.

In some implementations, the authentication token can include authentication credentials for the user 120 associated with the request for the record or for the healthcare provider. In these embodiments, the storage system 140 may extract the authentication credentials from the authentication token, compare the authentication credentials to known authentication credentials for the user 120 or healthcare provider, and authenticate the first request based on the comparison. Since the authentication credentials are specific to the user associated with the record or to an approved healthcare provider, the storage system 140 may be configured to authenticate the request based only on the person making the request. Authenticating the first request based on the authentication credential may be performed in addition to or in lieu of authenticating the first request based on a hardware-specific machine token.

The storage system 140 accesses the electronic medical record associated with the first request (216). For example, the storage system 140 may access the electronic medical record associated with the first request from electronic storage associated with the storage system 140. In this example, the storage system may access all electronic medical records associated with the user identified in the first request, or may access a particular electronic record identified by the first request. In some embodiments, the first request may include a restriction or condition on the electronic medical record requested in the first request. For example, the first request may indicate that only certain types of electronic medical records (e.g., only orthopedic medical records) or only electronic medical records for a certain period of time (e.g., only the last five years of electronic medical records) should be accessed. In this example, the storage system 140 may access the user's electronic medical records based on these restrictions or conditions. In other examples, the restrictions or conditions may be associated with a particular user or may be preset by the user. For example, an orthopaedic doctor may only have access to records associated with orthopaedic treatment and may not have access to other types of medical records. In another example, a user may set a limit or condition to a recording request made to the storage system 140 in advance, and the storage system 140 may be configured to process the recording request based on the limit or condition set by the user. In this example, the user may decide to prevent particularly difficult or painful medical records from being accessed through the record request, while storage system 140 may prevent access to those records upon receiving an electronic request for those records. Storage system 140 may be configured to provide a message to the person requesting the restricted records indicating that access to those records has been restricted by the user.

The storage system 140 transmits the accessed electronic medical records to the user electronic device (218). For example, the storage system 140 may transmit the accessed electronic medical records to the user electronic device 130 as one or more electronic communications over the network 110. The transmission of the electronic medical record may be a secure transmission of the electronic medical record. For example, the electronic record may be encrypted and transmitted using another security technique for transmitting electronic information over a network. Further, the transmission of the electronic record may include transmitting authentication information (e.g., an authentication token as described with reference to the user electronic device 130). The consumer electronic device 130 may employ the authentication information to authenticate the electronic medical records so that the consumer electronic device 130 can verify that the electronic medical records are legitimate.

The storage system 150 receives the second request (220), authenticates the second request (222), accesses the electronic medical record associated with the second request (224), and transmits the accessed electronic medical record to the user electronic device (226). The storage system 150 may perform steps 220-226 using techniques similar to those described above with reference to the storage system 140 performing steps 212-218. Although the request for the electronic medical record is shown as being sent to two storage systems, the request for the electronic medical record may also be sent to more than two storage systems or only a single storage system.

The consumer electronic device 130 receives electronic medical records from the storage system 140 and the storage system 150 (228). For example, consumer electronic device 130 receives electronic medical records from storage system 140 and storage system 150 in the form of electronic communications sent over network 110. In this example, the electronic communication and the electronic medical record may be encrypted, exchanged over a secure connection, or protected from undesired or improper access. The electronic communication and the electronic medical record may include authentication information, wherein the user electronic device may authenticate the received electronic medical record with the authentication information to ensure that the received electronic medical record is authentic. In some implementations, the user electronic device 130 can be configured to display the received electronic medical record. In these embodiments, the medical services provider may view the electronic medical records presented by the user electronic device 130 on a display while providing the treatment or service to the user.

The consumer electronic device 130 establishes a secure connection with the recipient electronic device 180. For example, the consumer electronic device 130 may establish a secure connection with the recipient electronic device 180 via connection 190. In some examples, the consumer electronic device may be configured to establish a secure connection with the recipient electronic device 180 through a wired connection only between the consumer electronic device 130 and the recipient electronic device 180 (and perhaps other trusted devices). For example, in these examples, the user electronic device 130 may establish a wired connection with a computer in the doctor's office through a direct USB connection, or may establish a wired connection with a computer in the doctor's office through a local area network included in the doctor's office. In other examples, the consumer electronic device 130 may establish a secure connection with the recipient electronic device 180 over a wireless connection.

The consumer electronic device 130 transmits the electronic medical record to the recipient electronic device over the secure connection (232), and the recipient electronic device receives the electronic medical record (234). For example, the consumer electronic device 130 may transmit the electronic medical record to the recipient electronic device 180 over the secure connection in the form of an electronic communication, which the recipient electronic device 180 may receive.

The recipient electronic device 180 displays and optionally stores the electronic medical record (236). For example, the recipient electronic device 180 may display the received electronic medical record on a display device associated with the recipient electronic device 180 so that the medical services provider may view the electronic medical record presented by the recipient electronic device 180 on the display when providing the treatment or service to the user. In this example, the recipient electronic device 180 may display an X-ray image or electronic medical chart entry received with the electronic medical record. The recipient electronic device 180 may also store the electronic medical records in electronic memory for recording and later retrieval.

Fig. 3 is a flow diagram of a process 300 for accessing and presenting electronic medical records. For convenience, the process 300 is performed with reference to the specific components described with reference to fig. 1. However, a similar approach may be applied in other embodiments where different components are used to define the system structure or where functionality is distributed differently among the components shown in FIG. 1.

The consumer electronic device 130 receives a user input requesting an electronic medical record (310). For example, the user 120 may provide user input (e.g., using a keyboard, keypad, mouse, stylus, etc.) to the user electronic device 130 to initiate a request for an electronic medical record. In other examples, the recipient 170 may enter user input into the consumer electronic device 130, or the consumer electronic device 130 may receive user input from, for example, the recipient electronic device 180 over the connection 190 or the network 110.

The consumer electronic device 130 determines the desired electronic medical record based on the user input (320). For example, the user electronic device 130 determines whether the request for a record requests all of the electronic medical records associated with the user 120 or only a desired subset of the electronic medical records. In some implementations, the request may be for some type of electronic medical record. For example, the request may be for electronic medical records regarding plastic and muscle treatment. In other implementations, the request may be for records from a specified provider. For example, the request may be for electronic medical records from a particular doctor and a particular hospital. In further embodiments, the request may be for a record from a particular time period. For example, the request may be for electronic medical records within the last decade. Other embodiments may enable the user to impose other restrictions on the recording request, and may enable the user to impose multiple restrictions on the recording request.

The consumer electronic device 130 determines the location of the desired electronic medical record (330). For example, the consumer electronic device 130 may determine whether the consumer electronic device 130 stored the requested record locally on the consumer electronic device 130 or whether an electronic device located at a remote location stored the requested record. The consumer electronic device 130 determines, for each requested record, the electronic device that stores the requested record. In some implementations, the consumer electronic device 130 can determine that the consumer electronic device 130 stores a portion of the requested record locally and that each of the plurality of record storage systems 140, 150, and 160 stores a portion of the requested record.

After determining the location of the desired recording, the consumer electronic device 130 sends a communication requesting the recording to the electronic device that stored the requested recording (340). For example, the consumer electronic device 130 may send an electronic communication over the network 110 to the plurality of record storage systems 140, 150, and 160 to request a record. The electronic communication may identify the user 120 requesting the record, the consumer electronic device 130 requesting the record, the recipient 170 that may receive the record, the requested record, and/or restrictions imposed on the record request.

The consumer electronic device 130 receives a record sent by the electronic device storing the requested record in response to receiving the communication requesting the record (350). For example, consumer electronic device 130 may receive electronic records from the plurality of record storage systems 140, 150, and 160 via network 110. In one embodiment, the consumer electronic device 130 may also access records stored locally on the consumer electronic device. In another embodiment, the consumer electronic device 130 may receive the recording from the recipient electronic device 180 over the connection 190. The consumer electronic device 130 may receive all of the requested records or may receive only a portion of the requested records. If the consumer electronic device 130 receives only a portion of the requested records, the consumer electronic device 130 may again send the communication requesting the records, and/or may update the display to inform the user 120 that all of the requested records have not been received, and may request further user input on how to proceed (e.g., whether to continue requesting the records and/or whether to cancel restrictions, such as restrictions on the record provider, when making subsequent record requests). When the consumer electronic device 130 receives the record, the consumer electronic device 130 may send an acknowledgement to the electronic device that sent the electronic record.

The consumer electronic device 130 displays the recorded information (360). For example, consumer electronic device 130 may display the recorded information on a display of consumer electronic device 130, or may control a separate display device to display the recorded information. The record information may include one or more of a list of received records, statistical information associated with the records, and/or received electronic records. In one embodiment, the received record may be a medical record and the user electronic device 130 may display a list of records. The list of records may be organized by type, provider, and/or date. The user 120 or recipient 170 may browse the electronic records using a list of records displayed on the consumer electronic device 130. For example, the user 120 or the recipient 170 may enter user input into the user electronic device 130 to display the medical record of interest.

Optionally, the consumer electronic device 130 may transmit the recording to the recipient electronic device 180 (370). The consumer electronic device 130 may transmit the record to the recipient electronic device 180 via the connection 190 or the network 110. The recipient electronic device 180 can display the recorded information on a display of the recipient electronic device 180 or can control a separate display device to display the recorded information. The recipient electronic device 180 can store the received record locally on the recipient electronic device 180 or can store the received record on another device associated with the recipient 170 that is configured to store the electronic record. In one embodiment, the received record may be a medical record of the user 120 and the recipient 170 may be a physician who provides treatment to the user 120. In such an embodiment, the physician may use the recipient electronic device 180 to display the medical records of the user 120. The display of the recipient electronic device 180 may be more suitable for displaying electronic medical records than the display of the user electronic device 130.

Fig. 4 illustrates an exemplary user interface 400 for requesting a record. A user interface 400 may be presented to a user of the consumer electronic device requesting the recording. In one embodiment, as shown, the user interface 400 may be used to request medical records associated with a user.

The user interface 400 includes a name text field 405, an identification text field 410, an authorization code text field 415, a request all available records selection box 420, a restrictions to providers section 430, a restrictions to types section 440, a restrictions to dates section 460, a request records interface actionable item 470, and a cancel interface actionable item 475.

Name text field 405 identifies the name of the user of the consumer electronic device and enables the user to modify the name. The user's name may be used to identify the record for retrieval and/or authentication processing.

The identification text field 410 identifies an identification number of a user of the consumer electronic device and enables the user to modify the identification number. The user's identification number may be used to identify the record for retrieval and/or authentication processing. The identification number may be, for example, a social security number of the user.

The authorization code text field 415 identifies the authorization code for the user of the consumer electronic device and enables the user of the consumer electronic device to modify the authorization code. The user's authorization code may be used for the authentication process. For example, the consumer electronic device may provide an authorization code to the record storage provider, which provides the record to the consumer electronic device only if the record storage provider receives a valid authorization code.

The request all available records selection box 420 enables a user to indicate that all available records for the user should be requested without limitation. When the request all available records checkbox 420 is selected, the restrictions to providers 430, restrictions to types 440, and restrictions to dates 460 may be hidden or disabled.

The restrictions on providers section 430 includes checkboxes 431-437 that enable the user to indicate that records should be requested only from the provider identified by the selected checkbox. Selection boxes 431-437 may enable a user to limit providers to a particular doctor, hospital, pharmacy, insurance company, record storage company, and/or any other provider. For example, selection box 431 may enable a user to limit Records to those from the provider Health host, selection box 432 may enable a user to limit Records to those from the provider dr.jones, selection box 433 may enable a user to limit Records to those from the provider Good drug pharma, selection box 434 may enable a user to limit Records to those from the provider dr.reed, selection box 435 may enable a user to limit Records to those from the provider Premium instrument co, selection box 436 may enable a user to limit Records to those from the provider Health Records Database co, and selection box 437 may enable a user to limit Records to those from all other providers. The user interface 400 may include a selection box for all providers where the user has medical records, all providers where the user has a threshold number of medical records, or a certain number of providers where the user has the most medical records.

The restricted portion of types 440 includes a selection box 441- < - > 455 that enables a user to indicate that only records of the type identified by the selected selection box should be requested. Selection box 441-. For example, selection box 441 may enable a user to limit records to General Medical type records, selection box 442 may enable a user to limit records to Cardiovasular type records, selection box 443 may enable a user to limit records to Respirotory type records, selection box 444 may enable a user to limit records to neurologic type records, selection box 445 may enable a user to limit records to Orthopic type records, selection box 446 may enable a user to limit records to Musculus type records, selection box 447 may enable a user to limit records to Dermatologicals type records, selection box 448 may enable a user to limit records to Surgical type records, selection box 449 may enable a user to limit records to Allergies type records, selection box 450 may enable an Immunizans type records, selection box 451 may enable a user to limit records to homogeneity type records, selection box 452 may enable a user to restrict records to records of the Psychiatric type, selection box 453 may enable a user to restrict records to records of the Dental type, selection box 454 may enable a user to restrict records to records of the Vision type, and selection box 455 may enable a user to restrict records to records of the Insurance record type. The user interface 400 may include a selection box for all types that the user has medical records, all types that the user has a threshold number of medical records, or a certain number of types that the user has the most medical records.

The Date restricted portion 460 includes selection boxes 461-463, a Start Date (Start Date) text field 464, and an End Date (End Date) text field 465. Selection boxes 461 and 463 enable the user to indicate that recording of only the particular time period identified by the selected selection box should be requested. Selection box 461-463 enables the user to indicate that only those medical records not earlier than a particular time should be requested. For example, selection box 461 may enable a user to limit recording to records with dates within the last year, selection box 462 may enable a user to limit recording to records with dates within the last five years, and selection box 463 may enable a user to limit recording to records with dates within the last ten years. The selection boxes 461 & 463 may be mutually exclusive and the start date text field 464 and the end date text field 465 may be hidden or disabled when one of the selection boxes 461 & 463 is selected. The start date text field 464 and the end date text field 465 enable the user to specify a custom time period in which the user wishes to request medical records therein. The start date text field 464 identifies the start date of the time period for which recording is requested and enables the user to modify the start date. An end date text field 465 identifies the end date of the time period for which recording is requested and enables the user to modify the end date.

Request record interface actionable item 470, when activated, initiates a record request operation using information currently displayed by user interface 400. Cancel interface actionable item 475, when activated, cancels the record request operation.

Fig. 5 is a flow diagram of a process 500 for adding electronic medical records. For convenience, process 500 is performed with reference to specific components described with reference to fig. 1. However, a similar approach may be applied in other embodiments where different components are used to define the system structure or where functionality is distributed differently among the components shown in FIG. 1.

The consumer electronic device 130 receives a request to add an electronic medical record (510). For example, the user electronic device 130 may receive a request to add an electronic medical record associated with the user 120. In one embodiment, the request to add a recording may be received based on user input provided to the consumer electronic device 130 by the user 120 or the recipient 170. In another embodiment, the request to add a record may be received in electronic communication over connection 190 or network 110. For example, recipient electronic device 180 may send a request to add a record to consumer electronic device 130 via connection 190, or one of the plurality of record storage systems 140, 150, and 160 may send a request to add a record to consumer electronic device 130 via network 110. In one embodiment, the recipient 170 may use the recipient electronic device 180 to send a request to add a record to the consumer electronic device 130 over connection 190. In this embodiment, the record may be a medical record of the user 120 based on the treatment and/or diagnosis provided by the recipient 170.

The consumer electronic device 130 receives the new recorded information (520). For example, the consumer electronic device 130 may receive new record information regarding records associated with the user 120. In one embodiment, the new recording information may be received based on user input provided to the consumer electronic device 130 by the user 120 or the recipient 170. In another embodiment, the new record information may be received in electronic communication over connection 190 or network 110. For example, recipient electronic device 180 may send the new record information to consumer electronic device 130 via connection 190, or one of the plurality of record storage systems 140, 150, and 160 may send the new record information to consumer electronic device 130 via network 110. The new recording information includes information on the new recording. For example, the new record information may include information identifying the new record, information identifying the location and/or electronic device where the new record is stored, information regarding the type, provider, and/or date of the new record, and/or information identifying the user associated with the record. In one embodiment, the new record information may include information regarding a new medical record for the user 120. In this embodiment, the new recording information may indicate: the record is for user 120, the record is about the treatment received by recipient 170, the date of the treatment, and the electronic device storing the new record (e.g., recipient electronic device 180 or one of the plurality of record storage systems 140, 150, and 160).

The consumer electronic device 130 updates the log information (530). For example, the consumer electronic device 130 may update data regarding records associated with the user 120. The updated data may include data sufficient to identify the new record and retrieve the new record upon request. In one embodiment, the consumer electronic device 130 may update a database of medical record information associated with the consumer 120. In this embodiment, the consumer electronic device may update a database stored locally on the consumer electronic device 130 and/or may update a database stored remotely with respect to the consumer electronic device 130. The updated record information may indicate that the user's new medical record is stored on a particular electronic device and may include information regarding the type, provider, and date of the medical record.

Optionally, the consumer electronic device 130 may receive a new electronic record (540). For example, the consumer electronic device 130 may receive a new electronic record associated with the user 120. In one embodiment, the new electronic record may be received based on user input provided to the consumer electronic device 130 by the user 120 or the recipient 170. In another embodiment, the new electronic record may be received in electronic communication over connection 190 or network 110. For example, recipient electronic device 180 may send the new electronic record to consumer electronic device 130 via connection 190, or one of the plurality of record storage systems 140, 150, and 160 may send the new electronic record to consumer electronic device 130 via network 110. In one embodiment, the recipient 170 may use the recipient electronic device 180 to send the new electronic record to the consumer electronic device 130 over the connection 190. In this embodiment, the new electronic record may be a medical record of the user 120 based on the treatment and/or diagnosis provided by the recipient 170.

Optionally, the consumer electronic device 130 may store the new electronic record (550). For example, the consumer electronic device 130 may store the new electronic record in a local memory of the consumer electronic device 130. In one embodiment, the new electronic record may be a medical record, the consumer electronic device 130 may maintain a medical record database of the user 120, and the consumer electronic device 130 may update the medical record database by storing the new electronic record.

Optionally, the consumer electronic device 130 may transmit the new electronic record to the database provider (560). For example, consumer electronic device 130 may transmit the new electronic record to a database provider over network 110 or connection 190. In one embodiment, consumer electronic device 130 may receive a new electronic recording from recipient electronic device 180 over connection 190 and may transmit the new electronic recording to one of the plurality of record storage systems 140, 150, and 160 over network 110. In this embodiment, one of the plurality of record storage systems 140, 150, and 160 stores the new electronic record, and the consumer electronic device 130 may update the record information stored on the consumer electronic device indicating that the new electronic record is stored on one of the plurality of record storage systems 140, 150, and 160.

Fig. 6 illustrates an exemplary user interface 600 for adding a record. User interface 600 may be presented to a user electronic device configured to augment a recording or a user of a recipient electronic device. In one embodiment, as shown, the user interface 600 may be used to augment medical records associated with a user.

User interface 600 includes a patient information section 610, a patient device information section 620, a record information section 630, a local store selection box 650, a send to database provider selection box 660, an add record interface actionable item 670, and a cancel interface actionable item 680.

Patient information section 610 includes a name text field 611, an address text field 612, a phone number text field 613, an e-mail text field 614, and an identification number text field 615. Name text field 611 identifies the name of the person associated with the record and enables the user to modify the name. The address text field 612 identifies the address of the person associated with the record and enables the user to modify the address. Phone number text field 613 identifies the phone number of the person associated with the record and enables the user to modify the phone number. The email text field 614 identifies the email address of the person associated with the record and enables the user to modify the email address. The identification number text field 615 identifies the identification number of the person associated with the record and enables the user to modify the identification number. The identification number may be, for example, a social security number of the person associated with the record.

The patient device information portion 620 includes a device identification portion 621 and a connection portion 622. The device identification section 621 includes a type text field and an identification number text field. The type text field identifies the type of patient device and enables the user to modify the type. The identification number text field identifies the identification number of the patient device and enables the user to modify the identification number. The connection text field 622 identifies the connection type of the patient device and enables the user to modify the connection type of the patient device. The patient device information section 620 enables a user to identify information associated with the patient device for use in sending new record information or new records to the patient device.

The record information section 630 includes a physician text field 631, a category text field 632, a location text field 633, a date text field 634, a time text field 635, a description text field 636, a prescription text field 637, a follow-up appointment text field 638, an attachment text field 639, and a browsing interface actionable item 640. The doctor text field 631 identifies the name of the doctor associated with the new medical record and enables the user to modify the doctor name. Category text field 632 identifies the category associated with the new medical record and enables the user to modify the category. Location text field 633 identifies the location associated with the new medical record and enables the user to modify the location. Date text field 634 identifies the date associated with the new medical record and enables the user to modify that date. The time text field 635 identifies the time associated with the new medical record and enables the user to modify the time. The description text field 636 identifies the description associated with the new medical record and enables the user to modify the description. Prescription text field 637 identifies the prescription associated with the new medical record and enables the user to modify the prescription. When the user types a prescription in the prescription text field 637, the prescription may be automatically sent to the pharmacy when medical records are added. The follow-up appointment text field 638 identifies the follow-up appointment associated with the new medical record and enables the user to modify the follow-up appointment. When the user enters a subsequent appointment in the subsequent appointment text field, a calendar entry for the subsequent appointment may automatically enter the calendar of the doctor and the calendar of the patient. The attachment text field 639 identifies the name of the file to be attached in association with the new medical record and enables the user to modify the name of the file to be attached. An attachment text field 639 may enable a user to attach other files to the medical record, such as images, other records, and/or other documents. For example, the user may attach a patient image file (e.g., xray. jpg 641), a Chart entry image (e.g., Chart entry. pdf 642), and a prescription image file (e.g., description. pdf 643). The browse interface actionable item 640, when activated, may enable a user to browse a local directory of files to be attached to a medical record.

The local store selection box 650 enables the user to indicate that a new medical record should be stored locally. For example, the local storage selection box 650 may enable the user to indicate that the new medical record should be stored locally on the recipient electronic device with which the user is entering new medical record information. In another example, local storage selection box 650 may enable a user to indicate that a new medical record should be stored locally on an electronic device associated with a doctor and/or location associated with the medical record.

The send to database provider selection box 660 enables the user to indicate that a new medical record should be sent to the database provider for storage of the new medical record. For example, the send to database provider checkbox 660 may enable the user to indicate that a new medical record should be sent over the network to the record storage system for archival storage.

Add recording interface actionable item 670, when activated, initiates an add recording operation using information currently displayed by user interface 600. Cancel interface actionable item 680, when activated, cancels the add record operation.

Referring to fig. 7, the aggregation of medical records may be performed relatively anonymously. As shown, three (possibly more or fewer) electronic medical records storage systems 710, 720, and 730 store electronic medical records for patients as follows: that is, the electronic medical records of a particular patient and the user identity information of the particular patient are broken down into the three electronic medical records storage systems 710, 720, and 730. In other words, a violation of one of the three electronic medical records storage systems 710, 720, and 730 will not enable a violating user to identify the particular patient, will not enable the violating user to access the other storage systems using the identification and/or authentication information of the violated storage system, will not provide the violating user with complete access to the entire set of medical records for the particular patient, or even all of the information of the particular record, and will not enable the violating user to identify the other electronic medical records storage systems that store the remaining medical record information for the particular patient. Thus, using the electronic medical record aggregation technique illustrated in fig. 7, electronic medical record storage and aggregation may provide enhanced privacy and anonymity to patients.

The electronic device 740 is used to aggregate and display medical records for a particular patient. The electronic device 740 serves as a secure agent or channel for accessing the disaggregated electronic medical record information stored in the electronic medical record storage systems 710, 720, and 730. In particular, the electronic device 740 may store information identifying the electronic medical records storage systems (e.g., electronic medical records storage systems 710, 720, and 730) that store the electronic medical records for the particular patient, as well as information needed to authenticate and retrieve the electronic medical records for the particular patient from each of the electronic medical records storage systems. In some implementations, the electronic device 740 may communicate with another device over a network or through a direct connection to retrieve information needed to access the disaggregated electronic medical record information stored in the electronic medical record storage systems 710, 720, and 730.

The electronic device 740 includes an input unit 745 (e.g., a keypad, etc.) that enables a user to provide user input to the electronic device 740, and a display 750 that displays electronic medical record information. The electronic device 740 includes a processor configured to control the operation of the electronic device 740, and includes at least one computer-readable storage medium for storing instructions executed by the processor in performing the described processes and storing information used by the electronic device 740 in acting as a secure agent or channel for accessing decomposed electronic medical record information (e.g., identification information for electronic medical record storage systems, identification/authentication information for each electronic medical record storage system, etc.). The electronic device 740 may be similar to the consumer electronic device 130 described above with reference to FIG. 1.

Referring to fig. 7, a particular patient, John Smith, is associated with the electronic device 740. In this example, electronic medical records for John Smith are stored in a disaggregated manner in three electronic medical records storage systems 710, 720, and 730, and the electronic device 740 serves as a secure agent for aggregating and displaying electronic medical records for John Smith. Each of the three electronic medical records storage systems 710, 720, and 730 includes different identification information for John Smith and different authentication information required to obtain electronic medical records for John Smith.

In particular, the electronic medical records storage system 710 stores electronic medical records information 715 for John Smith. As shown, the electronic medical records storage system 710 identifies John Smith and performs authentication of John Smith with the machine token. In this example, the machine Token is labeled Token: 89965. accordingly, to retrieve an electronic medical record for john smith from the electronic medical records storage system 710, the electronic device 740 accesses (e.g., from an electronic storage of the electronic device 740) the machine token 89965 and sends the machine token 89965 to the electronic medical records storage system 710. In response to receiving the machine token 89965, the electronic medical records storage system 710 authenticates the request as being from John Smith, accesses (e.g., from electronic storage of the electronic medical records storage system 710) electronic medical records associated with John Smith, and transmits the accessed electronic medical records to the electronic device 740.

The electronic medical records storage system 720 stores electronic medical records information 725 for John Smith. As shown, the electronic medical records storage system 720 identifies John Smith as UserID: XJ689, and performs authentication of John Smith using password "1234". Accordingly, to retrieve electronic medical records for John Smith from the electronic medical records storage system 720, the electronic device 740 accesses (e.g., from an electronic memory of the electronic device 740) the user identification XJ689 and password "1234" information and transmits the user identification XJ689 and password "1234" information to the electronic medical records storage system 720 in a request for medical records. In response to receiving the user identification XJ689 and password "1234" information, the electronic medical records storage system 720 authenticates the request as being from John Smith based on the user identification and password information, accesses (e.g., from electronic storage of the electronic medical records storage system 720) electronic medical records associated with John Smith, and transmits the accessed electronic medical records to the electronic device 740.

The electronic medical records storage system 730 stores electronic medical records information 735 for John Smith. As shown, the electronic medical records storage system 730 identifies John Smith as UserID: JPFI and performs authentication of John Smith with password "56789". To retrieve electronic medical records for John Smith from the electronic medical records storage system 730, the electronic device 740 uses similar techniques as discussed above for retrieving electronic medical records from the electronic medical records storage system 720, but uses different identification information and passwords.

As such, when the electronic device 740 receives a request to access a medical record (e.g., user input from the input unit 745 regarding accessing electronic medical records for John Smith), the electronic device 740 automatically generates a request for electronic medical records from each of the three electronic medical records storage systems 710, 720, and 730 without human information and aggregates the information for display to the user. More particularly, the electronic device 740 identifies each of the three electronic medical records storage systems 710, 720, and 730 as storing John Smith's records, identifies different identification/authentication information for each of the three electronic medical records storage systems 710, 720, and 730, and generates three separate requests for the three electronic medical records storage systems 710, 720, and 730 using the respective identification/authentication information. The electronic device 740 may also use different communication protocols or formats to send and retrieve electronic medical records for each of the three electronic medical records storage systems 710, 720, and 730.

In response to receiving the request from the electronic device 740, each of the three electronic medical records storage systems 710, 720, and 730 authenticates the request and, if the request is determined to be authentic, accesses and provides the electronic medical record to the electronic device 740. For example, in response to receiving a request from the electronic device 740 that includes the machine token 89965, the electronic medical records storage system 710 accesses the electronic medical records information 715 and sends the electronic medical records information (e.g., records R1: Broken Bone, R6: Heart attach 11/11/04, R7: DOB08/20/1953, R11: Torn ACL 05/08/97, R12: VG04, and R13: Painkiller05/07/07) to the electronic device 740. Further, in response to receiving a request from the electronic device 740 that includes the user ID XJ689 and the password "1234", the electronic medical records storage system 720 accesses the electronic medical records information 725 and transmits the electronic medical records information (e.g., records R2: BP 111/83; 10/20/06, R3: BP 113/80; 04/16/07, R5: OTATI 020, R8: BloodType A +, and R12: IR60) to the electronic device 740. Also, in response to receiving a request from the electronic device 740 that includes the user ID JPFI and the password "56789", the electronic medical records storage system 730 accesses the electronic medical records information 735 and transmits the electronic medical records information (e.g., records R1: Tibia06/06/05, R4: BP 112/86; 04/05/06, R5: CNRCHV 127, R9: Pacemaker 12/12/04, R10: Penicilin 06/01/07, and R12: AA07) to the electronic device 740.

The electronic device 740 receives (e.g., over a network) electronic medical record information from each of the three electronic medical record storage systems 710, 720, and 730 and aggregates the electronic medical record information into a complete set of medical records for John Smith. The electronic device 740 then displays the aggregated electronic medical record information on the display 750.

In presenting the display, the electronic device 740 combines the electronic medical record information 715, 725, and 735 received from each of the three electronic medical record storage systems 710, 720, and 730, respectively. The electronic device 740 identifies records that include complete information (e.g., the information of the records is from only one source, although the information may or may not include all of the information typically associated with the records), and may display the records without further processing. As shown in fig. 7, the records R2-R4, R6-R11, and R13 are complete records, and the electronic device 740 can combine the records into an aggregated/integrated display without additional processing.

For partial recordings (e.g., recordings where the recorded information is received from multiple sources), the electronic device 740 processes the received individual segments of each recording and generates a complete recording based on the individual segments when aggregating the recordings. The local recording may be used for more sensitive information that guarantees additional privacy protection. Since generating a complete record requires several pieces of information from several decomposed sources, infringement of the complete record may be more difficult.

For example, the records R1, R5, and R12 represent local records. As shown, the record R1 includes information stored in the electronic medical records storage system 710 (e.g., R1: BrokenBone) and information stored in the electronic medical records storage system 730 (e.g., R1: Tibia 06/06/05). Information stored in both electronic medical records storage systems 710 and 730 is required to determine a complete medical record. In particular, the information stored in the electronic medical records storage system 710 indicates that the patient has suffered a fracture (brooken bone), but does not indicate where or when the fracture occurred. The information stored in the electronic medical records storage system 730 indicates medical records related to the Tibia (Tibia) at date 06/06/05, but does not indicate what disease or treatment occurred in 06/06/05 in relation to the Tibia. In combination, the electronic device 740 determines that the patient has suffered a tibial fracture at 06/06/05, and may combine the partial records to display a "R1: broken Tibia06/06/05 ".

Records R5 and R12 are examples of electronic medical records stored across multiple storage systems, where specific processing is required to combine local information when generating a complete record. In particular, the record R5 includes information stored in the electronic medical records storage system 720 (e.g., R5: OTATI 020) and information stored in the electronic medical records storage system 730 (e.g., R5: CNRCHV 127). To generate the complete record R5, the electronic device 740 interleaves the characters included in the partial records received from the electronic medical records storage systems 720 and 730, starting with the characters included in the electronic medical records storage system 730. By doing so, the electronic device 740 determines that the patient is infected (contract) with HIV at 01/22/07, and may combine these local records to appear as "R5: contract HIV01/22/07 ". Accordingly, to determine that the patient is HIV infected at 01/22/07, the offending user would have to intercept the information stored in the electronic medical records storage system 720 (e.g., R5: OTATI 020) and the information stored in the electronic medical records storage system 730 (e.g., R5: CNRCHV 127) and know the specific processing required to combine these information. Violating electronic medical record information stored in this manner can be difficult because intercepting one of the local records will not cause intelligible information about the record to be known, and because the local records are retrieved with different identification/authentication information and do not include information about the combining process or other record sources, intercepting a single part of a record does not cause an offending user to discover other parts of the record or the process required to combine the various resolved parts.

In another example, record R12 includes information stored in electronic medical records storage system 710 (e.g., R12: VG04), information stored in electronic medical records storage system 720 (e.g., R12: IR60), and information stored in electronic medical records storage system 730 (e.g., R12: AA 07). To generate a complete record R12, the electronic device 740 interleaves the characters included in the partial records received from the electronic medical records storage systems 710, 720, and 730, starting with the characters included in the electronic medical records storage system 710 through to the electronic medical records storage system 730. By doing so, the electronic device 740 determines that the patient was prescribed Viagra at 06/04/07, and may combine the local records to appear as "R12 when the medical record R12 is displayed: VIAGRA 06/04/07'. Although specific examples of combining local electronic medical records are described, other processes and techniques for combining local records to preserve anonymity may also be used and/or combined with other techniques such as encryption.

In some implementations, the electronic device 740 displays based on the aggregated electronic medical records (e.g., a complete record received as a complete record, and a partial record that has been combined to generate a complete record). In displaying the aggregated electronic medical records, the electronic device 740 may organize the display based on a plurality of factors. For example, as shown in fig. 7, the electronic device 740 may arrange the aggregated electronic medical records by date. In this example, the records R1 to R6 and R9 to R13 are arranged in reverse chronological order: r12, R10, R13, R3, R5, R2, R4, R1, R9, R6 and R11. Records R7 (Date of Birth) and R8 (blood type) are not associated with Date. Thus, records R7 and R8 may be displayed first or in a separate section that distinguishes dated medical records from non-dated medical records. A filter to the electronic medical record date may be used (e.g., electronic medical records older than a particular threshold, such as ten years, may be removed, or a particular date range for aggregating electronic medical records may be defined, and only electronic medical records from that defined date range may be aggregated). Other rules may be used in organizing the display of the electronic medical records, such as displaying the electronic medical records based on the category and/or source of the electronic medical records.

The electronic device 740 may perform statistical processing on the electronic medical record data and display the results of the statistical processing. Displaying the results of the statistical processing performed on the electronic medical records may make the electronic medical record data easy to understand and use by the medical service provider. In some implementations, the electronic device 740 can average electronic medical record data included in a plurality of electronic medical records received from one or more sources. As shown in fig. 7, the electronic device 740 may calculate an average blood pressure for a patient (e.g., John Smith) using the electronic device 740. The electronic device 740 may recognize that the records R2-R4 include previous blood pressure data and average the blood pressure data received in the records R2, R3 from the electronic medical records storage system 720 and the record R4 from the electronic medical records storage system 730. As shown, the electronic device 740 determines and displays a mean blood pressure as Average BP-112/83. The electronic device 740 may perform other statistical processing on the aggregated electronic medical records and may determine and display other results.

The electronic device 740 may also group the aggregated electronic medical record data. The electronic device 740 may identify a plurality of electronic medical records that belong to a particular category. For example, the electronic device 740 may group electronic medical records related to the heart (heart) into one category, and may also group electronic medical records related to drugs (medicine) currently used by the patient and/or used in the past. The electronic device 740 may identify the records R6 and R9 as being cardiac related and group the records R6 and R9. The electronic device 740 may also identify records R10, R12, and R13 as being drug related and group records R10, R12, and R13 into a group. As shown in fig. 7, the electronic device 740 may display the categories of electronic medical records that are grouped and the number of electronic medical records that have been grouped into the categories (e.g., Heart (2) and Medicine (3)). Clicking on the displayed item associated with the heart group or the medication group may display the electronic medical records that have been grouped into that particular category. Grouping records and displaying categories may enable a healthcare provider to more quickly identify important/relevant electronic medical records without having to consult a full set of electronic medical records. Clicking on a particular link may lead to other information related to the recording (e.g., treatment or warning information related to the recording) or more detailed information related to the recording.

While the user perceives that the electronic medical records are all stored on the electronic device 740, the electronic medical records are actually stored in a disaggregated manner on the three electronic medical records storage systems 710, 720, and 730, and the interface provided by the electronic device is a virtual collection of these records. The electronic device 740 serves as a secure channel configured to receive and display the resolved medical record.

Fig. 8 is a flow diagram of a process 800 for anonymously aggregating medical records. For convenience, process 800 is performed with reference to specific components described with reference to fig. 7. However, a similar approach may be applied in other embodiments where different components are used to define the system structure or where functionality is distributed differently among the components shown in FIG. 7.

The electronic device 740 initiates a process of aggregating electronic medical records associated with a patient (805). The process may be initiated in response to the patient providing user input to an electronic device associated with the patient. For example, the patient may enter a command to display the electronic medical records, and the process of aggregating the electronic medical records may be triggered.

In response to initiation of the process of aggregating electronic medical records associated with a patient, the electronic device 740 identifies at least a first electronic medical records storage system and a second electronic medical records storage system each storing electronic medical records associated with a patient (810). The second electronic medical records storage system is different from the first electronic medical records storage system. The electronic device 740 may identify the electronic medical records storage system by accessing data stored at the electronic device 740, or may identify the electronic medical records storage system by communicating with another electronic device and receiving electronic records profile information for a patient. The first electronic medical records storage system and the second electronic medical records storage system may be unrelated and unaware of each other.

The electronic device 740 identifies first patient authentication information that enables retrieval of an electronic medical record associated with the patient from a first electronic medical record storage system (815). The electronic device 740 may identify first patient authentication information that enables retrieval of an electronic medical record associated with the patient from a first electronic medical record storage system by accessing data stored at the electronic device 740 or by communicating with another electronic device and receiving the first patient authentication information. The electronic device may identify a first patient identifier and a first password for a first electronic medical records storage system. The combination of the first patient identifier and the first password enables retrieval of an electronic medical record associated with the patient from the first electronic medical record storage system. The electronic device 740 may also identify a machine token for the first electronic medical records storage system.

The electronic device 740 identifies second patient authentication information that enables retrieval of an electronic medical record associated with the patient from a second electronic medical record storage system (820). The second patient authentication information is different from the first patient authentication information. The electronic device 740 may identify second patient authentication information that enables retrieval of an electronic medical record associated with the patient from a second electronic medical record storage system by accessing data stored at the electronic device 740 or by communicating with another electronic device and receiving the second patient authentication information. The electronic device 740 may identify a second patient identifier and a second password for a second electronic medical records storage system. The combination of the second patient identifier and the second password enables retrieval of the electronic medical record associated with the patient from the second electronic medical record storage system. The first patient identifier for the first electronic medical records storage system may be different from the second patient identifier for the second electronic medical records storage system, and the first password for the first electronic medical records storage system may be different from the second password for the second electronic medical records storage system. The electronic device 740 may identify a machine token for the second electronic medical records storage system (which may be a second machine token different from the first machine token for the first electronic medical records storage system).

The electronic device 740 generates a first request for a medical record using the first patient authentication information and a second request for a medical record using the second patient authentication information (825). The electronic device 740 may generate the first and second requests by including the first and second authentication information in electronic communications to be sent to the first and second electronic medical records storage systems, respectively. The electronic device 740 may generate the first and second requests using different protocols, formats, and/or encryption techniques appropriate for the first and second electronic medical records storage systems, respectively. The electronic device 740 may store information required to generate the request in the information and format required by the electronic medical records storage system. In some examples, the electronic device 740 generates a first request including a first patient identifier and a first password, and generates a second request including a second patient identifier and a second password. In other examples, the electronic device 740 generates a first request including a machine token for a first electronic medical records storage system and generates a second request including a patient identifier and a password for a second electronic medical records storage system. The first and second requests may include any combination of authentication information, such as a machine token, a password, an identifier, encryption techniques, encoding, and the like.

The electronic device 740 transmits the first request to the first electronic medical records storage system and transmits the second request to the second electronic medical records storage system (830). For example, the electronic device 740 sends the first and second requests as electronic communications over a network to the first and second electronic medical records storage systems. The first and second requests may be transmitted simultaneously or not.

The electronic device 740 receives a first response from the first electronic medical records storage system, wherein the first response includes at least a first portion of one or more electronic medical records of the patient stored at the first electronic medical records storage system (835). The first response is sent from the first electronic medical records storage system in response to the first request being received by the first electronic medical records storage system and authenticated based on the first patient authentication information.

The electronic device 740 receives a second response from the second electronic medical records storage system, wherein the second response includes at least a second portion of the one or more electronic medical records for the patient stored at the second electronic medical records storage system (840). The second response is sent from the second electronic medical records storage system in response to the second electronic medical records storage system receiving the second request and authenticating the second request based on the second patient authentication information. The first and second responses may or may not include identification information associated with the patient or information identifying any other electronic medical records storage system. Limiting the information in the first and second responses to the particular electronic medical records storage system that sent the response may improve anonymity and privacy in the electronic medical records because an infringement of a single storage system or response does not result in information that enables an infringement of the entire set of electronic medical records.

The electronic device 740 generates a set of electronic medical records associated with the patient by combining a first portion of the one or more electronic medical records for the patient included in the first response with a second portion of the one or more electronic medical records for the patient included in the second response (845). In some embodiments, the electronic device 740 receives a first response and receives a second response, wherein the first response includes a first portion of a first electronic medical record of a patient stored at a first electronic medical records storage system and the second response includes a second portion of the first electronic medical record of the patient stored at a second electronic medical records storage system. In these embodiments, the electronic device 740 combines the first portion of the first electronic medical record with the second portion of the first electronic medical record to generate a complete first electronic medical record. Once the electronic device 740 has generated a complete electronic medical record from the received partial records (or received a complete electronic medical record), the electronic device 740 combines the complete record into a set of electronic medical records for the patient. The electronic device 740 may organize the electronic medical records in the group by date, by category, or by another sorting technique. The electronic device 740 may also filter the electronic medical records based on user-defined filtering criteria before combining the electronic medical records into the group. In some examples, the electronic device 740 may detect inconsistencies or redundancies in the aggregated electronic medical records. In these examples, the electronic device 740 may automatically resolve/correct the inconsistency and/or redundancy, or may mark the inconsistency and/or redundancy to alert a person viewing the electronic medical record.

The electronic device 740 enables display of the generated set of electronic medical records associated with the patient (850). The electronic device 740 may display the virtual collection of electronic medical records as a single file. The electronic device 740 may also perform statistical processing or grouping on the received electronic medical records prior to displaying the electronic medical record information. The electronic device 740 may also transmit the electronic medical record information to another device, and the other device may display the electronic medical record information. It may be beneficial to transmit electronic medical record information to another device for display when the other device has a larger or more suitable display for viewing the electronic medical record and/or any images (e.g., x-rays) associated with the electronic medical record.

In some embodiments, in response to initiation of the process of aggregating electronic medical records associated with a patient, the following actions occur automatically without human intervention: identifying at least a first electronic medical records storage system and a second electronic medical records storage system, identifying first patient authentication information, identifying second patient authentication information, generating a first request, generating a second request, transmitting the first request, transmitting the second request, receiving a first response, receiving a second response, generating a set of electronic medical records, and enabling display of the generated set of electronic medical records. Moreover, neither the first request nor the first response may include information identifying the second electronic medical records storage system, such that interception of the first request and the first response does not result in identification of the electronic medical records stored in the second electronic medical records storage system. Further, neither the second request nor the second response may include information identifying the first electronic medical records storage system.

Referring to fig. 9, an emergency services provider 920 may be provided access to medical records associated with a patient 910 being treated by the emergency services provider 920. The emergency services provider 920 uses the patient electronic device 930 belonging to the patient 910 to aggregate electronic medical records associated with the patient 910 and display the aggregated electronic medical records. The patient electronic device 930 includes an input unit 935 (e.g., keypad, etc.) that enables a user to provide user input to the patient electronic device 930, and a display 940 that displays electronic medical record information. The patient electronic device 930 includes a processor configured to control the operation of the patient electronic device 930 and includes at least one computer-readable storage medium for storing instructions executed by the processor 930 in performing the described processing and for storing information used by the patient electronic device 930 in acting as a secure agent or channel for accessing the parsed electronic medical record information (e.g., identification information for the electronic medical record storage systems, identification/authentication information for each electronic medical record storage system, etc.). The patient electronic device 930 may be similar to the user electronic device 130 described above with reference to FIG. 1 and the electronic device 740 described above with reference to FIG. 7.

The patient electronic device 930 may be configured to aggregate electronic medical records of the patient 910 using techniques similar to those described above. The patient electronic device 930 may also be configured to authenticate an emergency service provider (e.g., emergency service provider 920) and aggregate electronic medical records associated with the patient 910 for display to the emergency service provider 920. In response to authenticating the emergency service provider, the patient electronic device 930 may aggregate the electronic medical records as if the patient 910 had made an aggregation request.

Upon authenticating the emergency service provider 920, the patient electronic device 930 may request the emergency service provider 920 to enter a password or passcode. For example, the patient electronic device 930 may display an input control 945 on the display 940, and the emergency service provider 920 may use the input control 945 to enter a password or passcode. The patient electronic device 930 may compare the entered password to the valid password and determine whether to authenticate the emergency service provider 920 based on whether the comparison indicates that the entered password matches the valid password.

In some embodiments, the valid password may be a single valid password known to all emergency service providers. The valid password may also be provider specific, such that each licensed emergency service provider has a unique password for authentication. The patient electronic device 930 may require the emergency service provider 920 to enter identification information (e.g., employee ID, certificate number, name, etc.) prior to authentication. Requiring entry of identification information may enable tracking of emergency service provider access to electronic medical records of other patients. The tracking system may track access of the electronic medical records by emergency service providers in order to identify emergency service providers that are improperly accessing the electronic medical records or to identify when emergency service provider access credentials have been included (e.g., a particular emergency service provider is making an excessive number of medical record access requests, or is requesting electronic medical records for patients that the emergency service provider is not treating).

The patient electronic device 930 may store the emergency service provider authentication information and perform emergency service provider authentication based on the stored emergency service provider authentication information. In some examples, the patient electronic device 930 may communicate with an authentication electronic device of a centralized emergency service provider to perform authentication. The patient electronic device 930 may receive authentication information (e.g., a valid password (or passwords)) from the centralized emergency service provider's authentication electronic device and perform emergency service provider authentication based on the received emergency service provider authentication information. The patient electronic device 930 may also provide authentication information input by the emergency service provider 920 to a centralized emergency service provider authentication electronic device, which may authenticate the input authentication information, and which may report the authentication results to the patient electronic device 930. The certified electronic device of the centralized emergency services provider may track emergency services provider accesses to electronic medical records, generate reports, and send alerts when suspicious electronic medical record accesses occur.

Valid authentication information (e.g., a valid password) may change over time (e.g., a new password may be issued each day). For example, each emergency service provider may receive a new password every weekday for that emergency service provider. The new password may be received using a secure electronic communication mechanism or may be posted in an area that is expected to be accessible only by authorized emergency service providers (e.g., a backroom of a police department). The patient electronic device 930 may periodically receive updated authentication information (e.g., a password, token, etc.) for the licensed/authorized emergency service provider, or may request and receive authentication information (e.g., a password, token, etc.) for a particular emergency service provider in response to the particular emergency service provider requesting an electronic medical record using another user's device. Changing the authentication information (e.g., a valid password) may reduce the risks associated with potential infringement of emergency service provider authentication information and limit improper access to electronic medical records.

The emergency service provider 920 may also need to perform hardware authentication to access electronic medical records associated with the patient 910 using the patient electronic device 930. Hardware authentication may be in addition to or in place of the password-based authentication described above. Hardware authentication may require that the emergency service provider 920 physically possess a particular hardware device in order to be authenticated as a licensed emergency service provider. For example, the particular hardware device may be a hardware key or dongle that an emergency service provider physically connects to the patient electronic device for authentication.

In some embodiments, a hardware device for hardware authentication may be electronically connected to the patient electronic device 930 via a wireless connection. For example, as shown in fig. 9, the hardware device may be a wireless communication device 950 with which the emergency service provider 920 performs hardware authentication operations. In this example, the wireless communication device 950 can exchange a predetermined series of communications with the patient electronic device 930, while the patient electronic device 930 authenticates the emergency service provider based on the exchanged communications (e.g., based only on the exchanged communications or by communicating with another centralized authentication device). The communications exchanged by the wireless communication device 950 required for authentication may vary over time as with the password authentication discussed above. The usage of the wireless communication device 950 (or another hardware authentication device) may also be tracked as discussed above. The particular hardware device may be issued only to licensed emergency service providers and may be controlled by the emergency services authority to enable the emergency services authority.

In response to authenticating the emergency service provider 920, the patient electronic device 930 aggregates the electronic medical records associated with the patient 910 and displays the aggregated electronic medical records. The process of aggregating and displaying electronic medical records associated with patient 910 may be performed using techniques similar to those discussed above with respect to fig. 7.

In some embodiments, the emergency services provider 920 may not be given access to all of the electronic medical records of the patient 910. In these embodiments, the access given to the emergency service provider 920 may include electronic medical records that are beneficial for providing emergency treatment and exclude electronic medical records that are not relevant or less important to emergency treatment. Thus, the emergency services provider 920 may receive fewer electronic medical records than the patient 910 may receive (e.g., as shown by the difference between the electronic medical records shown in fig. 7 and the electronic medical records shown in fig. 9). The patient 910 may define the level of access provided to the emergency service provider 920, as well as the type of medical record (or records) provided to the emergency service provider 920.

In further embodiments, emergency service providers with different credentials may be provided different levels of access. For example, an ambulance driver may obtain fewer records than an emergency room doctor treating patient 910, and an emergency room doctor may obtain fewer records than a surgeon performing an emergency procedure on patient 910. The level of access (e.g., number and type of records) may be adapted to the type of service provided by the emergency service provider. The access level may be defined based on the preferences of the patient, may be automatically defined based on authentication information received from the emergency service provider, or may be defined based on which records are requested by the emergency service provider.

In some examples, additional information may be provided to the emergency service provider 920 that is not provided when the patient 910 requests an electronic medical record. In these examples, the additional information may include emergency contact information and natural death claim (living will) information (e.g., patient preferences regarding whether the patient wishes to resuscitate). The format of the information provided to the emergency service provider 920 may also be different than that provided to the patient 910. For example, the patient electronic device 930 may display information that may pose a risk to the emergency service provider 920 in a different section or in a highlighted manner (e.g., highlighting HIVPositive).

In some embodiments, the patient electronic device 930 may transmit the electronic medical records to a hospital or other emergency service provider in response to an initial emergency service provider authentication and record aggregation operation. In these embodiments, in response to the emergency services provider 920 being authenticated to the patient electronic device 930, the patient electronic device 930 may automatically transmit (or control another device to transmit) an electronic medical record to the hospital or doctor's office to which the patient 910 is being sent for further treatment. The electronic medical records sent to the hospital or doctor's office may include the same electronic medical records aggregated and displayed to the emergency service provider 920, or may include more or fewer electronic medical records. The hospital or doctor's office may be determined based on user input provided by the emergency service provider 920 to the patient electronic device 930, or may be automatically determined based on known information about the emergency service provider 920 (e.g., the hospital at which the emergency service provider 920 is working) or known information about the patient 910 (e.g., the family doctor used by the patient 910). Providing an electronic medical record to a hospital or doctor's office before the arrival of the patient 910 may improve emergency treatment because an emergency services provider at the hospital or doctor's office may have some time to view the medical record before the arrival of the patient 910.

Input from the patient 910 may also be required to authenticate the emergency service provider 920. For example, biometric input (e.g., a fingerprint scan or a retinal scan) of patient 910 may be required to authenticate emergency service provider 920. The biometric input may confirm that the patient 910 is near the emergency service provider 920 attempting to access the electronic medical record, and the biometric input is also the type of input that the patient 910 may provide if the patient is unconscious or incapacitated while being treated by the emergency service provider 920.

Fig. 10 is a flow diagram of a process 1000 for enabling an emergency service provider to access a patient's medical records. For convenience, process 1000 is performed with reference to specific components described with reference to fig. 9. However, a similar approach may be applied in other embodiments where different components are used to define the system structure or where functionality is distributed differently among the components shown in FIG. 9.

The patient electronic device 930 receives a request from the emergency service provider 920 of a treatment patient 910 to access a medical record associated with the patient 910 (1010), wherein the patient electronic device 930 belongs to the patient 910. The patient electronic device 930 may receive a request to access the medical records associated with the patient 910 based on user input provided by the emergency service provider 920 to the patient electronic device 930, or the patient electronic device 930 may receive a request to access the medical records associated with the patient 910 in an electronic communication sent from the wireless communication device 950.

In response to receiving the request from the emergency service provider 920, the patient electronic device 930 performs an authentication process on the emergency service provider 920 to determine a condition of the emergency service provider 920 based on authentication information provided to the electronic device by the emergency service provider 920 (1020). For example, the patient electronic device may perform a two-stage authentication process, wherein a first stage of entry of a valid password is required and a second stage of hardware authentication process is performed using a hardware device issued by the emergency services agency. The authentication process may include receiving input from a hardware device, and determining a condition of an emergency service provider based on the received input from the hardware device, wherein the hardware device is issued by an emergency services agency to the emergency service provider to enable authentication of the emergency service provider with an electronic device of a patient, wherein the electronic device of the patient is configured to aggregate electronic medical records associated with the patient. The authentication process may also include receiving input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider and determining a status of the emergency service provider based on the user identifier and the password.

In some embodiments, the patient electronic device may determine whether the emergency service provider is licensed or may determine a credential level of the emergency service provider 920. The level of certification may be at least one of ambulance personnel, emergency room physicians, and surgeons performing emergency surgery.

In some examples, the authentication process may be performed without receiving input from the patient. In other examples, authentication of the emergency service provider may be conditioned on receiving biometric input from the patient indicating that the patient is physically near the patient's electronic device. The biometric input may be a fingerprint scan or a retinal scan that can be provided even when the patient is unconscious.

The patient electronic device 930 accesses from the electronic storage the patient's 910 preferences for emergency services providers to access the patient's medical records (1030). The patient electronic device 930 may access the profile information from an electronic memory of the patient electronic device 930, or may access the profile information from an electronic memory of a device remote from the patient electronic device 930 over a network. The profile information may indicate the patient's preference for providing electronic medical records to emergency service providers.

The patient electronic device 930 determines a level of access to medical records associated with the patient 910 to provide to the emergency service provider 920 based on the determined status of the emergency service provider 920 and the accessed patient preferences (1040). The patient electronic device 930 may determine an access level from at least three access levels. The three levels of access may include a full level of access that enables full access to all medical records of the patient, an unauthorized level of access that does not enable access to any medical records of the patient, and an intermediate level of access that enables access between the full and unauthorized levels of access. In one example, the patient electronic device 930 may determine to provide access to at least some of the medical records associated with the patient in response to determining that the emergency service provider is permitted, and may determine not to provide any access to the medical records associated with the patient in response to determining that the emergency service provider is not permitted. In another example, the patient electronic device 930 may determine to provide a first level of access to the emergency service provider 920 in response to determining that the emergency service provider 920 is an ambulance person, the patient electronic device 930 may provide a second level of access to the emergency service provider 920 in response to determining that the emergency service provider 920 is an emergency room physician, and the patient electronic device 930 may determine to provide a third level of access to the emergency service provider in response to determining that the emergency service provider is a surgeon performing an emergency procedure. The third level of access may be different from the first level of access and the second level of access.

The patient electronic device 930 aggregates electronic medical records associated with the patient 910 based on the determined level of access to be provided to the emergency service provider 920 (1050). The patient electronic device 930 aggregates the electronic medical records associated with the patient 910 using the techniques described above. The type and scope of the aggregated electronic medical records may be controlled by the determined level of access provided to the emergency service provider 920. The patient electronic device 930 may automatically aggregate the electronic medical records without further input from the emergency service provider 920.

The patient electronic device 930 enables display of the aggregated electronic medical records associated with the patient 910 to the emergency service provider 920 (1060). The patient electronic device 930 may display the virtual collection of electronic medical records as a single file. The electronic device 930 may also perform statistical processing or grouping on the received electronic medical records prior to displaying the electronic medical record information. The electronic device 930 may also transmit the electronic medical record information to another device, and the other device may display the electronic medical record information. It may be beneficial to transmit electronic medical record information to another device for display when the other device has a larger or more suitable display for viewing the electronic medical record and/or any images (e.g., x-rays) associated with the electronic medical record.

The described systems, methods, and techniques may be implemented in digital electronic circuitry, computer hardware, firmware, software, or in combinations of these elements. Apparatus embodying these techniques may include appropriate input and output apparatus, a computer processor, and a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor. Processes embodying these techniques may be performed by a programmable processor executing a program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high level procedural or object oriented programming language, or if desired, an assembly or machine language, and in either case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and compact disk read-only memory (CD-ROM). Any of the above may be supplemented by, or incorporated in, specially designed ASICs (application-specific integrated circuits).

In one embodiment, a proxy application is sent to the mobile device using a mobile device message (e.g., a specially configured MMS ("multimedia messaging service") or SMS ("short message service") message) configured to launch the application. For example, an MMS message may be sent to the mobile device. The MMS message may include a URL ("uniform resource locator") that points to an installed application. The user may retrieve the URL to install the proxy application. The URL may include a link to a BREW ("binary runtime over Wireless") or J2ME ("Java 2 Micro Edition") program configured to be installed as a proxy application.

The user may contact their insurance provider, medical records provider, or healthcare provider (health care provider) in order to receive the program. Thus, the user can enter their address information (e.g., telephone number or email address) at the network site (or through the transit center). The insurance provider may then provide a link to the installer in response. The user selects the link to install the proxy application onto the wireless telephone and then inputs user information (e.g., authentication and identification information) using the proxy application. Once authenticated, the record storage system may provide address information for the record for the user. The record storage system may transmit the secure URL to the proxy application. The proxy application may then be configured to store these URLs and access the records through these URLs.

When a user interacts with different record storage systems, the user may transmit identification information for each different record storage provider so that the broker application may be configured to add address information for each record storage provider. For example, a user accessing a medical testing center may provide a wireless telephone number to access the testing results. The medical testing center may then send a message to register the user's mobile device in the network of devices that are allowed to access the records securely published by the medical testing center. Once the user has successfully completed the validation process, the detected address information for the user may be added to the list of URLs managed by the proxy application. In one configuration, the agent application is configured to store address information for insurance and claims processing, attending physicians and specialists, and pharmacy services. By configuring the broker application on the mobile device to store address information for securely published medical records, users can use their mobile devices to selectively distribute records to interested parties, such as healthcare providers.

To illustrate, a user accessing his doctor may register with the "front desk" of the doctor. The foreground may include a bluetooth (TM) transceiver configured to prompt the agent application for the user's medical records, test results, and insurance information. The user receives a message from the agent application indicating that the doctor's foreground is requesting access to the medical records, test results, and insurance information. The user may then "accept" the prompt to command the agent application to access the requested record. The broker application then accesses the URL to obtain each requested record from each record storage provider. The proxy application may then provide authentication information or rely on previously provided authentication information. The record storage provider may provide a PDF (portable document format) file with the requested information.

The mobile device receives the requested recording and transmits the recording to the doctor's foreground. The front desk system can then distribute the records to the necessary doctors, nurses, and claims processing personnel. The user may then receive medical services. Depending on the communication protocol used, the mobile device may remain in communication with the foreground system (using, for example, Wi-Fi wireless local area network technology) or disconnect from the foreground system (using, for example, bluetooth (TM) technology).

As a result of the user receiving service and the doctor updating medical records, requesting tests and prescribing, the healthcare provider may wish to update the user's records. The agent application may then receive a communication from the foreground system (or other system of the doctor's office) and request transmission of that information to the corresponding record storage provider. The user may then confirm the prompt to allow the mobile device to receive updated medical records, test requests, and prescriptions. The broker application on the mobile device may then retrieve the address information for each record and transmit the updated information to each medical storage provider. Alternatively, the foreground system may then transmit each update to an email address associated with the user, where the updated information is processed and sent to each respective healthcare provider. Such a configuration may be employed where access to the information is deemed particularly sensitive and updates to the information are deemed less important because the update system is already able to access the updated information.

In one embodiment, specialized units and systems, such as emergency room and ambulance personnel and systems, may have privileges to access the record storage provider. For example, if a patient cannot access or interface with a mobile device to provide medical records, perhaps because the patient is unconscious or incapacitated, the mobile device may be configured to enable trusted personnel and systems to access the required records. In one configuration, the mobile device requires personnel to enter trusted access information for the emergency room. Alternatively or additionally, the mobile device may be configured to read MAC ("media access control") address information from the local wireless system. The mobile device may then be configured to read the MAC address from the emergency room system and transmit the MAC address of the emergency room system to a confirmation system (e.g., a security program operated by the record storage provider). The validation system may then determine whether the MAC address is in the MAC address list of the trusted emergency room system. The mobile device may be configured to automatically confirm the MAC address without intervention to reduce the burden on emergency room personnel. In yet another configuration, MAC address filtering is used in addition to requiring emergency room personnel to type in a PIN ("personal identification Number") for the particular emergency room where the patient is being attended.

In one configuration, in response to determining that emergency service personnel are accessing medical records, the storage record provider may be configured to send a DNR ("Do Not Resuscitate") message to the emergency service personnel. For example, the mobile device may be configured to generate an eye-catching display and/or to require confirmation of the DNR condition of the patient. The record storage provider may also be configured to send voice and email messages to contact emergency service personnel for DNR status information.

Pharmacies may also be registered in a registered pharmacy list that allows access to patient medication records. For example, a pharmacy may use a dedicated printer with a short-range wireless transmitter configured to automatically interrogate the agent application on the mobile device. In response to entering the pharmacy, the dedicated printer may automatically query the agent application for prescription information. The proxy application may communicate with the pharmacy records provider to determine whether the specialized printer is associated with a trusted pharmacy. As a result of identifying the dedicated printer as being associated with a trusted pharmacy, the dedicated printer accesses an electronic record with unfilled and/or refilled prescriptions and prints out the prescriptions. The pharmacist may then execute the prescription.

It will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, advantageous results still could be achieved if steps of the disclosed techniques were performed in a different order, and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. Other embodiments are within the scope of this description.

Claims (10)

1. A method of enabling an emergency service provider to access a patient's medical records, comprising:

receiving, at a patient's electronic device, a request to access a medical record associated with the patient from an emergency services provider that treats the patient;

in response to receiving the request from the emergency service provider, performing an authentication process on the emergency service provider to determine a status of the emergency service provider based on authentication information provided by the emergency service provider to the electronic device;

accessing from electronic storage preferences of the patient regarding access by emergency service providers to medical records of the patient;

determining a level of access to the medical records associated with the patient to provide to the emergency service provider based on the determined status of the emergency service provider and the accessed preferences of the patient;

aggregating, at the electronic device of the patient, electronic medical records associated with the patient based on the determined level of access to be provided to the emergency service provider; and

enabling display of the aggregated electronic medical records associated with the patient to the emergency service provider.

2. The method of claim 1, wherein performing an authentication process on the emergency service provider to determine the status of the emergency service provider comprises:

receiving an input from a hardware device issued by an emergency services agency to the emergency services provider to enable authentication of the emergency services provider with the electronic device of the patient, wherein the electronic device of the patient is configured to aggregate electronic medical records associated with the patient; and

determining a status of the emergency service provider based on the received input from the hardware device.

3. The method of claim 1, wherein performing an authentication process on the emergency service provider to determine the status of the emergency service provider comprises:

receiving input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider; and

determining a status of the emergency service provider based on the user identifier and the password.

4. The method of claim 1, wherein performing an authentication process on the emergency service provider to determine the status of the emergency service provider comprises:

receiving input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider;

receiving an input from a hardware device issued by an emergency services agency to the emergency services provider to enable authentication of the emergency services provider with the electronic device of the patient, wherein the electronic device of the patient is configured to aggregate electronic medical records associated with the patient; and

determining a status of the emergency service provider based on the user identifier and the password and the received input from the hardware device.

5. The method of claim 1, wherein:

the step of performing an authentication process on the emergency service provider to determine a status of the emergency service provider comprises: determining whether the emergency service provider is licensed; and is

Based on the determined condition of the emergency service provider, determining a level of access to the medical record associated with the patient to provide to the emergency service provider comprises:

in response to determining that the emergency service provider is licensed, determining to provide access to at least a portion of the medical record associated with the patient, and

determining not to provide any access to the medical record associated with the patient in response to determining that the emergency service provider is not licensed.

6. The method of claim 1, wherein:

the step of performing an authentication process on the emergency service provider to determine a status of the emergency service provider comprises:

determining whether the emergency service provider is at least one of an ambulance personnel, an emergency room doctor, and a surgeon performing an emergency procedure; and

based on the determined condition of the emergency service provider, determining a level of access to the medical record associated with the patient to provide to the emergency service provider comprises:

determining to provide a first level of access to the emergency service provider in response to determining that the emergency service provider is an ambulance person,

in response to determining that the emergency service provider is an emergency room doctor, determining to provide a second level of access to the emergency service provider, the second level of access being different than the first level of access, an

In response to determining that the emergency service provider is a surgeon performing an emergency procedure, determining to provide a third level of access to the emergency service provider, the third level of access being different from the first level of access and the second level of access.

7. The method of claim 1, wherein determining a level of access to the medical records associated with the patient to provide to the emergency service provider based on the determined status of the emergency service provider and the accessed preferences of the patient comprises:

the access level is determined from at least three access levels, wherein the three access levels include at least a full access level, an unauthorized access level, and an intermediate access level between the full access level and the unauthorized access level.

8. The method of claim 1, wherein aggregating, at the electronic device of the patient, electronic medical records associated with the patient based on the determined level of access to be provided to the emergency service provider comprises:

automatically aggregating electronic medical records without further input from the emergency service provider.

9. The method of claim 1, wherein performing an authentication process on the emergency service provider comprises: the authentication process is performed without receiving input from the patient.

10. The method of claim 1, wherein performing an authentication process on the emergency service provider comprises: receiving a biometric input from the patient indicating that the patient is physically near the electronic device of the patient as a condition for authenticating the emergency service provider.