CN107004048B - Record access and management - Google Patents

Abstract

An electronic device for aggregating electronic medical records, wherein the electronic medical records are aggregated from multiple electronic repositories and displayed as a single collection of records. The multiple electronic repositories may use different identification/access information to store patient-specific records to facilitate anonymous access to electronic medical records. The emergency medical service provider can use the electronic device to access the patient's medical records after being certified as a valid/licensed medical service provider.

Description

Record access and management

Cross reference to related applications

Priority of U.S. non-provisional patent application serial No.14/523,110, filed 2014 10, 24 and entitled "record ACCESS AND MANAGEMENT", in accordance with 35USC § 119(e), this us non-provisional patent application is a partial continuation of us application No.14/083,691 filed on 19.11.2013 and entitled "record ACCESS AND MANAGEMENT", this U.S. application No.14/083,691 is a continuation of U.S. application No.12/167,746, now entitled record ACCESS AND MANAGEMENT, filed on 3.7.2008, this U.S. application No.12/167,746 claims priority to U.S. provisional application No.60/947,809, filed on 3/7/2007 and entitled "record ds ACCESS AND MANAGEMENT" and also claims priority to U.S. provisional application No.60/974,997, filed on 25/9/2007 and entitled "record ds ACCESS AND MANAGEMENT". The contents of these applications 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 a paper or electronic format. When medical records need to be transmitted or collected from multiple medical service providers, the transmission and collection can be difficult and time consuming.

Disclosure of Invention

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

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

At the electronic device, one or more electronic medical records included in the first request are received from the first communication device, the one or more electronic medical records included in the first request being transmitted 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.

At the electronic device, the one or more electronic medical records included in the second request are received 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.

Display of information related to 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 is enabled.

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

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

One or more electronic medical records associated with the patient may be accessed from a local storage associated with the electronic device. Enabling display of information related to the one or more electronic medical records to a medical services provider that provides services to the patient may include enabling display of the one or more electronic medical records accessed from the local storage.

The filter criteria associated with the service provided to the patient by the medical service provider may be accessed and transmitting from the electronic device to the first communication device may include transmitting the filter criteria. Sending the second request from the electronic device to a second communication device different from the first communication device may include sending filtering criteria. Receiving, at the electronic device, the one or more electronic medical records from the first communication device may include receiving the one or more electronic medical records that satisfy the filtering criteria. Receiving, at the electronic device, the one or more electronic medical records from the second communication device may include receiving the one or more electronic medical records that satisfy the filtering criteria.

Enabling display of information related to 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 servicing the patient may include rendering a display of information related to 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 to enable the medical services provider to perceive (successful) the electronic medical records.

The electronic device associated with the patient may include a first electronic device, and enabling display of information related to 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 include 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 sense, techniques and systems for accessing medical records are described. A process of aggregating electronic medical records associated with a patient is initiated, the process being initiated in response to the patient providing user input to an electronic device associated with the patient. In response to initiation of a 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.

First patient authentication information enabling retrieval of an electronic medical record associated with a patient from a first electronic medical record storage system is identified. Second patient authentication information enabling retrieval of an electronic medical record associated with the patient from a second electronic medical record storage system is identified. 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 and a second request for the medical record is generated using the second patient authentication information. A first request is sent from the electronic device to a first electronic medical records storage system.

A second request is sent from the electronic device to a second electronic medical records storage system. The method further includes 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 the one or more electronic medical records for 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 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, 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, receiving the first response may include receiving the first response including a first portion of the first electronic medical record for the patient stored at the first electronic medical records storage system, and receiving the second response may include receiving the second response including a second portion of the first electronic medical record for the patient stored at the second electronic medical records storage system. Generating the set of electronic medical records may include combining a first portion of the first electronic medical record with a 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 an interception (intervention) 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.

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, sending the first request, sending 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 may occur automatically, without human intervention, in response to initiation of a process of aggregating electronic medical records associated with a patient.

Identifying the first patient authentication information may include identifying a machine token that enables retrieval of an electronic medical record associated with the patient from the first electronic medical record storage system. Identifying the second patient authentication information may include identifying a password that enables retrieval of an electronic medical record associated with the patient from the second electronic medical records storage system, and generating the first request for the medical record using the first patient authentication information may include generating the first request including the machine token. Generating the second request for the medical record using the second patient authentication information may include generating the second request including the password.

Identifying the 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. Identifying the 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 the electronic medical record associated with the patient from the second electronic medical record 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 the medical record using the first patient authentication information may include generating the first request including a first patient identifier and a first password. Generating the second request for the medical record using the second patient authentication information may include generating a second request including a second patient identifier and a second password.

In yet another general sense, access to a medical record of a patient is enabled by receiving, at an electronic device of the patient and from an emergency services provider that treats the patient, a request to access the medical record associated with the patient. In response to receiving a request from an emergency service provider, performing an authentication process for the emergency service provider based on authentication information provided to the electronic device by the emergency service provider to determine a condition of the emergency service provider;

patient preferences regarding emergency service providers accessing medical records of patients are accessed from an electronic storage device. Based on the determined status of the emergency service provider and the accessed patient preferences, a level of access to medical records associated with the patient to be provided to the emergency service provider is determined.

Based on the determined level of access to be provided to the emergency service provider, electronic medical records associated with the patient are aggregated at the patient's electronic device. Displaying the aggregated electronic medical records associated with the patient to the emergency service provider is accomplished.

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

Performing an authentication process with the emergency service provider to determine a status of the emergency service provider may include receiving an input from the emergency service provider indicating a user identifier and a password associated with the emergency service provider, and determining the status of the emergency service provider based on the user identifier and the password.

Performing an authentication process on the emergency service provider to determine a status of the emergency service provider may include receiving input from the emergency service provider indicative of a user identifier and a password associated with the emergency service provider, receiving input from a hardware device issued by the emergency services authority to the emergency service provider to enable authentication of the emergency service provider to an electronic device of the patient configured to aggregate electronic medical records associated with the patient, and determining the status of the emergency service provider based on both the user identifier and the password and the input received from the hardware device.

Performing an authentication process with the emergency service provider to determine a condition of the emergency service provider may include determining whether the emergency service provider is permitted, and determining a level of access to medical records associated with the patient to be provided to the emergency service provider based on the determined condition of the emergency service provider may include determining 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 determining 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.

Performing an authentication process with the emergency service provider to determine a condition of the emergency service provider may include determining whether the emergency service provider is at least one of an ambulance person, an emergency room doctor, and a surgeon performing an emergency procedure, and determining a level of access to medical records associated with the patient to be provided to the emergency service provider based on the determined condition of the emergency service provider may include 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, determining to provide a second level of access to the emergency service provider in response to determining that the emergency service provider is an emergency room doctor, wherein the second level of access is different than the first level of access, and determining 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, wherein the third level of access is different from the first level of access and the second level of access.

Determining a level of access to 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 patient preferences may include determining the level of access from at least three levels of access including at least a full level of access, a no level of access, and an intermediate level of access between the full level of access and the no level of access.

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

Performing the authentication process with the emergency service provider may include performing the authentication process without receiving input from the patient.

Performing an authentication process with the emergency service provider may include adjusting authentication of the emergency service provider upon receiving biometric input from the patient indicating that the patient is physically proximate to the patient's electronic device.

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

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. 1A is a block diagram of an example system configured to perform record access and management.

FIG. 1B is a block diagram of another example 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 contextual diagram (contextual Diagram) showing anonymous medical record aggregation.

FIG. 8 is a flow chart of a process for anonymously aggregating medical records.

FIG. 9 is a contextual diagram illustrating an emergency service provider accessing medical records.

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

FIG. 11 illustrates an example system 1100 for a user to solicit bids for healthcare services.

FIG. 12 is a flow chart illustrating a process by which a user solicits bids for healthcare services.

Fig. 13 is another flow chart of a process for accessing electronic medical records for sharing with a Patient Safety Organization (PSO).

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 conduit that receives electronic medical records from a remote service provider so 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 (appointment) and the doctor does not have the necessary medical records for the user, the user can quickly access the electronic medical records needed by the doctor using the user's mobile device. In another example, if a user is involved in a car accident and an emergency service provider is providing treatment to the user, the user's mobile device may be used to access the user's electronic medical records that may assist 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 can have a complete review of the relevant medical records and have 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, thereby enabling the mobile device to render a display of information related to the received medical records. The user may then present the display to a medical service provider (e.g., a doctor) that provides care to the user for review of the medical records. The mobile device may be configured to transmit the received medical record to an electronic device of a medical service provider such that the mobile device acts as a secure conduit for the medical record. In this way, by using security on the mobile device, access to the medical records may be securely accessed by using the mobile device as a conduit. Further, the mobile device may be configured to request only a subset of the user's medical records that are relevant to the treatment provided by the physician. Because a subset of the medical records are distributed across multiple storage devices, a single point of failure (e.g., a security breach) at a particular segmented storage device does not compromise the entire record. Each fragment may also be referred to as a stub (stub), or a segment, or a portion. In addition, data segments that are considered more sensitive (or dirty) may be preserved with a higher level of security. To achieve security, each data segment may be encrypted with a different level of complexity. Further, the mobile device may be configured to enable the user and/or the medical services provider to add medical records for the user.

In some implementations, the electronic device can act as a distributable, remotely accessible, and secure electronic medical records broker, where the intended broker aggregates the separately stored pieces of the user medical records from storage using identifiers associated with the resolved identities of the pieces. Thus, the recorded portions may be stored separately in a plurality of locations. To prevent alteration/tampering, an integrity check mechanism may be implemented for each part to enforce non-repudiation (non-repudiation). In particular, each portion may be stored in a separate network location and have a corresponding error check code. For example, each portion may include a hash code generated from the payload data of that portion. For example, MD5 hashes may be generated for each portion to prevent alteration therein. A watermark may also be generated for each portion for the same purpose. Each portion may not contain information identifying the user who owns the data. Each portion may include a unique identifier that does not identify the user, but may link the stored portions together. The recipient of the viewing/access agent perceives a single file. However, the perceived file is a virtual assembly of the stored user identity with more than one stored component of the complete medical record using the public key. This allows for the aggregation of data from all over the world. That is, the recipient gets a file that looks simple. However, the recipient (e.g., user/patient) may have control over what the file includes, and only the recipient knows the source from which to assemble the file. In addition, the recipient can ensure privacy because the recipient's name (or other identifying information) is broken down from the file, and even in the case of a leak (break), the segmentation of the de-identified medical record can render the compromised data segment useless to intruders (or people who inadvertently obtain the data segment).

Notably, a chain of trust may be established. For example, the electronic medical record may be accompanied by a digital certificate. The digital certificate may include the public key of the submitter issued by a certificate authority (also referred to as a CA). In such instances, the electronic medical record may be encrypted by the submitter's private key such that the encrypted electronic medical record may only be decrypted by the submitter's public key. Such asymmetric encryption/decryption may keep the content of the electronic medical record authentic. Asymmetric encryption/decryption may also prevent tampering or alteration by other parties. In another example, the electronic medical record may include a digital watermark that uniquely identifies the submitter. In this particular example, the digital certificate may include, for example, a digital signature of the submitting party. The correlation between the digital signature in the digital certificate and the digital signature embedded in the electronic medical record may prevent other parties from altering and tampering with the electronic medical record during distributed storage of the electronic medical record.

In some examples, an emergency service provider (e.g., a 911 service provider, an emergency medical technician, etc.) may be provided with a key for a medical record that is accessed based on a code on a person associated with the medical record being read by a third party (e.g., a code on a bracelet or key fob), where the third party itself may be identified as an emergency responder. The code may also be supplied by an emergency service operator or other service provider that manages emergency access to the recipient's medical records. In this context (e.g., an emergency service provider may need to enter a code and have a specific device or hardware key available for accessing medical records only to the licensed emergency service provider), dual factor identification may be used to enable emergency access. Further, 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).

In the event that the principal (principal) is rendered unable to make a decision, the healthcare principal may allow the principal to assign healthcare decisions to the contracted agents. A caregiver to an elderly person may have a medical order for the elderly person. The caregiver can access the elderly's medical records without the elderly's approval. In particular, the caregiver can request information as needed to provide care to the elderly. The caregiver may not have access to information unrelated to the caregiver's provision of medical care. Further, the caregiver may interact with the social media channel on behalf of the elderly. Caregivers can report medical information of the elderly even during medical studies involving the elderly (e.g., clinical trials of drugs for treating alzheimer's disease). Likewise, a child guardian may have a similar medical attorney for children and may have similar access privileges to children's medical records. In these cases, a chain of trust may be established in accordance with the disclosure herein.

