Patent Application
20120029938
Patient privacy is a significant concern when dealing with medical matters. As medical records are converted to electronic form, the risk of compromising patients' privacy increases significantly, because the electronic format makes it easier to misuse patients' data.
At the same time, such data is accessible to many parties who do not need much, if any, of it. For example, insurers and pharmacies are not actively involved in patient care. However, patients who are insured are required to share the entire record of their medical treatment with their insurer in order to receive benefits, and those patients can only hope that the insurance company and its employees maintain the records confidentially. Similarly, a pharmacy may store data regarding patient prescriptions, such as all prescriptions filled for each patient.
In actuality, there is no medical reason for these parties to have this information. For example, an insurer only needs enough information to be able to prevent fraud and verify that the provided treatment is covered under the patient's policy. A pharmacy only needs to know that the patient has a valid prescription for the medication being dispensed.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards using cryptographic techniques (anonymous proof systems) to ensure the anonymity of health records when processing payment claims to insurers and pharmacies. In one aspect, a mechanism (e.g., at a healthcare provider) inputs a delegated patient token comprising attributes of a patient, and data of an insurer by which the insurer is able to validate another token corresponding to the patient token. The delegated token is processed into an anonymized token that identifies the healthcare provider (or pharmacy) and identifies one or more covered medical services or products for which reimbursement from the insurer is desired. The anonymized token does not include information by which the patient is directly identifiable, and may be transmitted to the insurer for payment.
In one aspect, an encrypted patient record corresponding to a medical procedure performed with respect to the patient is maintained, e.g., at a health system/service. In another aspect, anonymous data corresponding to the medical procedure performed with respect to the patient is transmitted to a data aggregator, such as for use in medical research.
For prescriptions, an anonymized token may be generated in two parts, comprising an endorsement associated with the patient (e.g., given to the patient by the healthcare provider as a printed barcode), and an unendorsed token transmitted to the pharmacy from the healthcare provider. The pharmacy combines data corresponding to the unendorsed token with data corresponding to the endorsement into an anonymous combined token, and transmits the anonymous combined token to an appropriate recipient (e.g., the insurer) for payment.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards a technology by which payment for services and/or pharmaceutical products can be achieved without the patient identity being revealed to the insurer or pharmacy. In one implementation, this may be accomplished without separate visits by the same patient being linkable to one another. Further, anonymized versions of patients' records may be uploaded to a data aggregator service, such as for purposes of medical research.
To this end, the various parties (healthcare provider, insurer, patient and pharmacy) may have identities in a public key infrastructure. As described herein, a patient sets up an insurance policy with the insurer and performs an interactive protocol with the insurer which results in the patient possessing a electronically signed proof statement (a token) indicating that the patient possesses a valid insurance policy with certain properties. This token is presented to a healthcare provider (e.g., doctor or hospital) and is used to generate anonymized, unlinkable signed authorization statements, which are presented to the insurer for payment. In a similar manner, a pharmacy receives payment from the insurer for a prescription without learning the patient's identity.
While the examples herein are directed towards typical medical scenarios, it should be understood that any of the examples herein are non-limiting, and other scenarios may benefit from the technology described herein. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used in various ways that provide benefits and advantages in computing and privacy in general.
As described herein and in general, the tokens are later used in conjunction with the healthcare provider 108 to produce anonymized tokens, which are presented back to the insurer 106 for payment for services. Note that the insurance company may need to revoke tokens, for example, if a patient/organization cancels the policy or otherwise stops paying the premium. Revocation may be done using existing anonymous credential revocation techniques, such as described in J. Camenisch and A. Lysyanskaya. “Dynamic accumulators and application to efficient revocation of anonymous credentials. Crypto '02.
In the anonymized token, the health record is not associated with this patient when shared with the insurer 106 or a pharmacy 110. Instead, when the patient 102 visits the healthcare provider 108, a private record of treatment is generated and stored in the patient's confidential health record. In one example scenario, when the patient 102 is treated by the healthcare provider 108, the healthcare provider 108 generates a record of this visit and uploads it in a secure manner to the patient's confidential personal clinical health record, such as maintained at the consumer health system 104. The patient's private record is maintained encrypted and is not viewable by the consumer health system 104 or anyone else, without explicit authorization and the appropriate secret keys.
As described below, the healthcare provider 108 submits a claim to the insurer 106 and payment is processed without the insurer 106 learning for which patient the payment is being made.
In another typical scenario, if the healthcare provider 108 prescribes medication for the patient, the healthcare provider 108 transmits a token (or partial token as described below) containing relevant information to the pharmacy 110. This token does not include information by which the patient is identifiable, but does comprise a signed authorization statement (possibly including state-provided data) indicating that the provider (doctor) is authorized by the state to prescribe medication for the patient. The transmission may be by email, uploading the token to a certain site, and so forth.
As also described below, the healthcare provider 108 additionally generates a digitally signed prescription token (e.g., in the form of a printed barcode) for the patient to take to the pharmacy 110 to pick up the prescription. Note that a physical printout is not necessarily provided, as for example, a barcode may be downloaded to the patient's cell phone or other such device where it can be scanned at the pharmacy.
In this way, the healthcare provider 108 may act as the trusted representative of the patient 102 in the transactions with insurer 106 and pharmacy 110. More particularly, the healthcare provider 108 interacts with the pharmacy 110 to and bills the insurer 106 on behalf of the patient 102 using tokens in an anonymized, delegatable, and unlinkable credentialing system. As described below, safeguards may be used ensure that such tokens are not abused (e.g., passed on to others for multiple use).
Step 204 represents the patient visiting the doctor/hospital, which accepts tokens representing a valid insurance policy. The patient reveals the relevant part of the policy, and gives the healthcare provider a token for this visit, which is processed into an anonymized token. As described below, some interaction between the doctor and patient may be required to generate the anonymized token that is presented to the insurer for that visit. In one implementation, the doctor/hospital is assumed to be fully trusted by the patient with regard to any record or data generated by that visit.
Step 206 represents the doctor/hospital encrypting the patient's record for that visit and uploading the record to the consumer health system. The doctor/hospital optionally also may upload an anonymized version of patient's visit/health record to the data aggregator system (step 208).
At step 210, doctor/hospital bills the insurer using a valid, anonymized, unlinkable token. The doctor may check (possibly before treatment) that the insurance claim is valid under the patient's policy, and sends the anonymized token to the insurance company, which includes a description of the services provided. The insurance company checks this token and reimburses the claim; that is, the doctor/hospital receives payment after the insurer checks the validity of the token. Note that before performing any procedure on the patient, the doctor/hospital may have a mechanism to check that the token is valid for the desired procedure, at least in part (with the patient responsible for any difference).
Steps 212 and 214 represent various doctor/patient/pharmacy operations. In general, at step 212, the doctor prescribes one or more medications for the patient. This information is included in the patient's record for that visit. Note that once the information is stored electronically, drug-interaction errors may be caught automatically, whereby pharmacies do not need to play as large a role in this process. To communicate the prescription to the pharmacy, the doctor/hospital uses credentials issued by the state that prove the right to prescribe, and generates a signed prescription which is tied to the particular patient via an anonymous token showing that the insurance will cover the medication. The information given to the pharmacy thus includes the prescription details and one or more tokens that the pharmacy can use to present to the insurer for payment/verification of insurance coverage.
As represented by step 214, instead of writing a hand-signed prescription, the doctor may print or otherwise generate a token (e.g., a partial token) comprising a digitally signed prescription to give to the patient to take to the pharmacy (which may be in the form of a barcode). The patient then goes the corresponding pharmacy, which verifies the tokens received from the patient and the doctor before dispensing the appropriate medication. For reimbursement, as proof of the claim that the medical product was indeed received by the patient, the pharmacy combines the token from the doctor and the token from the patient and presents the result to the insurance company, which verifies the proof and reimburses the claim.
In this manner, payment for services and medical products may be achieved without the patient identity being revealed to the insurer or pharmacist, and without separate visits by the same patient being linkable. This is because the anonymous credential system allows users to obtain credentials from an organization, and then access a resource/service while generating tokens proving that they hold the necessary credentials. These tokens are anonymous in that they do not reveal any information about the patient, they cannot be linked back to the initial issuance, and it is not possible to tell whether two tokens were generated using the same credential.
Turning to various aspects of tokens in one implementation, as represented in
A patient with a credential/token 320 can issue a delegated token 322 to another party, that is, to the healthcare provider 108. The patient 102 can also choose which of its attributes are included in the delegated token 322, e.g., via a token editor 324 (e.g., a software program) that allows certain attributes to be modified. With the delegated token 322, the healthcare provider 108 is able to prove ownership of a credential that was issued by someone with a valid credential from the organization (without revealing information on this intermediary user).
Thus, in one implementation, the token 320 for a patient 102 may comprise a simple credential including the attributes of the policy, assuming that policies have a standardized form. The token for the healthcare provider 108 may comprise the delegated token 322, such as with the visit date hardcoded. Via the token editor 324, the patient may choose to remove some field if it is unrelated to the treatment being performed. For example, dental credentials may be removed on a visit to the patient's primary care doctor. Alternatively, the patient may be more involved in the process, such as to need to authorize every treatment being claimed.
With respect to the anonymous token 326 for the insurer 106, the healthcare provider 108 uses the delegated token 322 to generate a proof (via an anonymous token generator 328, e.g., a software program) that the procedure and/or services claimed are indeed covered. Note that the patient 102 may work with the healthcare provider 108 in the generation of the anonymous token 326. Payment 330 is then sent to the healthcare provider 108 as described above.
In some cases it is important to ensure that no credential is used more than once in the same setting. In this case the patient 102 provides a single-use token for each setting. If the patient 102 generates two or more tokens for the same setting, these may be easily detected, however as long as each use is in a different setting, there is no way to tell that multiple tokens were generated by the same patient 102. Thus, the anonymous token 326 may be combined with a single use label for that patient and that date, which prevents multiple claims for the same procedure.
If the insurers policies are more complex, other features (achievable with existing techniques) may be provided via data in the token. For example, there may be time gaps needed between certain procedures, such as only one rehabilitation procedure per week, which may be included as data in the token. Other features of an insurance company's token may be directed towards proving that a preceding procedure has already been reimbursed, proving that the patient's lifetime or annual cap has not been exceeded, proof of signed results from labs for this patient, and so forth.
For the pharmacy 110, when the doctor 408 is given a delegated token 422, in one implementation the doctor 408 generates (via an endorsed delegated token generator 428, such as a software program) an endorsed delegated token 440 with whatever information is needed to verify the claim. This is basically an endorsed version of the anonymized token for the insurer 108, which reveals only that the prescribing doctor is certified. The unendorsed token (portion) 441 is transmitted or otherwise sent to the pharmacy, with the endorsement 442 printed or otherwise electronically generated in some way (e.g., as a one or two dimensional barcode) and associated with (e.g., given to) the patient 102. As described above, the patient 102 or patient's representative provides the pharmacy 110 with the endorsement 442, which then recombines and anonymizes (e.g., via an anonymous token combiner/generator software program 428) the endorsement 442 with the unendorsed token 441 into an anonymous combined token 426, which is provided to the insurer 106 for payment 430.
Turning to another aspect, there may be situations where revocation of anonymity/allowing auditing is needed. There is thus provided a way to retrieve the treatment information and identity for each patient, such as in case of an audit. One option is to have one (or several) trusted parties who hold a decryption key or shares of a decryption key. When a token is formed to be sent to the insurance company, the doctor can also include data encrypted under this key, comprising treatment information (as well as his or her signature on this information). If an audit is needed, the insurer can ask the trusted parties to perform the decryption. If fraud is discovered, the doctor can then be held responsible.
With respect to preventing the sharing of tokens, an insurer will not want a patient to share a policy with others (other than co-insured family members, for example). One solution is to assume that the parties (including the patients) have verifiable identities in a public key infrastructure. Another, weaker, solution is to require that a patient share all of his or her rights in order to allow someone else to use his policy. Yet another solution is to include the patient name in the policy token that is issued, and in the delegated token the patient shows to the doctor (but not in the anonymized tokens); then the doctor is responsible for verifying the patient's identity.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 510 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 510 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 510. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above may also be included within the scope of computer-readable media.
The system memory 530 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 531 and random access memory (RAM) 532. A basic input/output system 533 (BIOS), containing the basic routines that help to transfer information between elements within computer 510, such as during start-up, is typically stored in ROM 531. RAM 532 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 520. By way of example, and not limitation,
The computer 510 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 510 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 580. The remote computer 580 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 510, although only a memory storage device 581 has been illustrated in
When used in a LAN networking environment, the computer 510 is connected to the LAN 571 through a network interface or adapter 570. When used in a WAN networking environment, the computer 510 typically includes a modem 572 or other means for establishing communications over the WAN 573, such as the Internet. The modem 572, which may be internal or external, may be connected to the system bus 521 via the user input interface 560 or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer 510, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
An auxiliary subsystem 599 (e.g., for auxiliary display of content) may be connected via the user interface 560 to allow data such as program content, system status and event notifications to be provided to the user, even if the main portions of the computer system are in a low power state. The auxiliary subsystem 599 may be connected to the modem 572 and/or network interface 570 to allow communication between these systems while the main processing unit 520 is in a low power state.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