A user-configurable presence profile may be used to limit the information provided to the emergency service provider. The online profile may be used to adjust information based on the status of the emergency personnel (e.g., ambulance driver gets low level; trauma team (trauma) gets high level, etc.). In particular, the user may choose to disclose the medication to a regular doctor and to disclose more visits (e.g., full visits) to the trauma pack provider. The system may also be configured to disclose all information to different levels of multiple parties simultaneously (e.g., providing limited information to ambulance drivers and providing more in-depth access to local emergency room personnel to provide them time to prepare for incoming (inbound) patients).

Further, the user may configure persistence parameters for the user's medical record data collected from various storage locations. Depending on the context, the user may desire different durations for the aggregated medical care record. In the event that the healthcare professional may only need to temporarily view the aggregated medical record information (e.g., for confirmation purposes only), the aggregated medical record information may be available on the display of the user's mobile device for a limited period of time. In these cases, the rendered display information may not be printed to a printer or transmitted (beacon) to a device at the doctor's office. In the case where the aggregated medical care record is sent to a device at a physician's office, the aggregated medical record data may expire after a limited period of time, e.g., as the password used to encrypt the aggregated medical record expires. In other cases, when a user desires to revisit the same doctor's office for a follow-up visit, the user may desire a longer duration, including permanent storage.

Referring to FIG. 1A, 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 via connection 190.

The network 110 is configured to enable the exchange of electronic communications 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 line (xDSL)), radio, television, cable, satellite, and/or any other delivery or tunneling mechanism for carrying data. Network 110 may include multiple networks or sub-networks, each of which may include, for example, wired or wireless data pathways. The 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 implementations, the user 120 is a patient receiving medical treatment from a doctor. 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 treatment at or before the time of 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 the consumer electronic device 130 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 user electronic device 130 can be configured to access an electronic medical or health record of the user 120 and render a display of the medical or health record on a display associated with the user electronic device 130. In these embodiments, the user 120 may show the display to the medical service provider to enable the service provider to perceive the electronic medical record. In other embodiments, the user 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 via 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 storage or memory device configured to store electronic data. The storage or memory device may be configured to store data using, for example, magnetic, optical, and/or solid state technology. For example, the storage or memory device may include a hard disk, tape drive, compact disk, random access memory ("RAM"), and/or 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 three record storage systems are shown in FIG. 1, any number of record storage systems may be connected to network 110. In some implementations, 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.

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 access the electronic medical records of the user 120 using the recipient electronic device 180 to assist in treating the user 120. A healthcare provider may be referred to as a healthcare professional or healthcare provider.

The recipient electronic device 180 is an electronic device configured to communicate with other electronic devices to perform record access and management operations. Recipient electronic device 180 may be any type of electronic device configured to exchange communications over 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 can include an integrated display configured to display the recorded information and/or the recipient electronic device 180 can 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 render a display of 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 services provider (e.g., a doctor) in a treatment facility (e.g., a doctor's office or hospital).

The connection 190 is configured to enable the exchange of electronic communications between devices connected to the connection 190. For example, the connection 190 may be configured to enable an 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 path. For example, the connection 190 may be a bluetooth connection between the consumer electronic device 130 and the recipient electronic device 180. In one configuration, the connection may include a Radio Frequency (RF) link for the consumer electronic device 130 and the recipient electronic device 180 to transmit data to each other. In another configuration, the connection may include an Infrared (IR) link for the consumer electronic device 130 and the recipient electronic device 180 to exchange data. In another example, the connection 190 is a direct wired connection (e.g., a Universal Serial Bus (USB) connection, an IEEE 1394 (firewire) 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 via the direct wired connection. In yet another example, the connection may include a scanning mechanism by which the recipient electronic device 180 may scan symbols on a display of the consumer electronic device 130. The symbol may include a barcode, a QR code, or even textual information. The scanning mechanism may include a scanner having a light source and a light sensor. The light source may comprise, for example, a photodiode (such as an LED) for efficient operation. The light source may operate in the visible or Infrared (IR) spectrum. The light source may cause the symbol to be illuminated. In some embodiments, the illumination may be modulated to provide security. The light sensor may then receive a light signal caused by the illuminated symbol. The light sensor may comprise, for example, an IR sensor, a Charge Coupled Device (CCD), or an optical camera. 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 some embodiments, connection 190 facilitates the secure exchange of electronic medical records to maintain the integrity and privacy of electronic medical records exchanged via connection 190. For example, the connection 190 may be a direct wired connection only between the consumer electronic device 130 and the recipient electronic device 180 as described above. In other examples, connection 190 facilitates a Virtual Private Network (VPN) connection or another type of authenticated and/or encrypted connection sufficient to reasonably protect data exchanged via connection 190.

FIG. 1B illustrates another exemplary system 100 configured to perform record access and management. In particular, the electronic device 130 may act as a user device and a server from which the patient processes electronic medical records. As disclosed herein, some embodiments may include multiple instances of the electronic device 130 to process and interact with electronic medical records storage systems 140, 150, and 160. In one example, the electronic device 130 may include an electronic device 130B carried by the patient and an ancillary data server 130A on which the service provider may store, for example, an address of the patient's electronic medical record. In this context, a service provider may provide services such as on-demand access to distributed electronic medical records. Thus, secondary data server 130A may act as a backup server for, for example, electronic device 130B by maintaining a copy of the address information. The copy of the address information may be periodically synchronized with the copy on the electronic device 130B. Synchronization may also occur at each update of the copy on the electronic device 130B. In the event that electronic device 130B loses a copy thereon, for example, due to a storage failure or operator error, the backup copy on secondary data server 130A may be relied upon by electronic device 130B. Communication between electronic device 130B and secondary data server 130A may be performed via connection 195. Similar to connection 190, connection 195 facilitates the secure exchange of electronic medical records to maintain the integrity and privacy of electronic medical records exchanged via connection 195. For example, connection 195 may comprise a Virtual Private Network (VPN) connection or another type of authenticated and/or encrypted connection sufficient to reasonably protect data exchanged over connection 195. In another exemplary embodiment, secondary data server 130A may be another electronic device owned and operated by the user, such as a PC, Network Attached Storage (NAS), or another electronic device.

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

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 user input to the consumer electronic device 130 indicating a request for an electronic medical record by selecting an icon rendered on a graphical user interface of a display associated with the consumer electronic device 130 and configured to initiate the request for the electronic medical record. In another example, the user 120 may use a keyboard or keypad to enter commands into a user interface rendered on a display associated with the user electronic device 130 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) rendered 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 from a medical services provider (e.g., authentication credentials) 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 an electronic storage associated with the electronic consumer 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 making the request for the electronic medical record. The hardware-specific machine token may be specific to the user electronic device 130 such that a storage system (e.g., storage systems 140 and 150) may verify that a request for an electronic record of a particular patient has been received from a physical device associated with the patient. In this example, unless the request is received from a consumer electronic device 130 associated with the user 120, the request for the electronic medical record associated with the user 120 may be denied. For example, the user 120 may be receiving treatment from a doctor at the doctor's office. The physician may ask the user 120 questions about the user's medical history that the user does not know the answer to. In response, the user 120 may use the user electronic device 130 as a secure conduit 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 can provide the physician with accurate information needed for treatment in real-time or at least without the delay associated with requesting and delivering the medical records to the physician's office. Further, in this example, because the request must come from the user electronic device 130, reasonable 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 enable determination of 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 the 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 of the user 120 and/or a medical services provider.

To enable the medical services professional to access the electronic medical records received at the user electronic device 130, the medical services professional may be authenticated. Authentication may be based on a combination of hardware and software tokens of a healthcare professional. The authentication may be performed at the user's electronic device 130. Authentication may also be performed at a remote server of an identity provider (IdP) with the user as a relying party. The verification can ensure the validity of the data access. In some implementations, 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 validated 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 record of the user 120 may authenticate the medical service provider. In response to the authentication request being from an approved medical service provider and from the 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, the user may configure a list of approved or certified medical service providers as stored at a particular storage system. The user may also (as an illustration) issue a credential token to each of the approved or validated medical service providers using the user's private key. A credential token encrypted using the public key of a particular approved or certified medical service provider may be issued to the particular approved or certified medical service provider such that only the particular approved or certified medical service provider may decrypt the encrypted credentials. The issued credentials may be revoked by the user when reconfiguring the list of approved or validated healthcare providers. In this example, an approved medical services provider that provides emergency care to the user 120 is able to quickly access the electronic medical records of the user 120 if the user is incapacitated or otherwise 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 on the head. In this example, a medical services provider that provides emergency care to the user 120 on-site may obtain the user electronic device 130 from a person of the user 120, enter authentication credentials, and access an electronic medical record of the user 120. By enabling the medical service provider to access the electronic medical records of the user 120, the medical service provider can provide more efficient and safer treatment to the user 120. Further, in this example, because the request must come from an approved medical service provider and from the user electronic device 130, reasonable 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 records included in the request, and generates a request for the electronic medical records 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 related to a network address for the first storage system and formatting information for the request to the first storage system. In these examples, consumer electronic device 130 may generate a request that is directed to the first storage system and in 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 otherwise generate the request to include 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 is able to 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. However, the information segment of the requested electronic medical record may not include information identifying the user. As disclosed herein, a particular electronic medical record may be segmented and each segment stored at a separate storage device. To mitigate the risk of data leakage, each segment is not only stripped of information identifying the patient (user), but is also encrypted by a patient-unique key (e.g., the user's public key). To combat data alteration/tampering, the segments may also include integrity checks. In one example, a hash code (e.g., MD5 hash) may be generated for a segment and embedded in the data segment in a manner unknown to an intruder. The embedded location may be secret and known only to the user. In another example, the hash code may be stored elsewhere and data integrity may only be confirmed upon a successful comparison. The hash code example is only one illustration. Other integrity check codes may also be applied. Such as a cyclic redundancy code or an error checking code.

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 creation of the first request described above with respect to step 206. The second request may be directed 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 sends the first request to storage system 140 and sends the second request to storage system 150 (210). For example, the consumer electronic device 130 may send a first request for an electronic medical record as an electronic communication to the storage system 140 via the network 110, and the consumer electronic device 130 may send a second request for an electronic medical record as an electronic communication to the storage system 150 via the network 110. The consumer electronic device 130 may send the first request and the second request simultaneously, or may send the first request before or after sending the second request. For example, consumer electronic device 130 may send a first request to storage system 140 and wait to receive a response from storage system 140 before sending 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 request only electronic medical records that were not received in the response from the storage system 140, and send 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 via the network 110. The first request may include information sufficient for the storage system 140 to identify the user, identify the electronic record of the requested user, and authenticate the 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 to a known token associated with the user 120 associated with the first request and authenticate the first request based on the comparison. Because the hardware-specific machine token is specific to the consumer electronic device 130, the storage system 140 may be configured to only authenticate requests received from the consumer electronic device 130.

In some implementations, the authentication token may include authentication credentials for the user 120 or healthcare provider associated with the request for the record. In these implementations, 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 the healthcare provider, and authenticate the first request based on the comparison. Because the authentication credentials are specific to the user associated with the record or an approved healthcare provider, the storage system 140 may be configured to authenticate the request based on the person making the request. Authenticating the first request based on the authentication credential may be performed in addition to or instead 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 an electronic storage device 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 implementations, the first request can 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 (orthopedic) medical records) or only electronic medical records from a certain time period (e.g., only electronic medical records from within the last 5 years) should be accessed. In this example, the storage system 140 may access the user's electronic medical records based on 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 can only access records associated with orthopaedic treatment and is prevented from accessing other types of medical records that may not be associated with orthopaedic treatment, such as hair loss or skin rashes. In another example, a user may set a limit or condition on the recording request 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 embarrassing or annoying medical records from being accessed via the record request, and the storage system 140 may prevent access to these records when an electronic request for the records is received. For example, information about a particular condition (e.g., herpes, HIV, erectile dysfunction, accidental pregnancy, miscarriage) may require special access authorization. The storage system 140 may be configured to provide a message to a person requesting a restricted record that access to the record 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 send the accessed electronic medical records as one or more electronic communications to the user electronic device 130 via 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 may be transmitted using another type of security technique for transmitting electronic information over a network. Further, the sending of the electronic record may include sending authentication information (e.g., an authentication token as described with respect to the user electronic device 130). The authentication information may be used by the consumer electronic device 130 to authenticate the electronic medical record so that the consumer electronic device 130 may verify that the electronic medical record is 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 and 226 using techniques similar to those described above with respect to the storage system 140 performing steps 212 and 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 be sent to more than two storage systems or only one storage system. The mechanisms disclosed herein may rely on a distributed storage model in which a particular electronic medical record may be divided into segments, with each segment being stored at a different storage device via the network 110. Such a distribution may greatly reduce the chance of data leakage caused by a single point of failure. In addition, each segment may be stored using encryption or integrity check features as disclosed herein.

Notably, a chain of trust may be established for a particular electronic medical record. The trust chain may include an authenticity feature for a particular electronic medical record, i.e., the particular electronic medical record is authentic as submitted by the purported submitter. Such trustworthiness features include the ability to prove that a particular electronic medical record has not been altered or tampered with since the particular electronic medical record was submitted. The chain of trust may also include non-repudiation characteristics of the particular electronic medical record. In other words, electronic medical records have certain features that prevent the trustworthiness from being repudiated.

In some instances, a Certificate Authority (CA) may provide digital certificates and public/Private Key Infrastructures (PKI) to participating entities, including, for example, individual patients, healthcare professionals, or health insurance operators. For example, a hospital (or healthcare professional) may submit an electronic medical record with a proof of authenticity, such as a digital certificate. In these examples, the electronic medical records may be encrypted with the submitter's private key, and the corresponding public key may be appended to the encrypted medical records. The public key may include a digital signature of the CA as a preliminary proof of legitimacy. By using PKI, the authenticity of the underlying electronic medical record can be verified. In these examples, the submitter may be a healthcare provider, such as a hospital, a treating physician, or a nursing nurse. The submitter may also include a health insurance operator, such as an insurance payer. In one example, the submitter may also include individual patients who are submitted electronically with their medical records.

In some instances, from the perspective of the patient, the authentication mechanism may also include a biometric (biometric) mechanism that links the data record to the patient. The biometric information may serve as an encryption key for encrypting the medical record data in a symmetric encryption/decryption mechanism. Biometric information may include digitized fingerprints, iris scans, retinal scans, and the like. The biometric mechanism may allow the electronic medical record to be decrypted at the user's electronic device 130 based on the user's biometric information (e.g., a fingerprint).

The proof of authenticity may prove the validity of the electronic medical record (like an electronic postmark) to indicate, for example, the originating hospital and the destination storage device.

In some instances, the electronic postmark can also include an integrity check code to verify the integrity of the underlying electronic medical record. Integrity check codes may generally include checksums, hash codes, error check codes. The integrity check code may also be encrypted by the PSO's private key to protect it against counterfeiting or tampering. In other words, the integrity checking mechanism may enforce the non-repudiation feature of a particular electronic medical record to prevent any alteration or tampering thereof.

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 electronic communications sent over network 110. In this example, the electronic communication and the electronic medical record may be encrypted, exchanged via a secure connection, or otherwise protected from unwanted or incorrect access. The electronic communication and the electronic medical record may include authentication information that the user electronic device may utilize to authenticate the received electronic medical record to ensure that the received electronic medical record is authentic. In some implementations, the user electronic device 130 can be configured to render a display of the received electronic medical record. In these embodiments, the medical services provider may view the electronic medical records on the display rendered by the user electronic device 130 when 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 via a wired connection only between the consumer electronic device 130 and the recipient electronic device 180 (and possibly 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 via a direct USB connection, or may establish a wired connection with a computer in the doctor's office via 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 via a wireless connection.

The consumer electronic device 130 transmits the electronic medical record to the recipient electronic device via the secure connection (232), and the recipient electronic device receives the electronic medical record (234). For example, the consumer electronic device 130 may send the electronic medical record to the recipient electronic device 180 via a secure connection in an electronic message, and the recipient electronic device 180 may receive the electronic message.

The recipient electronic device 180 displays and optionally stores the electronic medical record (236). For example, the recipient electronic device 180 may render a display of the received electronic medical records on a display device associated with the recipient electronic device 180 such that the medical services provider may view the electronic medical records on the display rendered by the recipient electronic device 180 when providing the therapy 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 electronic medical records in an electronic storage for recording purposes and later retrieval.

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

The consumer electronic device 130 receives a user input requesting an electronic medical record (310). For example, the user 120 may supply user input to the user electronic device 130 (e.g., using a keyboard, keypad, mouse, stylus, etc.) to initiate a request for an electronic medical record. In other examples, recipient 170 may input user input to consumer electronic device 130, or consumer electronic device 130 may receive user input from, for example, recipient electronic device 180 via connection 190 or network 110. By way of background, the disclosure herein may generally not rely on a caching mechanism to retain a local copy of an electronic medical record on the consumer electronic device 130 or the recipient electronic device 180. In particular, the consumer electronic device 130 may not store the electronic medical records for future use. Also, the healthcare professional may not wish to keep a copy of the electronic medical record on the recipient electronic device 180 longer than necessary, the leakage of which would pose an endless risk to the patient. Electronic medical records may include sensitive information, the disclosure of which may be highly undesirable.

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 is a request for all electronic medical records associated with the user 120 or only a subset of the electronic medical records are needed. In some implementations, the request may be for some type of electronic medical record. For example, the request may be for electronic medical records related to orthopedics 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 other embodiments, the request may be for a record for a particular time period. For example, the request may be for electronic medical records over the past 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 stores the requested record locally on the consumer electronic device 130, or whether an electronic device located at a remote location stores 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 may determine that the consumer electronic device 130 stores some of the requested records locally, and each of the plurality of record storage systems 140, 150, and 160 stores some of the requested records.

When the requested record is stored remotely in the distributed storage, the consumer electronic device 130 may determine the location of the storage. In one example, the consumer electronic device 130 may act as an address server that stores the address of the stored portion of the particular electronic medical record. The address of the stored portion may point to each individual storage location on the network 110 where a particular portion of the electronic medical record may be retrieved. In this example, the address may include a Universal Resource Locator (URL), a stub, a hyperlink, or any exemplary location mechanism. In this example, the stored address information may include indirect address information. In particular, the storage of certain portions of the electronic medical records may be determined by an address server remote from the user device 130. The address server may have assigned storage of certain portions of the electronic medical records to one or more storage servers. The address server may have mapped the storage location of each segment of the portions of the electronic medical record. As disclosed herein, when the consumer electronic device 130 attempts to access a portion of an electronic medical record, the consumer electronic device 130 may request a copy from an address server. The address server, in turn, may determine a whereabouts of the portions of the electronic medical record based on the mapping. The address server may then obtain the requested copy on behalf of the consumer electronic device 130 before forwarding the copy back to the consumer electronic device 130. In some instances, the address server may send the memory address back to the consumer electronic device 130 so that the consumer electronic device may update the memory map maintained on the consumer electronic device 130. Once the mapping on the consumer electronic device 130 has been updated, the consumer electronic device 130 may send the request directly to the storage server(s) that store the portions.

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

The consumer electronic device 130 receives a record sent from 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 multiple 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. 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 recording, the consumer electronic device 130 may again send a message requesting the recording, and/or may update the display to inform the user 120 that all of the requested recording has not been received and may request further user input on how to proceed (e.g., whether to continue requesting the recording and/or whether to remove restrictions, such as restrictions on the recording provider, when making subsequent recording requests). When the consumer electronic device 130 receives a particular electronic medical record, the consumer electronic device 130 may send an acknowledgement to the record storage system that sent the particular electronic medical record.

The consumer electronic device 130 renders a display of the recorded information (360). For example, consumer electronic device 130 may render a display of recorded information on a display of consumer electronic device 130, or may control a separate display device to render a display of recorded information. The record information may include a list of the received records, statistics associated with the records, and/or one or more of the received electronic records. In one embodiment, the received records may be medical records 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 recipient 170 may input a user input to the user electronic device 130 that displays the medical record of interest.

In some implementations, the display can be short lived and the assembled electronic medical record does not remain on the user electronic device 130 for a long time. For example, the duration of the display may be configured by the user to be just long enough for the healthcare professional to see the content. The duration of the storage on the consumer electronic device 130 may be controlled by a cryptographic token having a preset lifetime. The lifetime of the password token may be set by the patient on the user's electronic device 130. The temporary display may be applicable when the healthcare professional only needs to verify the information and does not need to retain the information. An example scenario may include when a healthcare professional needs to compare a newly acquired radiographic image to historically stored radiographic images stored in a distributed storage system via network 110. Such distributed storage over network 110 with ubiquitous (ubiquitous) access may be referred to as cloud storage. In these scenarios, the persistence parameters may be set such that electronic medical records assembled based on data segments from the cloud cannot be printed to a physical copy. The screen capture program may be turned off. Even scanning may be temporarily disabled.

In other embodiments, the availability of the assembled electronic medical records may have a longer lifetime. For example, the assembled electronic medical record may be available during a patient's stay. The assembled medical data may remain available at all times as the patient enters an Intensive Care Unit (ICU). When a patient is parked at a rehabilitation facility, the relevant electronic medical records may be accessible during the patient's stay.

The consumer electronic device 130 may optionally 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. As disclosed herein, data transfer may occur via a wireless, wired link, RF link, or IR link. In some embodiments, the data transfer may include a scanning mechanism. The recipient electronic device 180 can render a display of the recorded information on a display of the recipient electronic device 180 or can control a separate display device to render a display of the recorded information. The recipient electronic device 180 may store the received record locally on the recipient electronic device 180 or may 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 user 120, and recipient 170 may be a physician providing treatment to user 120. In this 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 consumer electronic device 130.

Fig. 4 illustrates an exemplary user interface 400 for requesting a record. The 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.

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 checkbox 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.

The 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 in identifying the record to retrieve and/or in an authentication process.

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

The authorization code text field 415 identifies an authorization code for a user of the consumer electronic device and enables the user to modify the authorization code. The user's authorization code may be used in the authentication process. For example, the consumer electronic device may provide an authorization code to the record storage provider, and the record storage provider may provide the record to the consumer electronic device only if the record storage provider receives a valid authorization code. The authorization code may time out after the expiration date. After the expiration date, a new authorization code may be required to gain access to the electronic medical records. As discussed herein, the authorization code may also be based on a digital biometric of the user, such as a fingerprint of the user.

The request all available records checkbox 420 enables the user to indicate that all available records of the user should be requested without restriction. When the request all available records checkbox 420 is checked, 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 check boxes 431 and 437 that enable the user to indicate that recording should only be requested from providers identified by the checked check boxes. Check 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, check box 431 may enable a user to limit Records to those from the provider Health hospital, check box 432 may enable a user to limit Records to those from the provider Jones physician, check box 433 may enable a user to limit Records to those from the provider Good Drugs pharmacy, check box 434 may enable a user to limit Records to those from the provider Reed physician, check box 435 may enable a user to limit Records to those from the provider Premium insurance company, check box 436 may enable a user to limit Records to those from the provider Health Records Database company, and check box 437 may enable a user to limit Records to those from all other providers. The user interface 400 may include checkboxes for all providers from which the user has medical records, all providers from which the user has a threshold number of medical records, or some number of providers from which the user has the most medical records.

The restrict to type section 440 includes check boxes 441-455 that enable a user to indicate that recording should be requested only for the type identified by the checked check box. Check box 441-. For example, check box 441 may enable a user to limit recordings to General Medical (General Medical) types, check box 442 may enable a user to limit recordings to cardiovascular types, check box 443 may enable a user to limit recordings to respiratory types, check box 444 may enable a user to limit recordings to neurological types, check box 445 may enable a user to limit recordings to orthopedic types, check box 446 may enable a user to limit recordings to muscle types, check box 447 may enable a user to skin disease types, check box 448 may enable a user to limit recordings to surgical (surgical) types, check box 449 may enable a user to limit recordings to allergy types, check box 450 may enable a user to limit recordings to immunological types, check box 451 may enable a user to limit recordings to types of medications, check box 452 may enable a user to limit recordings to types of psychosis, check box 453 may enable a user to limit recordings to types of dentistry, check box 454 may enable a user to limit recordings to types of vision, and check box 455 may enable a user to limit recordings to types of insurance recordings. The user interface 400 may include checkboxes for all types for which the user has medical records, all types for which the user has a threshold number of medical records, or some number of types for which the user has the most medical records.

The date restricted portion 460 includes check boxes 461 & 463, a start date text field 464, and an end date text field 465. The check boxes 461 and 463 enable a user to indicate that recording should be requested only for a specific time period identified by the checked check box. Checkboxes 461-. For example, check box 461 may enable a user to limit recordings to recordings within the past year, check box 462 may enable a user to limit recordings to recordings within the past five years, and check box 463 may enable a user to limit recordings to recordings within the past decade. The check boxes 461-. The start date text field 464 and the end date text field 465 enable the user to specify a custom time period from which the user desires to request medical records. The start date text field 464 identifies the start date of the time period for which the record is requested and enables the user to modify the start date. The end date text field 465 identifies the end date of the time period for which the record was 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 an electronic medical record. For convenience, certain components described with reference to fig. 1 are referenced to perform the process 500. However, a similar approach can be applied to other embodiments as follows: different components are used to define the structure of the system in these embodiments, or the functionality is distributed differently among the components shown in FIG. 1 in these embodiments.

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 record may be received based on user input supplied by user 120 or recipient 170 to consumer electronic device 130. In another embodiment, the request to add the record may be received in an electronic message over connection 190 or network 110. For example, the recipient electronic device 180 may send a request to add a record to the 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 the consumer electronic device 130 via network 110. In one embodiment, recipient 170 may send a request to add a record to consumer electronic device 130 via connection 190 using recipient electronic device 180. In this embodiment, the record may include a medical record of user 120 based on the treatment and/or diagnosis provided by recipient 170.

In some implementations, a request to add an electronic medical record may be initiated during a medical study. For example, the patient may agree to and participate in a medical study, including, for example, a clinical trial on a drug, medical device, or other healthcare product. By consent, patients may submit medical data during the trial so that the manufacturer may aggregate data from trial populations (sometimes including control populations) and report to the regulatory body. Data submissions may be generally anonymous. In other words, the data may not include information identifying a particular patient. The data may include information (e.g., gender and age range) that reveals certain characteristics of the patient. The submitted data may include information resulting from treatment (by healthcare products or by placebo). Treatment can be performed in a double-blind manner. The information may include treatment efficacy and side effects as recorded by scientific instruments measuring specific physiological parameters or imaging specific areas. These instruments may also be referred to as sensors. Such information may be generally referred to as a particular biomarker. For diagnostic purposes, biomarkers may include, for example, glucose levels, cholesterol levels, blood pressure, body temperature, tumor size, vascular status of mass, or viability of the heart muscle. In addition, subjective data (such as patient diaries) may be reported in studies of diseases such as alzheimer's disease, parkinson's disease, or wilson's disease. Some embodiments may increase the range of data available to regulatory agencies, such as the Federal Drug Administration (FDA), during, for example, a phase III drug trial. The range of parameters that can be monitored has increased. As does the duration of the monitoring. The monitored data may be reported securely without including data security. However, since the reported data is from the patient without counterfeiting or alteration, the reported data may be trustworthy and have increased trustworthiness.

As disclosed herein, in some embodiments, the electronic medical records may be reported to a central Patient Safety Organization (PSO). In some embodiments, the PSO may act as an intermediary reporting data collected from patients participating in medical studies (e.g., safety studies of pharmaceutical products). The PSO may receive an electronic certificate to verify the authenticity of the submitted data record. Electronic certificates may be used in single-factor or multi-factor authentication mechanisms to prove the trustworthiness of electronic medical records. The PSO may be the middle cube of medical research. Thus, the PSO may have less motivation to hide reporting negative or adverse effects. In contrast, such concealment may be more prevalent when the electronic medical records are from a manufacturer conducting a medical study.

The consumer electronic device 130 receives the new recorded information (520). For example, the consumer electronic device 130 may receive new record information for records associated with the user 120. In one embodiment, the new record information may be received based on user input supplied to the consumer electronic device 130 by the user 120 or the recipient 170. In another embodiment, the new recorded information may be received in an electronic message over connection 190 or network 110. For example, the recipient electronic device 180 may send the new record information to the 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 the consumer electronic device 130 via the network 110. The new recording information includes information related to 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 relating to the type, provider, and/or date of the new record, and/or information identifying the user with which the record is associated. In one embodiment, the new record information may include information related to the new medical record of the user 120. In this embodiment, the new record information may indicate that the record is for user 120, that the record relates to the accepted treatment of 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, consumer electronic device 130 may update data related to a record associated with user 120. The updated data may include data sufficient to identify the new record and retrieve the new record if requested. 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 from the consumer electronic device 130. The updated record information may indicate that the user's new medical record is stored on the particular electronic device and may include information related to the type, provider, and date of the medical record.

The consumer electronic device 130 may optionally 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 supplied 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 an electronic message over connection 190 or network 110. For example, the recipient electronic device 180 may send the new electronic recording to the 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 recording to the consumer electronic device 130 via the 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 via connection 190. In this embodiment, the new electronic record may be a medical record of user 120 based on the treatment and/or diagnosis provided by recipient 170.

The consumer electronic device 130 may optionally store the new electronic record (550). For example, the consumer electronic device 130 may store the new electronic record in a local storage 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 database of medical records for the user 120, and the consumer electronic device 130 may update the database of medical records by storing the new electronic record.

As disclosed herein, electronic medical records may be added to a database located at a PSO. The database located at the PSO may be shared among multiple data providers. Data sharing may rely on a chain of trust to authenticate underlying electronic medical records or portions thereof.

During a medical study (e.g., a clinical trial with hundreds or even thousands of participating patients), the addition of data may be part of a data reporting process, for which data addition and reporting may need to be synchronized.

In some embodiments, the electronic medical record may be supplemented by information collected from health-related tissues. For example, recipient 170 may include a health-related organization to which the user has authorized access to the user's particular electronic medical records. Example organizations may even include social media sites and pharmacies.

In one example, electronic medical records including fitness data may be captured by mining social media channels (such as blogs, Facebook, twitter, or WeChat). The user may post the health club participation data on a social media channel, including on the health club's data portal. In this example, the data mining bot on the user electronic device 130 may search social media channels and capture such relevant healthcare information. The captured information may supplement existing electronic medical records.

In another example, the patient may enter into a monitoring agreement with a pharmacy or healthcare professional. Illustratively, the pharmacy may provide a discount rate to entice the patient to register a program for monitoring refill (refill) mode. Likewise, the healthcare professional can offer a discount to the patient in exchange for the patient registering a monitoring program for tracking follow-ups, rehabilitation visits, readings from sensors at home, and the like. Under such monitoring procedures, the user's electronic device 130 may generate electronic medical records based on monitored re-supplementation patterns, follow-ups, rehabilitation visits, and sensor readings. Such medical records are not only used for reporting purposes, but also to prevent fraudulent insurance claim submissions (or insurance policy abuse).

The consumer electronic device 130 may optionally send the new electronic record to the database provider (560). For example, consumer electronic device 130 may send the new electronic record to a database provider via network 110 or connection 190. In one embodiment, consumer electronic device 130 may receive a new electronic record from recipient electronic device 180 via connection 190 and may transmit the new electronic record to one of the plurality of record storage systems 140, 150, and 160 via 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 to indicate that the new electronic record is stored on the one of the plurality of record storage systems 140, 150, and 160.

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

User interface 600 includes a patient information portion 610, a patient device information portion 620, a record information portion 630, a locally stored checkbox 650, a send to database provider checkbox 660, an add record interface actionable item 670, and a cancel interface actionable item 680.

The patient information section 610 includes a name text field 611, an address text field 612, a phone number text field 613, an email 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. 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 portion 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 additional documents 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's name. Category text field 632 identifies the category associated with the new medical record and enables the user to modify the category. The 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 the 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 enters a prescription in the prescription text field 637, the prescription may be automatically sent to the pharmacy when the medical record is 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, calendar entries for the subsequent appointment may be automatically entered in the calendar of the physician and the calendar of the patient. The attached file text field 639 identifies the name of the file to be attached associated with the new medical record and enables the user to modify the name of the file to be attached. An additional file text field 639 may enable a user to attach other files (such as images, other records, and/or other documents) to the medical record. 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 for files to be attached to a medical record.

The local storage checkbox 650 enables a user to indicate that a new medical record should be stored locally. For example, the local storage checkbox 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, the local storage checkbox 650 may enable a user to indicate that a new medical record should be stored locally on the electronic device associated with the physician and/or at a location associated with the medical record.

Sending a checkbox 660 to the database provider enables the user to indicate that a new medical record should be sent to the database provider to store the new medical record. For example, sending a check box 660 to the database provider may enable the user to indicate that the new medical record should be sent over the network to the record storage system for archival storage.

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

Referring to fig. 7, medical record aggregation may be performed relatively anonymously. As shown, three (and perhaps more or fewer) electronic medical records storage systems 710, 720, and 730 store electronic medical records of patients as follows: in this manner, the electronic medical records for a particular patient and the user identity information for that particular patient are broken down across the three electronic medical records storage systems 710, 720, and 730. In other words, a breach of one of the three electronic medical records storage systems 710, 720, and 730 does not enable a breaching user to identify a particular patient, does not enable the breaching user to access other storage systems using identification and/or authentication information of the breach storage system, does not provide the breaching user with full access to the entire set of medical records of the particular patient or even to the complete information of the particular record, and does not enable the breaching user to identify other electronic medical records storage systems in which the remaining medical record information of the particular patient is stored. Thus, by using the electronic medical record aggregation technique shown in fig. 7, electronic medical record storage and aggregation may provide increased privacy and anonymity for patients.

The electronic device 740 is used to aggregate and display medical records for a particular patient. The electronic device 740 acts as a secure agent or conduit 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 a particular patient, as well as information needed to authenticate and retrieve the electronic medical records for a particular patient from each of the electronic medical records storage systems. In some implementations, the electronic device 740 may communicate with another device via 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 renders a display of 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 that stores instructions executed by the processor in performing the described processes and that stores information used by the electronic device 740 in acting as a secure agent or conduit for accessing decomposed electronic medical record information (e.g., identification information for the electronic medical record storage system, identification/authentication information for each of the electronic medical record storage systems, 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 acts as a secure agent that aggregates and displays electronic medical records for John Smith. The electronic medical records storage systems 710, 720, and 730 may be similar to the records storage systems 140, 150, and 160 described above with reference to fig. 1. Each of the three electronic medical records storage systems 710, 720, and 730 includes different identification information for John Smith and different authentication information needed to obtain electronic medical records for John Smith.

Specifically, 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 using the machine token. In this example, the machine token is labeled as token: 89965. thus, to retrieve an electronic medical record for John Smith from the electronic medical records storage system 710, the electronic device 740 (e.g., from an electronic storage of the electronic device 740) accesses 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 electronic medical records associated with John Smith (e.g., from electronic storage of the electronic medical records storage system 710), 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 the user ID: XJ689 and uses password "1234" to perform authentication of John Smith. Thus, to retrieve electronic medical records for John Smith from the electronic medical records storage system 720, the electronic device 740 accesses the user identification XJ689 and password "1234" information (e.g., from an electronic storage of the electronic device 740) 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, accesses electronic medical records associated with John Smith (e.g., from electronic storage of the electronic medical records storage system 720) based on the user identification and password information, 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 the user ID: JPFI and use the password "56789" to perform authentication for John Smith. 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 with respect to retrieving electronic medical records from the electronic medical records storage system 720, but uses different identification information and passwords.

Thus, when the electronic device 740 receives a request to access a medical record (e.g., a user input from the input unit 745 to access an electronic medical record for John Smith), the electronic device 740 automatically generates a request for an electronic medical record from each of the three electronic medical record storage systems 710, 720, and 730 without human information, and aggregates the information for display to the user. More specifically, 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, each of the three electronic medical records storage systems 710, 720, and 730 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: bone fracture, R6: heart attack 11/11/04, R7: DOB 08/20/1953, R11: ACL tear 05/08/97, R12: VG04, and R13: analgesic 05/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 sends 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: blood type A +, and R12: IR60) to the electronic device 740. Further, 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: tibia 06/06/05, R4: BP 112/86; 04/05/06, R5: CNRCHV 127, R9: pacemaker 12/12/04, R10: penicillin 06/01/07, and R12: AA07) to the electronic device 740.

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

Upon rendering 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 for the records is received 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 may combine these records into an aggregated/integrated display without additional processing.

For partial recordings (e.g., recordings in which information for the recording is received from multiple sources), the electronic device 740 processes the separate segments received for each recording and generates a complete recording based on the separate segments when aggregating the recordings. Partial records may be used to guarantee additional privacy protection for more sensitive information. Leakage of a complete record can be more difficult because several pieces of information from several decomposed sources are needed to generate the complete record.

For example, the records R1, R5, and R12 represent partial records. As shown, the record R1 includes information stored in the electronic medical records storage system 710 (e.g., R1: bone fracture) 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 needed 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, but does not specify which bone is fractured or when the bone is fractured. The information stored in the electronic medical records storage system 730 indicates that the medical record is associated with the tibia on date 06/06/05, but does not specify 06/06/05 of the occurring disease or treatment associated with the tibia. In combination, the electronic device 740 determines that the patient experienced a tibial fracture at 06/06/05, and may combine the partial records for use in displaying the medical record R1 as "R1: tibial fracture 06/06/05 ".

Records R5 and R12 are examples of electronic medical records stored across multiple storage systems, where a specific process is required to combine partial information in generating a complete record. Specifically, 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. In doing so, the electronic device 740 determines that the patient is infected with HIV at 01/22/07, and may combine the partial records for use in displaying the medical record R5 as "R5: infection with HIV 01/22/07 ". Thus, to determine that the patient is infected with HIV at 01/22/07, the user that caused the leak would have to intercept both 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 procedures required to combine the information. Revealing electronic medical record information stored in this manner can be difficult because intercepting one of the partial records will not convey intelligible information related to the record, and because the partial records are retrieved using different identification/authentication information and do not include information related to the combining process or other source of the record, intercepting a single portion of the record will not result in the process required by the user causing the disclosure to find other portions of the record or the combined decomposed portions.

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 up to the electronic informatics medical records storage system 730. In doing so, the electronic device 740 determines that the patient was prescribed a warrior (Viagra) at 06/04/07, and may combine the partial records for use in displaying the medical record R12 as "R12: wanaike 06/04/07 ". Although specific examples of combining partial electronic medical records have been described, other processes and techniques for combining partial records to maintain anonymity may be used and/or combined with other techniques such as encryption.

In some implementations, the electronic device 740 renders a display based on the aggregated electronic medical records (e.g., as complete received complete records and partial records that have been combined to generate complete records). In displaying the aggregated electronic medical records, the electronic device 740 may organize the display based on various 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 as R12, R10, R13, R3, R5, R2, R4, R1, R9, R6, and R11. R7 (date of birth) and R8 (blood type) were recorded independent of date. Thus, records R7 and R8 may be displayed first or in separate sections that are used to distinguish dated medical records from dated medical records. A filter may be used regarding the date of the electronic medical records (e.g., older electronic medical records may be eliminated for a certain threshold (such as ten years), or a particular date range may be defined for aggregating electronic medical records and only electronic medical records from the 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 record data may make the electronic medical record data easier to comprehend 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 use the electronic device 740 to calculate an average blood pressure for a patient (e.g., John Smith). The electronic device 740 may recognize that the records R2-R4 include past blood pressure data and average the blood pressure data received in the records R2 and 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 a mean blood pressure and displays the mean blood pressure as a mean BP-112/83. Other statistical processes may be performed on the aggregated electronic medical records, and other results may be determined and displayed by the electronic device 740.

As noted herein, the electronic device 740 may be similar to the consumer electronic device 130 described above with reference to fig. 1A. In some implementations, the electronic device 740 can also include an assistance date server as shown in fig. 1B. The electronic device 740 may also include components that interface with Patient Safety Organization (PSO). The PSO interface component may collect patient data and report the data to the PSO. Such data may include, for example, heart rate summary data, respiration rate summary data, and the like. Such data may be based on, for example, raw heartbeat data collected in real time. All data submitted may be stripped of patient identification information so that the data submitted is anonymous in order to maintain privacy of the patient.

The PSO may include an algorithmic implementation that presents anonymous information to healthcare providers that have contracted with the PSO. The anonymous information may not be provided to other parties. The anonymous information received from the PSO may be based on an electronic medical record or portion of a record of the patient owning the electronic device 740. The anonymous information received from the PSO may include aggregated information based on, for example, electronic medical records from all patients served from a healthcare provider. As noted herein, the healthcare provider communicates with the assistance data server of the electronic device 740.

In some instances, the information received from the PSO may include patient safety statistics on an anonymous basis, for example, during a drug trial. In other examples, the information received from the PSO may also include, for example, a prescription pattern for a particular healthcare professional or a prescription fill pattern for a given pharmacy store. In still other instances, the information received from the PSO may include a prescription profile for a particular patient. For example, an intelligent application on the user electronic device 740 may communicate with, for example, the electronic medical records storage systems 710, 720, and 730 to request such summary statistics. Summary statistics may include, for example, the number of adverse effects reported for a pharmaceutical product, the number of healthcare providers involved in an ongoing drug trial, the number of prescriptions written by a particular physician for a given pharmaceutical product. Also, more detailed statistical information may be available to pharmacies, drug manufacturers, insurance companies, or regulatory agencies. The more detailed statistical data may include a statistical distribution of prescription patterns, a confidence level for a given statistical metric, or even a trend prediction of prescription patterns for a particular pharmaceutical product.

As disclosed herein, electronic medical records as retained at electronic medical record storage systems 710, 720, and 730 are typically stripped of patient identification information. The distributed storage of electronic medical records in anonymous form alleviates privacy concerns from individual patients and liability concerns from healthcare providers. At the same time, the distributed storage of electronic medical records for statistical analysis enables data mining of aggregated electronic medical records to provide insights into stakeholders including individual patients, healthcare providers, insurance payers, and regulatory agencies. The ability to extract value from the ocean of de-identified electronic medical records in distributed storage may enable particular stakeholders to better understand relevant issues and make more informed decisions.

The PSO may serve as an intermediary for reporting data collected from patients participating in a medical study. The PSO may be the middle cube of medical research. Thus, the PSO may have less motivation to hide reporting negative or adverse effects. In contrast, such concealment may be more prevalent when the electronic medical records are from a manufacturer conducting a medical study.

In effect, a PSO is created to receive and process electronic medical records in order to generate feedback to remedy potential defects or improve potential inefficiencies in current medical practice. The PSO may provide the analysis in a secure manner. The participating healthcare professionals are not penalized for any defects or inefficiencies identified in the analysis performed by the PSO.

In general, submitters of electronic medical records may include healthcare providers, such as hospitals, therapists, diagnostic laboratories, and rehabilitation facilities. However, the benefit of having separate PSOs to aggregate and analyze anonymized electronic medical records may allow more parties to share data. By way of illustration, the patient or the principal of the patient may choose to participate in sharing the patient's electronic medical records. In one example, a party in the patient's identity may conclude that: the patient does not have any loss in submitting the patient's electronic medical record in an anonymous manner. In other instances, a party in the patient's identity may have an incentive to anonymously submit an electronic medical record for the patient. In such instances, a party in patient identity may be economically enticed to share a patient's electronic medical record anonymously in exchange for, for example, monetary compensation (on whatever basis, including receipt of coupons) or preferential access to the analysis results, pursuant to a compensation (quick-pro-quo) arrangement. As more parties share the patient's electronic medical records, the size of the data sample pool may increase, the overall quality of the raw data may improve, and the confidence of the statistical analysis may increase. As stakeholders begin to gain the benefits of sharing data, submitters will become more devoted to more data sharing in the future.

In some instances, an application on the user electronic device 740 may be configured to anonymously submit the user's electronic medical records. In one example, the application may utilize a random string (such as a hash) in place of the information identifying the user in the electronic medical data. The random string may later be used to assemble segments of electronic medical data of the same user collected from the distributed storage. The random string may also serve as a key for downloading statistical analysis or trend prediction from, for example, a data provider. In another example, the application may intelligently decide which portion of the user's electronic medical record is to be submitted. For example, the template configuration may triage (triage) submissions of electronic medical records. In one configuration, portions of the medical record that are considered taint (stigma) may not be submitted. In another configuration, overly bulky portions of medical records may be reduced or consolidated prior to submission. Examples of bulky parts may include: real-time recording of 3-dimensional imaging data, 4-dimensional imaging data, or electrocardiogram data of a patient. By way of illustration, the electrocardiographic data may be trimmed to highlight transitional trends, such as under stress testing; the voluminous imaging data can be reduced to reduce the data size; longitudinal data may be merged to remove fixed entries that do not show any changes. In short, the reporting mechanism may be ad-hoc, but consistent with the purpose and intent of PSO to promote transparency without compromising privacy.

In other exemplary embodiments, the analysis performed on the electronic medical records, as well as any resulting data as described above, may be shared with several other entities. In one example, the data is shared with the caregiver. In another example, data is shared with family members. In another example, the data is shared with a healthcare provider, or a pharmacy, or a school system. In these illustrative examples, the previously described process of sharing data by authenticating the recipient and providing authentication information for the data being shared may be utilized. Some of this data may be shared anonymously. Some data may also be shared with identification information specified by the user.

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 into a certain category, and may also group electronic medical records related to medications that the patient is currently taking and/or has taken 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 related to the drug and group records R10, R12, and R13. 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 (e.g., heart (2) and medication (3)) that have been grouped in the categories. Clicking on a display item associated with the group "heart" or the group "medication" may display electronic medical records that have been grouped into a particular category. Grouping records and displaying categories may enable a healthcare provider to more quickly identify important/relevant electronic medical records without having to review the complete set of electronic medical records. Clicking on a particular link may elicit 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 assembly of these records. The electronic device 740 acts as a secure conduit configured to receive and display the resolved medical records.

Fig. 8 is a flow diagram of a process 800 for anonymously aggregating medical records. For convenience, the particular components described with reference to fig. 7 are referenced to perform the process 800. However, a similar approach can be applied to other embodiments as follows: different components are used to define the structure of the system in these embodiments, or the functionality is distributed differently among the components shown in FIG. 7 in these embodiments.

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 an electronic medical record, and the process of aggregating electronic medical records may be triggered.

In response to initiation of the process of aggregating electronic medical records associated with the patient, the electronic device 740 identifies at least a first electronic medical records storage system and a second electronic medical records storage system that each store electronic medical records associated with the 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 not aware 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 the 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 a patient from the 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 the 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 the 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 generates a second request for a medical record using the second patient authentication information (825). The electronic device 740 may generate the first request and the second request by including the first authentication information and the second authentication information in electronic messages to be sent to the first electronic medical records storage system and the second electronic medical records storage system, respectively. The electronic device 740 may generate the first request and the second request using different protocols, formats, and/or encryption techniques applicable to the first electronic medical records storage system and the second electronic medical records storage system, respectively. The electronic device 740 may store information and formats required to utilize the electronic medical records storage system to generate the information required for the request. 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 request and the second request may include any combination of authentication information, such as a machine token, password, identifier, encryption technique, encoding, and the like.

The electronic device 740 sends the first request to the first electronic medical records storage system and sends the second request to the second electronic medical records storage system (830). For example, the electronic device 740 sends the first request and the second request as electronic messages over a network to the first electronic medical records storage system and the second electronic medical records storage system. The first request and the second request may be sent at the same time or at different times.

The electronic device 740 receives a first response from the first electronic medical records storage system that 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 electronic medical records storage system receiving the first request and authenticating the first request based on the first patient authentication information.

The electronic device 740 receives a second response from the second electronic medical records storage system that 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 response and the second response may not include identification information associated with the patient, and may also not include information identifying any of the other electronic medical records storage systems. Limiting the information in the first and second responses to the particular electronic medical records storage system that sent the response may promote anonymity and privacy of the electronic medical records, as leakage of a single storage system or response does not result in information that enables leakage of the entire collection 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 of the patient included in the first response with a second portion of the one or more electronic medical records of the patient included in the second response (845). In some implementations, the electronic device 740 receives a first response including a first portion of a first electronic medical record of a patient stored at a first electronic medical records storage system and receives a second response including 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 the received complete electronic medical record), the electronic device 740 combines the complete records into a set of electronic medical records for the patient. The electronic device 740 may organize the electronic medical records by date, by category, or by another type of 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 a collection. 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 viewer of 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 assembly of electronic medical records as a single file. The electronic device 740 may also perform statistical processing or grouping of 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 send the electronic medical record information to another device for display when the other device has a larger or otherwise 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, identifying at least the first and second electronic medical records storage systems, identifying the first patient authentication information, identifying the 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 occur automatically, without human intervention, in response to initiation of a process of aggregating electronic medical records associated with a patient. Further, both the first request and the first response may 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. Further, both the second request and the second response may not 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 render a display of the aggregated electronic medical records. The patient electronic device 930 includes an input unit 935 (e.g., a keypad, etc.) that enables a user to provide user input to the patient electronic device 930, and a display 940 that renders a display of electronic medical record information. The patient electronic device 930 includes a processor configured to control the operation of the patient electronic device 930 and the patient electronic device 930 includes at least one computer-readable storage medium that stores instructions executed by the processor in performing the described process and that stores information used by the patient electronic device 930 in acting as a secure agent or conduit for accessing the disaggregated electronic medical record information (e.g., identification information for the electronic medical record storage system, identification/authentication information for each of the electronic medical record storage systems, 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. In one example, the consumer electronic device 130 may allow an authorized emergency service provider 920 to access the consumer electronic device 130 when, for example, the consumer 120 has lost consciousness in an emergency situation. In this example, the user 120 may have delegated (e.g., by default) the emergency service provider 920 to act on behalf of the user 120 in the event that the user 120 is incapacitated in an emergency.

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 (passcode). For example, the patient electronic device 930 may render a display of the input controls 945 on the display 940, and the emergency service provider 920 may use the input controls 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 reveals 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 use in authentication. The patient electronic device 930 may ask the emergency service provider 920 to enter identification information (e.g., employee ID, badge (badge) number, name, etc.) prior to authentication. Requiring entry of identifying information may enable tracking of emergency service providers 'access to other patients' electronic medical records. The tracking system may track emergency service provider access to the electronic medical records 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 improper number of medical record access requests or is requesting an electronic medical record for a patient for which 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 (s)) 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 the centralized emergency service provider's authentication electronic device, which may authenticate the input authentication information, and which may report the results of the authentication to the patient electronic device 930. The authenticating electronic device of the centralized emergency services provider may track emergency services provider access to electronic medical records, generate reports, and send alerts when suspicious electronic medical record access occurs.

The elderly may have signed a medical attorney of a designated caregiver such that if the elderly becomes unable to make healthcare decisions, the caregiver will make such decisions on behalf of the elderly. When the elderly are incapacitated, the caregiver may act quickly on behalf of the elderly. To do so, the caregiver may need to access the elderly's medical records so that the healthcare professional can make informed decisions in making treatment like a treating physician. To enable a caregiver to access medical records on behalf of the elderly, the caregiver may be given limited access commensurate with the scope of the medical attorney. The caregiver may be granted such access to the elderly's medical records stored in segments in a distributed location. The caregiver may also be given corresponding access to the elderly's mobile device so that the caregiver may access the elderly's medical records from the elderly's mobile device. In such a scenario, the elderly may have authorized a caregiver to access the elderly's mobile device. Access may be limited according to the scope of the medical order. Also, the caregiver can submit a request for electronic medical records from the elderly's mobile device according to the medical attorney. The submitted request may identify the caregiver, but not the elderly, as the data requestor. Where the caregiver is a partner or cooperative facility (such as the senior living community), the medical attorney may be extended to designated members of the partner or cooperative facility. In other cases, if the caregiver is a corporation, the medical principal may extend to its subsidiaries, or even parent. In special cases, the medical Power of attorney may also exist according to the company's full rights representative (alter ego).

Similarly, a child may assign the child's healthcare decisions to a guardian. In most cases, the guardian is one of the parents. In some cases, the guardian may comprise another family member or even a third party. Example scenarios are not limited to divorce programs, where children may be monitored by family members. For example, the child may be in an in-school sports team, a community sports game, or a championship game. The sport in question may not be limited to recreational sports and may have competitive elements such as hockey games, baseball games, swimming courses. In fact, some intra-school sports may require each participant to sign a medical principal that designates someone (such as a coach in a school) to make a medical care decision if the participant is unconscious during the event due to an accident. In another example, a school in which the child is located may require access to the child's electronic medical records. Example situations may include when a child is on a sports team organized by school, when a child travels off the field to a school organization, or when a child engages in a daily school routine. In these example situations, if a child suffers an injury or accident, designated school personnel may seek medical care on behalf of the child.

In the above example, during an accident that unconsciouss a child and leaves the child guardian absent, the designated person may have limited access to the electronic medical records of the participant (e.g., minor). Generally, situations requiring a given person to act as a caregiver in an emergency situation may also include participating in sports clubs, gyms, sailing activities, and the like. The scope of data access is limited according to the medical authority. To gain access, a designated person may be authenticated based on, for example, authentication credentials. As disclosed herein, the authentication credentials may include a cryptographic token issued by the participant(s), including the guardian of the child. The authentication credentials may also include a designated person-specific hardware token. In one example, a request for medical record data may be submitted from a participant's mobile device. In this example, the request may be submitted with information indicating that the request was submitted by a designated person on behalf of the participant. In another example, a request for medical record data may be submitted from a computing device of a designated person. The participant may have pre-registered the designated person as one authorized party in a list of pre-approved parties. Thus, some embodiments disclosed herein may establish a delegation chain in case of emergency, e.g., delegation to a guardian, delegation of a guardian to a designated person. In some implementations, an application on the consumer electronic device 130 can perform the delegation task. For example, the application may be configured in conjunction with an expert system to determine the scope of medical information to be disclosed to the principal. The determination may be based on specific criteria set in advance and event driven. For example, the application may be configured to disclose more information to the principal during a scheduled sporting event than during a school routine. The disclosure may be determined based on the capabilities of the principal making the request. When a request is made by a school coach during a scheduled sporting event, the disclosed ranges may be comprehensive, including, for example, physiological parameters or past medical treatments. However, when the request comes from a school during the day, the scope of disclosure may be limited to the children's profile level information, such as calories consumed, activities performed.

Valid authentication information (e.g., a valid password) may change over time (e.g., a new password may be issued daily). For example, each emergency service provider may receive a new password on each day the emergency service provider works. The new password may be received using a secure electronic communication mechanism or may be posted in an area intended for the presence of only 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.) of the licensed/authorized emergency service provider or may request and receive authentication information (e.g., a password, token, etc.) of 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 risk associated with potential leakage 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 lieu of the password-based authentication described above. Hardware authentication may require that the emergency service provider 920 physically possess a particular hardware device to be authenticated as a licensed emergency service provider. For example, the particular hardware device may be a hardware key or dongle (dongle) that the emergency service provider physically connects to the patient electronic device for authentication.

In some implementations, the hardware device used for hardware authentication can be electrically 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 used by an emergency service provider 920 to perform hardware authentication operations. In this example, the wireless communication device 950 can exchange a predefined series of communications with the patient electronic device 930, and the patient electronic device 930 authenticates the emergency service provider based on the exchanged communications (e.g., alone or by communicating with another centralized authentication device). The communications exchanged by the wireless communication device 950 and required for authentication may change over time as discussed above for cryptographic authentication. Usage of the wireless communication device 950 (or another hardware authentication device) may also be tracked as discussed above. The specific hardware device may only be released to the licensed emergency service provider and may be under the control of the emergency service authority to enable the emergency service 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 renders a display of 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 reference to fig. 7.

In some implementations, the emergency service 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 medical treatment and exclude electronic medical records that are irrelevant or less important to the emergency medical treatment. Thus, the emergency services provider 920 may receive fewer electronic medical records than the patient 910 (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 and the type of medical records (or which records to provide) provided to the emergency service provider 920.

In other embodiments, different levels of access may be provided to emergency service providers having different credentials. For example, fewer records may be provided to ambulance drivers than emergency room doctors treating patient 910, and fewer records may be provided to emergency room doctors than surgeons performing emergency procedures on patient 910. The level of access (e.g., number and type of records) may be tailored to the type of service provided by the emergency service provider. The access level may be defined based on patient preferences, 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 to the patient 910 when requesting an electronic medical record. In these examples, the additional information may include emergency contact information and pre-living will information (e.g., patient preferences regarding whether the patient desires to be rescued). The information may also be provided to the emergency service provider 920 in a different form 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 prominent manner (e.g., prominent HIV positive).

In some implementations, the patient electronic device 930 may transmit the electronic medical records to the 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 by the patient electronic device 930, the patient electronic device 930 may automatically transmit (or control another device to transmit) the electronic medical record to the hospital or doctor's office where 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 that are 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 information known to the emergency service provider 920 (e.g., the hospital at which the emergency service provider 920 is working) or known to 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 medical treatment because an emergency service provider at the hospital or doctor's office may have some time to review 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 services provider 920 attempting to access the electronic medical record, and is also the type of input that the patient 910 may provide when being treated by the emergency services provider 920 when the patient is unconscious or otherwise incapacitated.

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, the particular components described with reference to fig. 9 are referenced to perform the process 1000. However, a similar approach can be applied to other embodiments as follows: different components are used to define the structure of the system in these embodiments, or the functionality is distributed differently among the components shown in FIG. 9 in these embodiments.

The patient electronic device 930 receives a request to access a medical record associated with the patient 910 from the emergency service provider 920 of the patient 910 to which the patient electronic device 930 belongs (1010). The patient electronic device 930 may receive a request to access the medical record associated with the patient 910 based on user input provided by the emergency service provider 920 to the patient electronic device 930, or may receive a request to access the medical record 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 with the emergency service provider 920 based on authentication information provided to the electronic device by the emergency service provider 920 to determine a status of the emergency service provider 920 (1020). For example, the patient electronic device may perform a two-stage authentication process that requires the entry of a valid password and the use of a hardware device issued by the emergency services agency to perform the second stage of the hardware authentication process. The authentication process may include receiving input from a hardware device issued by the emergency services agency to the emergency services provider to enable authentication of the emergency services provider to an electronic device of the patient configured to aggregate electronic medical records associated with the patient, and determining a condition of the emergency services provider based on the input received from the hardware device. The authentication process may also include receiving an 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 implementations, the patient electronic device can determine whether the emergency service provider is licensed or can determine a credential level for the emergency service provider 920. The credential level may be at least one of a rescuer, an emergency room doctor, and a surgeon performing an emergency procedure.

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 a biometric input from the patient indicating that the patient is physically proximate to the patient's electronic device. The biometric input may be a fingerprint scan or a retinal scan that the patient may be able to provide even when the patient is unconscious.

The patient electronic device 930 accesses the patient 910 preferences regarding emergency service providers accessing the patient's medical records from the electronic storage (1030). The patient electronic device 930 may access the profile information from an electronic storage of the patient electronic device 930, or may access the profile information from an electronic storage of a device remote from the patient electronic device 930 via a network. The profile information may indicate the patient's preferences regarding 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 preferences of the patient (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, a no level of access that does not enable any access to medical records of the patient, and an intermediate level of access that enables access between the full level of access and the no level 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 a rescuer, the patient electronic device 930 may determine to 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 920 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 the electronic medical records associated with the patient 910 based on the determined level of access 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 record associated with the patient 910 to the emergency service provider 920 (1060). The patient electronic device 930 may display the virtual assembly of electronic medical records as a single file. The electronic device 930 may also perform statistical processing or grouping of 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 send the electronic medical record information to another device for display when the other device has a larger or otherwise 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 implementations, the patient 120 may anonymously broadcast a request for medical services to a community of healthcare professionals who subscribe to the broadcast channel, as shown in fig. 11. The broadcast channel may include any form of electronic communication, e.g., email, SMS. As shown, the broadcast request may be sent by an application on the consumer electronic device 130. The application may be configured to hide any information identifying the submitting patient. In one example, the application may be configured to abstract the identifying information into classification parameters based on, for example, gender and age group. However, the broadcast request may include a particular level of information for the patient, such as general symptoms, possibly related professions. In general, the patient may configure the granularity of information to be shared. For common symptoms, default or template settings regarding the amount and abstraction of patient information to be shared may be applied. For more specific conditions, the level of information may be more specific to the target organ or system. For example, if the symptom includes angina, the information may include a cardiac parameter, such as blood pressure, low density cholesterol (LDL) level, or high density cholesterol (HDL) level. In this example, the level of information may not include information identifying the patient.

The healthcare professionals 170A-170C can review the submitted requests and determine whether they have the ability to provide assistance, whether they have the ability to provide the requested service, and whether they are working with the patient's health insurance policy. The healthcare professionals 170A-170C may also provide the requesting user 120 with an estimate of the cost, the available time of office access, and the services available at the office. The response may be in the form of a bid, and may also include credential information for the healthcare professional, including, for example, the age of the practice, graduate school, committee certifications, patient review statistics, and recommendations from sample patients.

Referring to the flow diagram 1200 of FIG. 12, the user 120 may submit a request from an application at the electronic device 130 to provide healthcare services for a particular condition (1210). The bids can be collected 1220 from the network 110 by an application on the consumer electronic device 130. The bid may be presented 1240 to the requesting user via an information interface on the consumer electronic device 130. In some instances, the application may rank the received bids. In one example, the ranking may be based on a degree of match between the benefit of the healthcare provider and the requested healthcare service.

In another example, the ranking may be based on price estimates provided by healthcare providers bidding for the requested healthcare service. In this example, the requesting user 120 may configure the ordering to be in ascending or descending order. In this example, the requesting user 120 can fine-tune the ranking based on adjustment factors that take into account, for example, historical price adjustments by the healthcare provider at the time of bidding. In some instances, the historical price adjustment may include an average upward or downward adjustment amount at the time of bidding. In other examples, the requesting patient 120 may be flagged with a historical price dispute between the reported healthcare provider and the patient's health insurance carrier. The details of such a report may be available to the patient's health insurance carrier at the time of the health insurance carrier's request.

In yet another example, the ranking may be based on the background experience of the bidding healthcare professional. The background experience of the bidding healthcare professional may include the area of expertise of the bidding healthcare professional. For example, an application on the consumer electronic device 130 may apply more weight to the bidding healthcare provider's newer experience in the area of specialization. This tapering (taping) can emphasize the freshness of relevant experience that the bidding healthcare provider may have. In another example, if the bidding healthcare provider works with well-known opinion leaders in the professional domain, more weight may be applied to him or her.

In yet another example, the ranking may be based on availability of the bidding healthcare providers. In one example, the ordering may be in the order of the next immediately open appointment. In such instances, the ranking may additionally take into account the distance from the requesting user to the facility of each bidding healthcare provider.

In yet another example, the ranking may be based on security records of healthcare providers bidding within the operator's particular healthcare network. In one illustration, the safety record may include a number of post-operative complications reported to the health insurance carrier regarding the procedure performed by the healthcare provider in providing the requested service. In a similar illustration, the safety record of the bidding healthcare provider may take into account medical incident litigation for the bidding healthcare provider, particularly when such incident litigation achieves a final adjudication.

In another additional example, the ranking may be based on the number of patients treated by the bidding healthcare providers within the particular healthcare network. By way of illustration, the application may rank the bidding healthcare providers according to the number of surgeries performed by each bidder in the past (e.g., three years) in providing the requested service.

When bids are received, they may be presented to the patient, for example, in an ordered order as described above. The patient can use his or her own privileges to select bids based on the patient's needs. Prior to making the selection of a bid, the patient may request more detailed information of the healthcare provider for the particular bid. Such detailed information may include, for example, incident litigation (if any) for a particular healthcare provider; committees are committed to the discipline of a particular healthcare provider; references already provided by a particular healthcare provider; media reports of a particular healthcare provider; peer review of a particular healthcare provider. The request for more detailed information may be submitted by the patient at the patient's electronic device 130 (1260).

Fig. 13 is a flow diagram of a process 1300 for accessing and presenting electronic medical records in the context of interacting with a PSO. For convenience, the particular components described with reference to fig. 1A are referenced to perform the process 1300. However, a similar approach can be applied to other embodiments as follows: different components are used to define the structure of the system in these embodiments, or the functionality is distributed differently among the components shown in FIG. 1A in these embodiments.

The consumer electronic device 130 receives a user input requesting an electronic medical record (1310). As described with reference to fig. 3, in one example, the user 120 can supply user input to the user electronic device 130 (e.g., using a keyboard, keypad, mouse, stylus, etc.) to initiate a request for an electronic medical record. In other examples, recipient 170 may input user input to consumer electronic device 130, or consumer electronic device 130 may receive user input from, for example, recipient electronic device 180 via connection 190 or network 110.

The consumer electronic device 130 determines the desired electronic medical record based on the user input (1320). For example, the user electronic device 130 determines whether the request for a record is a request for all electronic medical records associated with the user 120 or only a subset of the electronic medical records are needed. For example, the user electronic device 130 determines whether the request is for electronic medical records related to orthopedic and muscle treatment. For example, the user electronic device 130 determines whether the request is for electronic medical records from a particular doctor and a particular hospital. For example, the consumer electronic device 130 determines whether the request is for electronic medical records within the past decade. The user 120 may impose other restrictions on the record request.

The user electronic device 130 determines the location of the desired electronic medical record (1330). For example, the consumer electronic device 130 may determine whether the consumer electronic device 130 stores the requested record locally on the consumer electronic device 130 or whether an electronic device at a remote location stores the requested record. When the requested record, or portions thereof, are stored remotely in distributed storage, the consumer electronic device 130 may determine the location of storage by the address information of each portion. As noted above with reference to fig. 3, the address information may include a URL, stub, hyperlink, or any other exemplary location direct or indirect mechanism.

After determining the location of the desired recording, the consumer electronic device 130 sends a message requesting the recording to the electronic device storing the requested recording (1340). For example, consumer electronic device 130 may send an electronic communication requesting a record to a plurality of record storage systems 140, 150, and 160 via network 110. As noted above with reference to fig. 3, the electronic communication may identify the user 120 requesting the recording, the consumer electronic device 130 requesting the recording, the recipient 170, the recipient electronic device 180 that may receive the recording, the requested recording, and/or the restrictions imposed on the recording request. In this particular illustration, the PSO may be an example recipient 170. The data server at the PSO may be an example recipient electronic device 180.

The consumer electronic device 130 receives a record sent from the electronic device storing the requested record in response to receiving the message requesting the record (1350). For example, consumer electronic device 130 may receive electronic records from multiple record storage systems 140, 150, and 160 via network 110. When the consumer electronic device 130 receives the electronic medical record, the consumer electronic device 130 may send an acknowledgement to the record storage system that sent the electronic medical record.

The user electronic device 130 performs analysis on the requested electronic medical record and determines a portion to share with the PSO (1360). In some embodiments, a healthcare provider (such as a hospital, treating physician, or pharmacist) may submit an anonymized electronic medical record of a patient to a PSO. The submission may be pursuant to a contractual agreement between the healthcare provider and the PSO. In some embodiments, the patient 120 may enter into an agreement with a healthcare provider holding the electronic medical record of the patient 120. In the above context, the consumer electronic device 130 may analyze electronic medical records received from the distributed storage. The analysis may be conducted in accordance with agreements with the healthcare provider and the PSO such that sensitive information, patient identification information, or contaminated information may be purged from the received electronic medical records. In some examples, the agreement may impose further restrictions on portions of the received electronic medical record that may be shared with, for example, the PSO.

The consumer electronic device 130 may optionally transmit the recording to the recipient electronic device 180 at the PSO (1370). The transmission may be agreed upon and only the allowable portion according to the protocol may be sent to the PSO without patient identification information. As described herein, a PSO or a set of PSOs may perform analysis on an aggregated electronic medical record. Summary information generated by the analysis may be transmitted to, for example, healthcare providers that have contributed to submitting anonymized electronic medical records.

The described systems, methods, and techniques may be implemented in digital electronic circuitry, computer hardware, firmware, software, or in combinations of these elements. An apparatus embodying these techniques may include appropriate input and output devices, a computer processor, and a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor. A process 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 can be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language (if desired); and in any 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 disc read only memory (CD-ROM). Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).

In one embodiment, the 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 load 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 the installed application. The user may retrieve the URL in order to install the proxy application. The URL may include a link configured to install a BREW ("binary runtime for wireless") or J2ME ("binary runtime for wireless") program that acts as a proxy application.

The user may contact their insurance provider, medical records provider, or healthcare provider in order to receive the procedure. Thus, a user may enter their address information (e.g., phone number or email address) on a website (or through a call center). The insurance provider may then respond with a link to the installer. The user selects the link to install the proxy application onto the wireless telephone and then enters user information (e.g., authentication and identification information) using the proxy application. Once authenticated, the record storage system may provide address information for the records of the user. The record storage system may send the secured URL to the proxy application. The proxy application may then be configured to store the URL and access the record across the URL.

When a user interacts with different record storage systems, the user may send identification information for each of the different record storage providers, such that the broker application may be configured to add address information for each of the record storage providers. For example, a user accessing a medical examination center may provide a wireless telephone number to access the test results. The medical examination center may then send a message to register the user's mobile device in the network of devices that are allowed to access records securely published by the medical examination center. Once the user has successfully completed the authentication procedure, the address information for the user's check may be added to the URL list managed by the proxy application. In one configuration, the agent application is configured to store address information for insurance and claims processing, attending and specialist physicians, and pharmacy services. By configuring the broker application on the mobile device to store address information for the 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 their physician may register with the "front desk" of the physician. The foreground may include a bluetooth (TM) transceiver configured to prompt the agent application for the user's medical records, examination results, and insurance information. The user receives a message from the agent application indicating that the physician's front desk is requesting access to the medical records, examination results, and insurance information. The user may then "accept" the prompt to instruct the agent application to access the requested record. The broker application then accesses the URL for each of the requested records from each of the record storage providers. The agent application may then present the 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 sends the recording to the physician's foreground. The front desk system can then distribute the records to the necessary physicians, nurses, and claim processing personnel. The user may then receive medical services. Depending on the communication protocol used, the mobile device may maintain communication with the foreground system (using, for example, Wi-Fi wireless LAN technology) or disconnect from the foreground system (using, for example, bluetooth (TM) technology).

As a result of the user receiving the service, and the physician updating the medical records, requesting examinations, and writing prescriptions, the healthcare provider may wish to update the user's records. The agent application may then receive the communication from the foreground system (or other system in the physician's office) and request that the information be sent to the corresponding record storage provider. The user may then confirm the prompt to allow the mobile device to receive updated medical records, examination requests, and prescriptions. The broker application on the mobile device may then retrieve the address information for each of the records and send the updated information to each of the medical storage providers. Alternatively, the foreground system may then send each of the updates to an email address associated with the user at which the updated information is processed and sent to each of the respective healthcare providers. Such a configuration may be employed where access to the information is deemed particularly sensitive and updates to the information are deemed not to be of much concern because the update system has access to the information being updated.

In one embodiment, special privileges to access record storage providers may be provided to specialized units and systems, such as emergency rooms and rescue personnel and systems. For example, in the event that a patient cannot access or interface with a mobile device to provide medical records, which may be due to the patient being unconscious or incapacitated, the mobile device may be configured to enable authorized personnel and systems to access the required records. In one configuration, the mobile device challenges the person to enter approved 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 send the MAC address of the emergency room system to a verification system (e.g., a security program operated by a record storage provider). The verification system may then determine whether the MAC address is found in the list of approved MAC addresses for the emergency room system. The mobile device may be configured to automatically verify the MAC address without intervention to relieve emergency room personnel. In yet another configuration, MAC address filtering is used in addition to requiring emergency room personnel to enter a PIN ("personal identification number") for the particular emergency room in which the patient is being cared.

In one configuration, in response to determining that emergency services personnel are accessing the medical records, the storage record provider may be configured to send a DNR ("do not rescue") message to the emergency services personnel. For example, the mobile device may be configured to generate a prominent display and/or require confirmation of the DNR condition of the patient. The record storage provider may also be configured to send voice and email messages that contact emergency service personnel using DNR status information.

The pharmacy may also be registered in a registered pharmacy list that is granted access to the patient's pharmacological record. 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 agent application may communicate with the pharmacy records provider to determine whether the dedicated printer is associated with an approved pharmacy. As a result of identifying the dedicated printer as being associated with an approved pharmacy, the dedicated printer accesses the electronic record with unfilled and/or refilled prescriptions and prints out the prescriptions. The pharmacist may then complete the prescription.

It will be understood that various modifications may be made without departing from the spirit and scope. 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 the description.

Claims (45)

1. A method for aggregating electronic medical records associated with a user using a wireless device having a medical records application, and then transmitting the aggregated electronic medical records to a device configured to use the wireless device as an aggregated electronic medical record A method of a medical provider recording system of a source of records, the method comprising: A first request for a first electronic medical record associated with the user and stored in electronic storage accessible by the first communication device is sent from the wireless device to the first communication device, the first request including the first authentication information; A second communication to a second electronic medical record associated with the user and stored in electronic storage accessible by the second communication device is sent from the wireless device to a second communication device different from the first communication device request, the second request includes second authentication information; At the wireless device, the first electronic medical record is received from the first communication device in response to the first communication device receiving the first request and authenticating the first request based on the first authentication information, the wireless device also receiving a third Authentication information, the third authentication information: 1) confirm the identity of the first communication device, and 2) confirm the credibility of the received data; At the wireless device, a second electronic medical record is received from the second communication device in response to the second communication device receiving the second request and authenticating the second request based on the second authentication information, so as to thereby register at the wireless device where the first medical record and the second medical record are aggregated, the wireless device also receives fourth authentication information that: 1) confirms the identity of the second communication device, and 2) confirms the availability of the received data reliability; establishing a secure, authenticated connection between the wireless device and the medical provider record system by receiving fifth authentication information from the medical provider record system at the wireless device; sending a first electronic medical record and a second electronic medical record from the wireless device to the medical provider records system using the secure, authenticated connection; sending, from the wireless device, to at least one medical provider record system of a plurality of medical provider record systems, a request submitted by the user for a bid to provide a specific medical service related to a specific condition; receiving, at the wireless device, a bid from at least one healthcare professional corresponding to the at least one healthcare provider record system of the plurality of healthcare provider record systems; and Ranking received bids by the medical records application based on the background experience of the respective healthcare professional, the ranking being performed by the wireless device, wherein the ranking includes giving to the at least one healthcare professional in an area of specialization The newer the professional's experience, the more weight is applied. 2. The method of claim 1, further comprising configuring the first communication device and the second communication device to reject if the first request and the second request do not include one of the first authentication information and the second authentication information The first request and the second request for sending the first electronic medical record and the second electronic medical record to the wireless device. 3. The method of claim 1, wherein at least one of the first, second, third, fourth and fifth authentication information is an electronic signature. 4. The method of claim 1, wherein at least one of the third, fourth and fifth authentication information is a digital certificate. 5. The method of claim 1, wherein at least one of the third and fourth authentication information is an electronic postmark. 6. The method of claim 1, further comprising enabling display of the assembled first electronic medical record and second electronic medical record at the medical provider record system using the secure, authenticated connection. 7. The method of claim 1, wherein the wireless device and the medical provider record system constitute separate devices, and further comprising implementing an assembled first electronic medical record and a second electronic medical record at the wireless device Display of medical records. 8. The method of claim 1, further comprising accessing filter criteria associated with a service to be provided to a user, wherein the first request and the second request include the filter criteria and received at the wireless device The first medical record and the second medical record satisfy the filter criteria. 9. The method of claim 1, wherein the step of confirming the authenticity of the received data comprises confirming that the data has not been Change. 10. The method of claim 9, wherein the step of confirming the authenticity of the received data includes using at least one of a digital certificate, an electronic postmark, a hash code, and a watermark. 11. The method of claim 1, wherein the wireless device is at least one of a server and a personal computer. 12. The method of claim 1, wherein the medical provider record system is associated with a pharmacy and at least one of the first electronic medical record and the second electronic medical record includes prescription information, when the wireless device is When placed near the pharmacy, the medical provider records system sends a request to the medical records application of the wireless device to deliver the prescription information. 13. The method of claim 12, further comprising enabling delivery and printing of the prescription information at the pharmacy upon receipt of a request to the medical records application of the wireless device to deliver the prescription information . 14. The method of claim 1, wherein establishing a secure, authenticated connection between the wireless device and the medical provider record system comprises connecting the wireless device and the medical provider record between the wireless device and the medical provider record via the Internet Establish a secure, authenticated connection between systems. 15. The method of claim 1, further comprising: determining at least one of a summary and a statistical analysis of the first electronic medical record and the second electronic medical record; and A display of at least one of a summary and a statistical analysis of the first electronic medical record and the second electronic medical record is enabled. 16. The method of claim 1, wherein each of the first electronic medical record and the second electronic medical record constitutes only a partial record, such that assembly of the first electronic medical record and the second electronic medical record provides a separate basis A complete and usable record of the partial record. 17. The method of claim 1, further comprising: receiving at the wireless device (i) a request to add an electronic medical record, and (ii) information associated with the electronic medical record to be added; and An electronic medical record including at least a portion of the information associated with the medical record to be added is generated by the wireless device based on the request to add the electronic medical record. 18. The method of claim 1, wherein the wireless device communicates through a server to make a request for an electronic medical record from a communication device. 19. The method of claim 1, wherein electronic medical records downloaded to the medical provider record system can contain usage restrictions. 20. The method of claim 19, wherein the electronic medical record expires and is no longer accessible after a period of time. 21. The method of claim 19, wherein the electronic medical record cannot be printed. 22. The method of claim 1, wherein a first electronic medical record and a second electronic medical record are transmitted from the wireless device to the plurality of medical provider record systems. 23. A method for aggregating electronic medical records associated with a user using a wireless device having a medical records application, and then transmitting the aggregated electronic medical records to a device configured to use the wireless device as an aggregated electronic medical record An apparatus for a medical provider recording system of a source of records, the apparatus comprising: means for sending, from the wireless device to a first communication device, a first request for a first electronic medical record associated with the user and stored in electronic storage accessible by the first communication device, whereby the first request includes first authentication information; for sending from the wireless device to a second communication device different from the first communication device a response to a second electronic medical record associated with the user and stored in electronic storage accessible by the second communication device A second request unit, the second request includes second authentication information; means for receiving, at the wireless device, a first electronic medical record from the first communication device in response to the first communication device receiving the first request and authenticating the first request based on the first authentication information, the wireless device further receiving third authentication information that: 1) confirms the identity of the first communication device, and 2) confirms the credibility of the received data; for receiving, at the wireless device, a second electronic medical record from the second communication device in response to the second communication device receiving the second request and authenticating the second request based on the second authentication information, for thereby receiving the second electronic medical record at the wireless device a unit at the device that aggregates the first medical record and the second medical record, the wireless device also receives fourth authentication information that 1) confirms the identity of the second communication device, and 2) confirms the received the reliability of the data; means for establishing a secure, authenticated connection between the wireless device and the medical provider record system by receiving at the wireless device fifth authentication information from the medical provider record system; means for transmitting a first electronic medical record and a second electronic medical record from the wireless device to the medical provider records system using the secure, authenticated connection; means for transmitting, from the wireless device, to at least one of a plurality of medical provider record systems, a request submitted by the user for a bid to provide a specific medical service related to a specific condition; means for receiving, at the wireless device, a bid from at least one healthcare professional corresponding to the at least one healthcare provider record system of the plurality of healthcare provider record systems; and For use by the medical records application based on the price of the particular medical service, the corresponding healthcare professional's background experience, the corresponding healthcare professional's availability, the corresponding healthcare professional's security records, and the corresponding healthcare professional's At least one of the patient numbers is a unit for ranking received bids, the ranking being performed by the wireless device. 24. A computer-readable storage medium storing computer program instructions for aggregating electronic medical records associated with a user using a wireless device having a medical records application, and then Sending the aggregated electronic medical records to a medical provider records system configured to use the wireless device as a source of the aggregated electronic medical records, the computer program instructions are executed by a processor to perform the following operations: A first request for a first electronic medical record associated with the user and stored in electronic storage accessible by the first communication device is sent from the wireless device to the first communication device, the first request including the first authentication information; A second communication to a second electronic medical record associated with the user and stored in electronic storage accessible by the second communication device is sent from the wireless device to a second communication device different from the first communication device request, the second request includes second authentication information; At the wireless device, the first electronic medical record is received from the first communication device in response to the first communication device receiving the first request and authenticating the first request based on the first authentication information, the wireless device also receiving a third Authentication information, the third authentication information: 1) confirm the identity of the first communication device, and 2) confirm the credibility of the received data; At the wireless device, a second electronic medical record is received from the second communication device in response to the second communication device receiving the second request and authenticating the second request based on the second authentication information, so as to thereby register at the wireless device where the first medical record and the second medical record are aggregated, the wireless device also receives fourth authentication information that: 1) confirms the identity of the second communication device, and 2) confirms the availability of the received data reliability; establishing a secure, authenticated connection between the wireless device and the medical provider record system by receiving fifth authentication information from the medical provider record system at the wireless device; sending a first electronic medical record and a second electronic medical record from the wireless device to the medical provider records system using the secure, authenticated connection; and sending, from the wireless device, to at least one medical provider record system of a plurality of medical provider record systems, a request submitted by the user for a bid to provide a specific medical service related to a specific condition; receiving, at the wireless device, a bid from at least one healthcare professional corresponding to the at least one healthcare provider record system of the plurality of healthcare provider record systems; and by the medical records application based on the price of the particular medical service, the corresponding health care professional's background experience, the corresponding health care professional's availability, the corresponding health care professional's safety records, and the corresponding health care professional's number of patients At least one of the ordering of the received bids is performed by the wireless device. 25. The computer-readable storage medium of claim 24, further comprising: if the first request and the second request do not include one of the first authentication information and the second authentication information, communicating the first communication device with the second The device is configured to reject the first request and the second request to send the first electronic medical record and the second electronic medical record to the wireless device. 26. The computer-readable storage medium of claim 24, wherein at least one of the first, second, third, fourth, and fifth authentication information is an electronic signature. 27. The computer-readable storage medium of claim 24, wherein at least one of the third, fourth, and fifth authentication information is a digital certificate. 28. The computer-readable storage medium of claim 24, wherein at least one of the third and fourth authentication information is an electronic postmark. 29. The computer-readable storage medium of claim 24, further comprising a first electronic medical record and a second electronic medical record that enable assembly at the medical provider record system using the secure, authenticated connection display. 30. The computer-readable storage medium of claim 24, wherein the wireless device and the medical provider record system constitute separate devices, and further comprising a first electronic medical record assembled at the wireless device and display of a second electronic medical record. 31. The computer-readable storage medium of claim 24, further comprising accessing filter criteria associated with a service to be provided to a user, wherein the first request and the second request include the filter criteria, and in the wireless The first medical record and the second medical record received at the device satisfy the filter criteria. 32. The computer-readable storage medium of claim 24, wherein the step of confirming the authenticity of the received data comprises confirming that the data was sent after the data was sent by at least one of the first communication device and the second communication device. The above data has not been changed. 33. The computer-readable storage medium of claim 32, wherein the step of confirming the authenticity of the received data includes using at least one of a digital certificate, an electronic postmark, a hash code, and a watermark. 34. The computer-readable storage medium of claim 24, wherein the wireless device is at least one of a server and a personal computer. 35. The computer-readable storage medium of claim 24, wherein the medical provider record system is associated with a pharmacy and at least one of the first electronic medical record and the second electronic medical record includes prescribing information, when all When the wireless device is placed near the pharmacy, the medical provider records system sends a request to the medical records application of the wireless device to deliver the prescription information. 36. The computer-readable storage medium of claim 35, further comprising enabling delivery and printing of all prescription information at the pharmacy upon receipt of a request to the medical records application of the wireless device to deliver the prescription information. the prescribing information. 37. The computer-readable storage medium of claim 24, wherein establishing a secure, authenticated connection between the wireless device and the medical provider record system comprises connecting between the wireless device and the medical provider via the Internet Establish a secure, authenticated connection between healthcare provider record systems. 38. The computer-readable storage medium of claim 24, further comprising: determining at least one of a summary and a statistical analysis of the first electronic medical record and the second electronic medical record; and A display of at least one of a summary and a statistical analysis of the first electronic medical record and the second electronic medical record is enabled. 39. The computer-readable storage medium of claim 24, wherein each of the first electronic medical record and the second electronic medical record constitutes only a partial record, such that the Assembling provides a complete and usable record based on separate partial records. 40. The computer-readable storage medium of claim 24, further comprising: receiving at the wireless device (i) a request to add an electronic medical record, and (ii) information associated with the electronic medical record to be added; and An electronic medical record including at least a portion of the information associated with the medical record to be added is generated by the wireless device based on the request to add the electronic medical record. 41. The computer-readable storage medium of claim 24, wherein the wireless device communicates through a server to make a request for an electronic medical record from a communication device. 42. The computer-readable storage medium of claim 24, wherein electronic medical records downloaded to the medical provider record system can contain usage restrictions. 43. The computer-readable storage medium of claim 42, wherein the electronic medical record expires and is no longer accessible after a period of time. 44. The computer-readable storage medium of claim 42, wherein the electronic medical record cannot be printed. 45. The computer-readable storage medium of claim 24, wherein a first electronic medical record and a second electronic medical record are transmitted from the wireless device to the plurality of medical provider record systems.

Images