WO2001098866A2

WO2001098866A2 - Method and apparatus for requesting and retrieving medical information

Info

Publication number: WO2001098866A2
Application number: PCT/US2001/019565
Authority: WO
Inventors: Richard S. Dick
Original assignee: Nex2, Llc
Priority date: 2000-06-19
Filing date: 2001-06-19
Publication date: 2001-12-27
Also published as: WO2001098866A3; AU2001268567A1

Abstract

The present invention relates to a method of searching for medical information. The method of searching may be executed by one or more computers and comprises the steps of receiving a request for medical information (245) including identification of a subject; transmitting a query (245) to a medical information repository (275) for information pursuant to the request and receiving a response to the query (245). The response to the request including information based on the response to the query may be further transmitted after being received.

Description

METHOD AN APPARATUS FOR REQUESTING AND RETRIEVING MEDICAL INFORMATION

1. FIELD OF THE INVENTION The invention relates generally to electronic access of medical information and more specifically to electronic access of medication, pharmaceutical, and clinical information.

BACKGROUND OF THE INVENTION COMMON USES FOR MEDICAL INFORMATION

Common uses for medical information include physician reference and diagnosis, medical research, medical training, insurance policy underwriting and claims adjusting. Many fields of insurance (e.g., life, health, disability income, long term care, property, casualty, and reinsurance) routinely require medical information for analysis. Such analyses ofmedical information typically include reviewing attendingphysician's statements ("APS") and other medical records. An APS is usually considered to be the most reliable record as it contains analyses and conclusions by a licensed medical professional. Medical records may be used to help determine the risk presented by an insurance applicant. Medical records can also help determine causation and other issues relevant to claims adjusting. STATUS OF MEDICAL INFORMATION

Medical records, including APSs, are generally available, but are not easily accessible. Because such records are highly sensitive, they are protected by ethics and by law requiring patient consent prior to disclosure. APSs and other medical records are typically restricted to paper documentation located in patient record rooms of physicians and other medical providers. To avoid filling office and patient space with voluminous paper records, some medical providers are gradually migrating to computerized patient records systems ("CPRS"). Likewise, the number of providers employing retrospective conversion systems ("RCS") to convert paper records to computerized images or computer readable records is gradually increasing. However, like their paper counterparts, CPRS and RCS records most often remain isolated from external sources.

DIFFICULTIES CAUSED BY THE STATUS OF MEDICAL INFORMATION It may take several weeks to receive a medical record after it is requested from a medical information repository such as a physician's office. The delay is due to the paper- only format of the records and the low priority assigned to) such requests by medical providers. Since APSs and other medical records are generally restricted to paper, personnel time is required to locate, copy, and fax or mail copies to a requestor; consequently requesters are charged an administrative fee for this service. The lengthy delay causes a multitude of problems for requesters. For example, a delay in obtaining medical records for use in underwriting insurance policies may cause applicants to lose interest, with a consequent loss of business to the insurer.

In an effort to shorten delays, some requesters utilize agents to travel to and manually retrieve medical records from medical providers. Although this may partially resolve the delay problem at significant expense, it does not address the problem of not knowing whether the retrieved record is complete, whether other records exist, or where more complete or other records may be located. This is a persistent problem with physician-based records and clinical records. Further, even when the existence and location of a record are known, its relevance remains uncertain until retrieved and reviewed. Because of the significant cost of manual retrieval, this is a substantial problem.

Just as insurance companies lack access to the medical records they need, health care providers and emergency medical technicians also have a need for access to medical records regarding patients which presently goes unmet. Health care providers and emergency medical technicians are sometimes required to make decisions regarding how to care for a patient under circumstances in which paper records such as physician-based records are not available. Prior art systems for obtaining and utilizing information from a patient's medical records fail to provide information that may be helpful or in some cases crucial for proper care of the patient. The prior art systems' shortcomings in this area increase the risk of improper treatment for the patient and increase the likelihood of malpractice by the healthcare providers and emergency medical technicians.

The medical and health care records of an individual are highly personal documents often containing private, sensitive information. The release of medical information for commercial use is strictly regulated by state and federal law. Thus medical records are becoming more generally available in electronic form, but electronic signatures authorizing their release to others are not today easily accessible. Because such records are highly sensitive, the records are protected by laws requiring patient consent prior to release or disclosure to others.

Even with the advantages of the electronic medical records systems which allow medical records to be stored and transferred electronically, in many instances the laws still require that a request for a person's medical records to be accompanied by a signed authorization or consent from the patient/person/guardian to release the medical information. This presents a significant problem for those attempting to obtain such records manually or electronically. In order to use abide by legal and ethical requirements, present methods and systems for obtaining medical records rely on facsimile transmission of consent forms. Parties requesting medical information must transmit facsimile copies of signed release forms to the medical record keeper, which the record keep then receives and files. This greatly slows an otherwise efficient process and requires the transmittal and storage of paper documents. What is additionally needed is a method and system allowing a person to execute a consent to release medical records that is legally effective and can be transmitted and stored electronically. It would also be advantageous to provide such a method and system in a way that reduces the likelihood of fraud in obtaining the release of the records.

The present invention is directed to overcoming, or at least mitigating, one or more of the problems set forth above.

SUMMARY OF THE INVENTION Due to the present lack of electronically stored medical records which necessitates manual retrieval of paper records at high costs, in addition to other benefits which will be obvious to one skilled in the art, a novel method of accessing computer based medical records, generally, and surrogate information, in the form of electronically stored medication records, specifically, is disclosed. Similarly, a novel apparatus is disclosed.

An illustrative method in accordance with the present invention is disclosed, a method of searching for medical information executed by one or more computers comprising: receiving a request for medical information including identification of a subject and a signed information release form; transmitting a query to a medical information repository for information pursuant to the request; and receiving a response to the query containing medical information.

Accessing medication information as a surrogate solves or reduces the effects of cited problems in accessing more complete medical records and also provides additional benefits. For instance, instead of waiting several weeks to obtain information, medication information can be retrieved in near real-time since most pharmacy benefit managers ("PBM"s), healthcare plan systems ("HPS"s) and retail pharmacies ("RP"s) maintain electronic records. Further, PBMs, HPSs, and RPs are not overburdened by requests for information because computers handle requests for information. Next, since access is electronic, information requesters do not have to incur traditional fees for agents to travel to and retrieve the information. Also, because medication is usually prescribed for serious health problems relevant to insurance policy underwriting and claims handling, medication information can help focus the search for more complete and relevant medical records.

The present invention further entails methods and apparatus for obtaining electronic access to patient medical records. The system works most efficiently when a healthcare facility is utilizing a computer information system (CIS) for creating, managing and/or storing computerized patient records or electronic medical records, but the system can work advantageously with virtually any type of digitized medical record. The preferred embodiment of the system and method comprise a request facilitator which receives requests for medical records from a requestor such as an insurance company, physician, etc. and forwards the request through a CIS vendor or service provider to the appropriate healthcare facility or physician. As used herein, the term "healthcare facility" refers to any office, building or location, physical or electronic, where healthcare related services are rendered, including but not limited to clinics, hospitals, pharmacies, laboratories, healthcare providers and other medical information repositories.

The CIS vendor or service provider sends a prompt to the healthcare provider to inquire as to whether the records can be released. For purposes of this application, a healthcare provider can be any person or organization that renders healthcare related services, including but not limited to clinics hospitals, pharmacies and labs. Having received the request to release the records and after having verified authorization to do so, the healthcare provider manually or automatically releases the records, forwarding them to the facilitator. The records are then forwarded to the requestor.

The method may also include the steps of searching the medical information repository for information regarding a patient or healthcare provider. More complex methods also include payment schemes for remuneration of healthcare facilities or CIS providers. The step of transmitting may also include transmission to a request facilitator facility for normalization to a preselected format or other processing prior to responding to the requestor.

Some benefits of the present invention include a reduction in response time to requests, information in a preselected format for ease of analysis and when encryption systems are utilized, better security than faxing the information.

Further, a healthcare facility is not overburdened by requests for information because computers handle the requests. Since access is electronic, information requesters do not have to incur traditional fees for agents to travel and retrieve the information.

The retrieved information is more inclusive since a computer can search for every instance of an identifier in an entire healthcare facility or several healthcare facilities' records. Other information such as physician or DEA numbers are also searchable so that a or healthcare provider can be contacted directly or traced if the or healthcare provider has moved. As more CISs are installed and standardization occurs, more extensive searching will become available. It is anticipated that all patient records at multiple locations, including APSs, PBMs, and unrelated records will be searchable from one location with one request. The widespread use of the present invention may additionally facilitate a standardized communication conduit for all healthcare providers, creating a more interactive healthcare practice. Healthcare facilities and providers, clinics, hospitals, pharmacies, laboratories and medical information repositories can share and exchange information to improve the quality and efficiency of healthcare services . Such information can be electronically transmitted and received to and from a healthcare facility or a healthcare provider's electronic portable or hand held device.

Using the present invention, lab results, prescriptions, diagnosis, treatments, and coverage information could all be made available electronically in a standardized format and transmitted securely to authorized parties or stored in a secure database. The present invention makes possible standardized electronic and online practice protocol, greatly enhancing such practices. Using the information made available by the present invention, electronic and online prescriptions, for example, are safer, more accurate and more economical, as doctors, pharmacies and benefit managers have access to needed information. While one embodiment illustrates a facilitator at a location remote from the requestor, this invention also anticipates the searching software being located directly on requestor computers or being accessible thereby.

In order to further facilitate the secure, prompt exchange of valuable medical information electronically, in at least one embodiment, the present invention provides for the use of digital signature technology to fulfill the legal requirement for signed authorization for the release of medical information. Digital signatures allow authenticated and legally binding documents to be generated, distributed and signed electronically. The use of digital signatures allows the entire medical record request process to be accomplished electronically and in many cases will allow the entire information gathering process to be transacted online and nearly instantaneously. In order to more fully authenticate the person's authorization for a transaction, biometric authentication is integrated into the digital signature process to reduce the chances of information being obtained by a forged or fraudulent digital release form.

Thus, in order to transmit requested medical information, a first computer receives a request for medical information including identification of a subj ect and a digitally signed information release form. The identity of the person authenticating the release form is confirmed using biometric identification and authentication. The first computer transmits the query and the digitally signed release form to a second computer at a medical information repository. Alternatively, the computer could send the request to athirdparty acting in behalf of the patient to retrieve their records stored at a medical information repository for information pursuant to the request. The first computer then receives a response to the query containing medical information. The digital signature and biometric identification may be confirmed as authentic by both the party receiving the request or by another third party.

Where a health care provider has and maintains medical records of an individual and the individual requests copies of those records for use by the individual or a third party, by law the health care provider is required to deliver copies of the requested records to the individual or third party. The health care provider is also required to retain a copy of which records were delivered and to whom. Thus, using the method of the present invention, the process of requesting and delivering such documents is greatly facilitated, as is the subsequent storage of the request and response. In at least one embodiment, the method of the present invention uses digital signature and digital certification, to expedite the records retrieval process and to comply with the associated legal requirements. However, it has been reported that digital signatures have in some circumstances been misappropriated and used to commit fraudulent transactions. Having immediate access online to medical information such as prescription history and medical records (made possible by the use of the novel method) raises potential risks if the consent for release of the information cannot be verified as authentic.

The present invention employs biometric authentication in combination with digital certificates and digital signatures to greatly increase the security of the system and to help prevent unauthorized requests for access. Certain biological traits, such as the unique characteristics of each person' s fingerprint, iris scans, and facial features have been measured and compared and found to be unique or substantially unique for each person. These traits are referred to as biometrics. The computer and electronics industry is developing identification and authentication means that measure and compare certain biometrics with the intention of using them as biological "keys" or "passwords." Other means for securing the system could be employed in addition to those disclosed above.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other features of the present invention will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are, therefore, not to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

Figure 1 illustrates a flowchart of a preferred embodiment in accordance with the present invention; Figure 2 illustrates a flowchart of another embodiment of the present invention; Figure 3 illustrates several preferred physical environments in which the method of the preferred embodiment may be carried out;

Figure 4 illustrates a flowchart of a presently preferred embodiment in accordance with the present invention utilizing a remote facilitator/normalizer; Figure 5 illustrates a flowchart of another embodiment of the present invention utilizing direct communication between the CIS provider and the requestor for returning patient record repeats;

Figure 6 illustrates a flowchart of another embodiment utilizing a direct connection between the CIS and the requestor for both requests and return information; Figure 7 illustrates a flowchart of another embodiment showing direct connection between the requestor and the medical record source;

Figure 8 illustrates a flowchart of an embodiment in which software is loaded at both the requestor and destination sites to accomplish transmittal of requests and responses; Figure 9 illustrates a flowchart of an embodiment in which facilitating software is loaded at the facilitator's server, the vendor's server and the healthcare facility's server; and

Figure 10 illustrates a flowchart of an embodiment in which facilitating software is loaded at the facilitator's server and the vendor's server. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Illustrative embodiments of the invention are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort, even if complex and time-consuming, would be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

Figure 1 shows a flowchart of a preferred embodiment, in accordance with the present invention. Medical Information 100 encompasses all information relating to physical and mental health diagnoses and remedies such as physician-patient records, clinical information records and prescription drug records. Clinical information includes laboratory testing, ambulatory, home health, and long-term care among other sources of clinical care and information. The illustrative method in Figure 1 includes receiving a request for medical information including identification of a subject and a signed information release form 105; transmitting a query to a medical information repository for information pursuant to the request 115; and transmitting a response to the request for medical information, including information based on the response to the query 125. A variation of the method and system described in Figure 1 includes the additional steps of verifying the request 110 and receiving a response to the query containing medical information 120. In aid of further description, the illustrative method in Figure 1 will be described according to the several physical environments shown in Figure 3.

Figure 3 illustrates several preferred physical environments in which the preferred method 100 is carried out in search of medical information. Specifically, three front-end physical environments are shown, a client-server environment 200, an intranet-based environment 205, and an internet-based environment 210. Each front-end physical environment includes one or more requesting and viewing clients ("RVC's), respectively, client-server-based 215, intranet-based 220, and internet-based 225. An RVC is typically a terminal having at least a video display and keyboard. In general, each RVC is operated by an authorized user to request and subsequently review retrieved medical information or other search results. In light of the sensitive nature of medical information, security is of utmost importance. A variety of security measures could be employed to ensure that only authorized users obtain access. Each RVC operates to receive a request for medical information according to its configuration. Generally, each RVC will receive such a request via an authorized user's responses to prompts generated by executing software displayed on the RVC video display. More specifically, a client-server RVC 215 would receive a request from an authorized user responding to prompts from software executing on requestor's server 230 or on RVC 215. An intranet-based RVC 220 would receive a request from an authorized user responding to prompts from software executed by RVC 220. An internet-based RVC 225 would receive a request from an authorized user responding to prompts from internet browser software executed by RVC 225 wherein the browser software is executing instructions received by an internet website accessed through the browser software. In each of the three physical environments shown, RVCs are protected by at least one firewall 235 to deter unauthorized access. In the case of the client-server RVC 215, three firewall layers are shown in Fig.2, double firewall 240 in combination with firewall 235. An RVC is part of a network, wherein network is broadly defined to encompass any configuration of operably connected computers, including wired or wireless connectivity over an intranet, the internet, modems, phone lines, satellites, wireless transmitters and receivers, optical lines, firewalls, servers, relays, bridges, repeaters, etc.

Each request for medical information includes identification of a subject and, where required by law, a signed information release form. A subject might consist of a human individual or group of humans. The subject is the target of the search for medical information. The identification of the subject could be by way of name, patient number, social security number, driver's license number, address, phone number, biometric identification or any other identification or combination of identification characteristics capable of being correlated with stored medical information, if it exists.

The request may originate with any party desiring the medical information. The request may originate with insurance agencies, health care providers and professionals, and emergency medical technicians. In some embodiments of the present invention, the request originates with a medical information repository (MIR) itself. The request may be received directly by the MIR via an RVC controlled by the MIR or may be received by an RVC that then routes the request to the MIR. The term medical information repository includes but is not limited to pharmacy benefit managers ("PBM"s), pharmacies, and any other medical information repository such as a physician's office or clinical laboratory.

In some cases, consent of the subject(s) is required to obtain the medical information. In one embodiment of the present invention, a signed information release form is typically documentation of the subject's consent, or their legal representative's consent, to the disclosure of medical information. Such documentation can be in image or machine-readable format. The release form could become part of the request by a procedure that includes scanning in a signed paper-based release form, possibly modified by character recognition software, followed by pointing to the electronic location of the scanned release form in response to a prompt from requesting software displayed on an RVC. The necessity of scanning is eliminated if the subj ect or their authorized representative electronically signs an information release form. In some situations the requestor may electronically certify their possession of a signed information release. In other instances, where the law does not require a release, none is obtained.

Once a request is received by an RVC, the request is transmitted to and received by a central server 245. A central server may consist of multiple computers performing specific tasks or executing independent processes. When central server 245 receives a request for medical information 105, it may optionally verify the request 110 before it sends a response to the request 125. Request verification 110 can take many forms, but most likely will be driven by the satisfaction of legal and security requirements. Verification is communicated to the request handling software executing on the central server 245. An example of request verification 110 includes electronic verification of an electronic watermark or digital certificate submitted with the request. A further example includes verification of the user identified as originating the request for information. However, if the RVC is an automatic requesting system without a user per se, the security focus would be on source recognition, for instance a recognized account code, a request authorization code assigned by software, a hardware address, or the like.

Following receipt of the request for information 105, the Central Server 245 will transmit a query to a medical information repository 275 for information pursuant to the request 115. The query may or may not include a copy of the signed information release form depending on the procedure in place at the medical information repository. As explained above, a medical information repository includes pharmacy benefit managers ("PBM"s), pharmacies, and any other medical information repository such as a physician's office or clinical laboratory. PBMs are companies contracted by health insurers and self- insured employers to manage prescription drug programs. The path of the transmitted query 115 to the medical information repository may include one or more firewalls, 250 and 260, as depicted in Fig. 2. Firewall 250 prevents unauthorized access to the central server 245. The particular method of communication is unimportant as long as information security measures are taken. The most common forms of communication are depicted in Fig. 2 as leased line or internet 255. hi addition, an Archive Medical Information System (AMIS) server 265 may be accessed by the central server 245. AMIS server 265 will receive the transmitted query 115 and proceed to search the AMIS database for information in satisfaction of the query. To prevent unauthorized access, firewalls 250 and 260 protect the AMIS server.

A Universal Master Person Index (UMPI) may exist at the central servers 245 and will consist of a set of demographics and other specific information for identifying an individual, including pointers to other remote systems which may have relevant information about that individual. Similarly, an L-MPI (local MPI) may reside on the AMIS 265 and this will contain demographic and other specific information for the identification of the individual whose medication information resides on that particular AMIS 265. The purpose in both instances of the Master Person Index (MPI) is to enable the identification of an individual for whom a request is being made and to increase the speed and efficiency of retrieval.

There are several benefits to utilizing an AMIS server 265. The AMIS server 265 removes the computing burden from medical information repositories such as MIR 275 by processing requests for information. The AMIS server 265 also allows for system maintenance and upgrades without disrupting medical information repository systems. The AMIS server 265 can also be used to archive medical information for longer periods of time than may be established for MIR 275. The period of archival in the AMIS server 265 could be any length of time. The AMIS server 265 may be associated with one or more MIRs and may be networked with the MIR to receive data directly from the MIR or may be wholly removed from the MIR, receiving data indirectly.

When AMIS server 265 has completed information searches responsive to the query from central server 245, AMIS server 265 will transmit a response to central server 245 conveying the results of the search(es) made pursuant to the query/queries sent by central server 245. Central server 245 will thus receive one or more responses to its one or more queries 120. Following receipt of a response to its query 120, central server 245 will return a response to the request 125.

When central server 245 receives the response to its query 120, it will prepare a response to the request received 105 from an RVC . If more than one query was made, central server 245 will compile the responses to the queries prior to returning the response to the request 125. The response to the request will be based, at least in part, on information contained in the response to the query 120. Depending on the results of the search, the response to the request 125 may even convey no results if that is conveyed in the response to the query 120. Similarly, messages similar to "information repository unavailable" may be required from time to time.

The information requested from the various medical information repositories maybe stored in formats that are generic, incompatible or in some way undesirable . When information relative to request is located by the search, the information may be advantageously compiled and reformatted. The AIMS server or the central server may operate to reformat and/or compile the responses received, before the response is ultimately transmitted to the intended receiver. The response may be advantageously reformatted in a several ways. For example, the information maybe reformatted to facilitate transmission, to safeguard confidentiality, or to make the information more user friendly. Alternatively, if the various medical information repositories store medical information in formats that are incompatible or undesirable, the repositories themselves maybe advantageously reformatted. The information received could also be advantageously reformatted by the RVC or by the intended recipient. Once properly formatted, the response to the request maybe sent directly to the intended recipient from the MIR or AIMS. Alternatively the response may be transmitted to the intended recipient through the RVC. Central server 245 may provide several additional value added functions to the response(s) to queries prior to transmitting a response to the request 125. These value added functions include but are not limited to reformatting, searching for and appending names, addresses, phone numbers, fax numbers of physicians or pharmacists referred to in the medical information, and providing interpretive information. For example, medication information contained in the response may provide useful insights into the existence, location and importance of other medical records. Since medication information typically includes information about the physician prescribing medication by name and address or unique identifier, the probable location of medical information such as physician-based records may be determined from the medication information. Further, since the medication information typically includes the type of medication prescribed, the necessity of retrieving certain underlying physician-based records may be eliminated by review of the medication information.

In light of the complete computerization of the preferred embodiment, no human-induced delays are encountered. Thus, retrieval of medical information occurs in near real-time as opposed to the usual several week delay in obtaining physician-based records, clinical records, and other paper-based medical records. Because of the speedy retrieval of medical information and the elimination of the need to review irrelevant medical information, requestors such as insurance companies will not incur unnecessary expenses.

Additional benefits provided by a method implemented in accordance with the present invention, aside from overcoming the difficulties associated with the prior art, include: increased confidence in risk assessment through underwriting because medication information includes information about underlying physician-based records which otherwise maybe unknown; more refined and cost effective risk analysis for smaller polices for which no extensive medical underwriting is typically performed; benefits for physicians and especially emergency care physicians for purposes of diagnosis; increased revenue for life insurance companies who lose business due to long delays in retrieving medical records; increased revenue for health insurance companies by eliminating duplicative testing via locating and utilizing recent test results in lieu of newly ordered tests; prompt retrieval of medical information relevant to mental and physical health analyses for legal and mental health fields; prompt retrieval of information for individuals concerned about the contents of their medical records.

In another embodiment, similar to the use of medication information as a surrogate for physician-patient records, clinical laboratory information such as blood and tissue testing and x-ray results may be utilized as a surrogate for physician-based records such as APSs. Clinical information similarly records tests ordered, results obtained, and the requesting physician. Thus, the foregoing description of the preferred embodiment with respect to medication information applies equally to clinical information.

In hindsight, it will be recognized by those of ordinary skill having the benefit of this disclosure, that information other than medication and clinical information can be used as a surrogate for physician-based records such as APSs. It is therefore evident that the particular embodiments may be altered or modified and all such variations are considered within the scope and spirit of the invention. PROGRAM STORAGE DEVICE It will be apparent to those of ordinary skill having the benefit of this disclosure that any of the foregoing variations may be implemented by programming one or more suitable general- purpose computers having appropriate hardware. The programming may be accomplished through the use of a program storage device readable by the computer and encoding a program of instructions executable by the computer for performing the operations described above. The program storage device may take the form of, e.g., one or more floppy disks; a CD ROM or other optical disk; a magnetic tape; a read-only memory chip (ROM); and other forms of the kind well-known in the art or subsequently developed. The program of instructions maybe "object code," i.e., in binary form that is executable more-or-less directly by the computer; in "source code" that requires compilation or interpretation before execution; or in some intermediate form such as partially compiled code. The precise forms of the program storage device and of the encoding of instructions are immaterial here.

The particular embodiments disclosed above are illustrative only, as the invention maybe modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of preferred environments or preferred embodiments herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments may be altered or modified and all such variations are considered within the scope and spirit of the invention. Accordingly, the protection sought herein is as set forth in the claims below.

Figure 4 illustrates a flowchart of a preferred embodiment, in accordance with the present invention. A requestor 10 can be an insurance company, a physician with a new patient, or any other individual or institution which desires to have medical information regarding an individual or a group of individuals. Requestor 10 places a record request with a facilitator 12. Facilitator 12 verifies that there is a patient record waiver included with the request, determines the best sources for the requested information, and formulates a record query. The record query includes the patient waiver if the records are requested from a source which requires the waiver. It will be appreciated that the facilitator may determine that some information is available from non-confidential sources or sources which have a lower level of confidentiality not requiring a patient waiver. In the method illustrated in Figure 4, the facilitator has determined that the record query should be sent to a computer information system (CIS) 14. In an effort to provide increased searchability and to reduce the amount of effort required to search patient records, as well as a desire to increase the inclusivity of information regarding a particular patient, many healthcare providers in healthcare facilities have retained the services of a computer information system expert to electronically manage computerized patient records. The services may be provided by the vendor of the facility's CIS or some other computer information system manager. For purposes of this application the terms "CIS manager" and "CIS vendor" may be used interchangeably. A CIS manager may transfer information from paper records over to a digital format which allows for searching. Because storage of this information may require expensive servers and additional space, and to increase the ease of maintenance, these records may be stored at a CIS which is remote from the healthcare facility or physician's office. Some CISs are maintained on site with imbedded central server software allowing access to the data by the CISs manager. When the record query reaches CIS 14 a search is made of the records stored on the server, and the patient records are located. Included in the patient information is the name and DEA number of the physician and the physician's location. The physician is then contacted by the CIS manager indicating that a record query has been placed and requesting the physician's authorization to forward the patient record to the requestor. A copy of the patient's records may also be forwarded. After the physician has reviewed the record query and accompanying patient records, a physician authorizes the release of those records and the records are forwarded from the CIS 14 back to the facilitator 12.

It will be appreciated that the amount of time required by the physician and his staff in approving release of records is greatly reduced because no search time is expended by the physician nor his or her staff since the records are provided directly by the CIS to the physician. The physician can quickly review the records and provide electronic authorization to release the records. hi addition to the cost effectiveness of the system, the CIS is also more reliable in providing all of the appropriate records. Because no physical records are handled, the files are not misplaced nor any of their contents lost. This results in a better and more thorough review by the physician of the records, and a better report being sent back to facilitator 12.

When the patient record report is received by facilitator 12, the patient record report will be in the format provided by the CIS . Since these systems vary, the information may not be in a format readable by, or desired by, the requestor. The records can be transmitted in a standard machine readable format or, in one embodiment, facilitator 12 has on record the preferred format of requestor 10 and may normalize the patient record report into the appropriate format if needed. The normalization of this information occurs in a normalization engine 16. After normalization, or if the information does not require normalization, the patient record report is forwarded from facilitator 12 to requestor 10. Because all of the process occurs electronically, the amount of time between the placing of the record request and the return of the patient record report is greatly reduced. If the physician authorizes the request for the information in a timely manner, the patient record report may be returned to the requestor in the same day that the record request was made. If the physician preauthorizes the release of the information, the patient record report may be forwarded to the requestor 10 in minutes.

This is especially valuable when the patient record report leads the requestor to understand that other sources of information will be required or that other sources of information are available. For example, if the patient record report indicates that the patient has a disease requiring medication, requestor 10 can request pharmaceutical information from a pharmacy benefit manager (PBM) 18. Information regarding the progress of the disease can be derived from the pharmaceutical information to augment the patient record report forwarded by CIS 14. When several sources of information are combined in the augmented patient record report forwarded by facilitator 12, requestor 10 can make a more informed decision.

In addition to patient record reports, other information is also available using the method illustrated in Figure 4. For example, a physician' s DEA number should be associated with each report. If the requestor has additional questions, the appropriate physician can be located using this DEA number and can be contacted to request additional information. If the patent record report is discontinuous, facilitator 12 may prompt the CIS to determine if the physician has moved. If the physician has moved, facilitator 12 can prompt several CIS providers to determine the new location of the physician. The physician may then be contacted to determine if he or she still provides service to the patient. This is especially important when a patient' s name or other information has changed such as through marriage, etc. It will be appreciated that while only one CIS is illustrated in Figure 4, facilitator 12 is connected to many such CISs. In addition, facilitator 12 can be connected to many PBMs or other patient record sources. When used herein, "patient record" is defined to mean all traditional and nontraditional patient medical information including clinical information, APRs, PBMs, paper-based patient records which have been digitized, computer-based patient records offered through CISs, electronic medical records, personal health records, Internet records, etc. Facilitator 12 has access to many patient record sources. Upon receiving a record request, facilitator 12 queries all sources or a preselected number of sources and combines all that information in the augmented patient record report forwarded to the requestor. Turning now to Figure 5, another embodiment of the present invention is illustrated in which the role of facilitator 12 is reduced. In this embodiment, requestor 10 makes a record request of facilitator 12. Facilitator 12 makes a record query of CIS 14. CIS 14 uses information such as the social security number, name, and address to determine whether the individual has records within any of the clients which the CIS serves. If patient records are available from this patient record source, then the CIS requests authorization from the appropriate physician to release the records. Upon authorization by the physician, the CIS forwards the records directly to requestor 10. Although this embodiment does not provide the benefits of gathering information from multiple sources, or normalizing and augmenting the patient report, this embodiment is useful when only limited information is required and the CIS can provide the information in a format which is acceptable by the requestor. Since the CIS is paid for the records forwarded to the requestor, and the facilitator does not provide the service of normalization or augmentation, the CIS manager may charge more money for providing the records directly to the requestor. In order to enjoy this benefit, however, the CIS must provide the information in a format which is acceptable or at least tolerable by the requestor.

As discussed above, many CIS managers are queried by the facilitator and in the embodiment illustrated in Figure 5, more then one CIS could respond to the record query by the facilitator by forwarding a patient record report directly back to the requestor 10. Neither Figure 5 nor any embodiments disclosed herein are intended to be restricted to only one facilitator or only one CIS manager. It is anticipated that many patient record sources and multiple facilitators maybe utilized in each of these embodiments. Some of the benefits are achieved, however, by utilizing only one facilitator as the normalization and augmentation services provided by the facilitator are more beneficial when only one facilitator is utilized. Because not all patient record sources may allow access by all facilitators, however, there may be instances when several facilitators are required to gather a comprehensive patient record report.

Referring now to Figure 6, another embodiment of the present invention is depicted in which the function of the facilitator 12 and normalization engine 16 have been imported into the requestor's computer system. Requestor 10 now has facilitation software 20 available for directly querying patent record sources for records. In the embodiment illustrated in Figure 6, a record query is forwarded to CIS 14 from facilitation software 20. CIS 14 then forwards the record query to all of the patient record sources that CIS 14 hosts. It will be appreciated that the functionality of CIS 14 is increased in the role it plays in the embodiment illustrated in Figure 6. As can be seen in the illustration, CIS 14 manages records for not only healthcare facilities and individual physicians, but also hospitals, home care providers, hospices, pharmacies and other sources of patient records. As with the other embodiments, facilitation software 20 may contact many such CISs, however, because the CISs have assumed additional responsibilities, it is anticipated that fewer CISs will need to be contacted when utilizing the method of this embodiment. After receiving information from several of the patient record sources, CIS 14 forwards a patient record report back to facilitation software 20 which then normalizes and combines all of the information from the CIS into a single report viewable by the requestor.

Turning now to the embodiment illustrated in Figure 7, requestor 10 has available facilitation software 20 which can place a record request with a CIS 14. The embodiment depicted in Figure 7 varies from that shown in Figure 6, however, in that the patient record sources forward the records directly back to the facilitation software instead of passing through the CIS. Facilitation software 20 may then either forward the patient record reports from each of the patient record sources directly to the requestor or may wait until all of the information is provided and then normalize and augment the report before forwarding it to the requestor. Alternatively, the software may wait a prescribed period of time before normalizing and augmenting a report for the requestor.

Although not depicted, it will be appreciated that the present invention anticipates a combination of the methods set forth in Figure 6 and Figure 7 in which some of the patient record sources provide the patient record report back to the CIS and other patient record sources forward the information directly to the facilitation software. The depiction used in this application are not meant to restrict the scope of the claims, but instead serve to facilitate in the discussion of the present invention.

Turning now to Figure 8, an embodiment of the present invention is depicted in which requestor 10 has available facilitation software 20 which places record queries directly to patient record sources. Facilitation software 20 may then normalize and augment the patient record reports from the sources as the information is received or until a preset time limit has elapsed before prompting the requestor.

It will be appreciated that the requestor may also monitor the status of information received the facilitation software that any time even though a report has not been generated. If a requestor views an incomplete report, information maybe nevertheless gleaned from that report which prompts the requestor to request information from other patient record sources. This is especially beneficial if incomplete information is had regarding the name, address, or social security number of the patient. Using the embodiment in Figure 8, a requestor having only a limited amount of information regarding the patient, for example, only the sex, first and last name, could place a record request through the facilitation software and receive patient record reports which could be then culled through to locate the correct patient. A more extensive record query can then be launched to locate more confidential and secure patient record sources to receive a complete patient record report.

Although the facilitator 12 and facilitation software 20 as well as CIS 14 all have access to multiple patient record sources, not all of those patient record sources need be contacted upon the receipt of each record query or record request. To save time and costs, a requestor 10 may provide a limited request to the facilitator 12 and may be satisfied with the results received from that limited query. If not satisfied, the requestor may then request additional information from other perhaps more expensive sources from facilitator 12. PROGRAM STORAGE DEVICE

It will be apparent to those of ordinary skill having the benefit of this disclosure that any of the foregoing variations maybe implemented by programming one or more suitable general-purpose computers having appropriate hardware. The programming may be accomplished through the use of a program storage device readable by the computer and encoding a program of instructions executable by the computer for performing the operations described above. The program storage device may take the form of, e.g., one or more floppy disks; a CD ROM or other optical disk; a magnetic tape; a read-only memory chip (ROM); and other forms of the kind well-known in the art or subsequently developed. The program of instructions may be "object code," i.e., in binary form that is executable more-or-less directly by the computer; in "source code" that requires compilation or interpretation before execution; or in some intermediate form such as partially compiled code. The precise forms of the program storage device and of the encoding of instructions are immaterial here.

Example 1 In one example of one embodiment of the present invention, a system for retrieving computer-based patient records via computer network allows an insurance underwriter 60 to request computer-based patient records from a computerized patient records (CPR) facilitator. The system comprises a facilitator's central server 62 connected to the a computer network. The facilitator's server is capable of receiving information and requests from insurance underwriters, vendors of computer information systems, and healthcare facilities using a computer network such as the Internet. The facilitator's server is also capable of sending information and requests to the insurance underwriters, vendors of computer information systems for CPRs, and healthcare facilities over the Internet. The facilitator's central server is secure and is not used to retain any information from a CPR. The facilitator server merely makes it possible to electronically request and deliver the CPR to the underwriter.

The facilitator's server networks to a plurality of CIS vendors servers 64. The CIS vendors (CIS-Vs) are the vendors that install and maintain the computer information systems for CPRs used at physicians healthcare facilities. In this embodiment of the present invention, the facilitator installs a secure, requesting software module 63 onto the facilitator's server. The secure software module (Ml) on the facilitator's server is then networked to a second facilitator software module.(M2) 65 installed on each of the CIS - V central servers.

As will be explained more fully below, the facilitator is able to determine which vendor should receive the underwriter's request based on information provided by the underwriter and information provided by the various vendors. The appropriate vendor's server receives the underwriter's request via the facilitator.

Each of the CIS vendors is networked to the CISs 72 in the healthcare facilities which the vendor services. Typically, a vendor has a direct network connection to the CISs in the healthcare facilities it services in order to provide maintenance and customer service to the healthcare facility's CISs. Through the network connection, the vendor is able to transmit the requests and information from the M2 module to a third software module (M3) 73 installed on the healthcare facility CIS for that purpose. The M3 module on the healthcare facility's CIS is connected to the network in a way that allows the M3 to send information to the facilitator's server and subsequently to be delivered to the underwriter.

In an alternative embodiment, the CPR from the healthcare facility is sent from the M3 module on the healthcare facility CIS to a fourth software module (M4) 75 on the facilitator's server. The M4 receives the report and may augment the information being transmitted. For example, the M4 may normalize the information to a convenient format for transmission or reception or may remove or add information from the CPR as necessary or desired. In this example the underwriter desires to know medical information about an insurance applicant. Using a keyboard and visual interface, such as personal computer, the underwriter logs onto the facilitator's server over the Internet and orders an APS associated with the applicant. As the request is being processed, the underwriter's personal computer receives and displays the current status/progress of APS retrieval. The facilitator's central servers (FCS) receive the request from the underwriter for retrieval of an individual's medical record (APS). The FCS receives status information from Ml and transmits it to the underwriter's personal computer for immediate viewing by the underwriter. The central server delegates the underwriters request to Ml , operational within the facilitator's central servers, to determine if an electronic medical record (e-APS) is likely to exist. Typically the request contains information sufficient to determine which healthcare facility generated the APS. For example the request may include information regarding a physician's demographics, including the DEA number, as well as the detailed information about the healthcare facility where that physician now practices, or has previously practiced. This information from the request, together with information obtained from the vendors, facilitates retrieving the medical record.

The Ml module analyzes the request to determine if the healthcare facility is using a CIS system and therefore knows whether to attempt retrieval of an electronic medical record (e-APS). If it appears that no e-APS exists, Ml sends negative acknowledgment to the underwriter about the e-APS and may offer to initiate an order for physical-or manual-retrieval of the paper-based APS. If a healthcare facility is using a vendor's CIS, the Ml determines which vendor system is installed at the facility. If it appears that an e-APS might exist on a CIS, Ml sends an affirmative acknowledgment to the underwriter indicating that the e-APS retrieval process has commenced. The Ml continues to post further status indicators showing key procedures in the retrieval process as they occur. Ml determines which CIS vendor has this e-APS, and also indicates in which healthcare facility it is stored. Ml, running on FCS, initiates the sequence to forward the request for the e-APS to the external module, M2, which is running on the specified CIS vendor's central server. Ml then initiates transmission of the request for the e-APS to M2. Upon receipt of the request for the e-APS from Ml , M2 responds by acknowledging receipt of the request, and then continues sending current status information about progress in the handling of the request back to Ml.

In addition to receiving information through M2 about the specific request, Ml may receive new and updated information on the various healthcare facilities and healthcare providers who are using that vendor's computer information system. M2 sends all update information on existing-as well as any additional or new-healthcare facilities which have installed their CIS to Ml. M2 also routinely transmits to Ml any and all information about any changes about any of their existing or newly-registered healthcare providers at any of their installed sites, including when they commenced/terminated practicing at their healthcare facilities. Ml receives the update information on healthcare facilities and healthcare providers from the M2, and then files and indexes such data. Ml also maintains the files containing all demographics and related information about each healthcare facility, as well as each healthcare provider who is using or who has ever used that vendor' s system. Maintaining all of the indices to these files on Ml provides very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using or who has ever used a CIS system.

Similarly, Ml also receives all transaction information concerning the processing of e-APS requests from the M2 and then files, archives, and indexes such data. Ml maintains the files containing all accounting and related information about each transaction associated with each vendor's information system and with each of their installed systems. Ml may continually or periodically receive notice and the updated processing status from M2.

When M2 receives the request for retrieval of an electronic medical record (e-APS), from Ml, the request for the e-APS contains information such as the DEA number of the healthcare provider and the vendor's internal ID of the specific healthcare facility where the healthcare provider practices, to facilitate locating the record. M2 sends notice of receipt of request to Ml and continues to transmit updates to Ml concerning processing status.

Having identified the specific healthcare facility at which the record is likely to be kept, M2 sends the request for a specific e-APS to M3, which is running on the installed CIS at the designated healthcare facility. M2 receives the notice and the processing status from M3 and continues sending status info to Ml .

M3 receives request from M2 at the CIS vendor's server for retrieval of an electronic medical record (e-APS). In this example, the request contains DEA number of the healthcare provider, and the internal ID of the specific healthcare facility where the healthcare provider practices or practiced, that is, the healthcare facility where it is anticipated that the e-APS resides. M3 then sends to M2 the notice of receipt of request for the e-APS and updates the processing status.

Each of the vendor's installed CIS systems maintains a record of all demographics for all healthcare providers who utilize their system to document patient encounters, and M3 receives and tracks the identity of each healthcare provider user, including their DEA number and the internal ID of the specified healthcare facility(s) where each healthcare provider practices. M3 then sends to M2 the complete information about each healthcare provider user registered at the healthcare facility where the CIS is installed. This provides M2 the information it needs to quickly locate the healthcare facility where the electronic record is likely to reside. Like Ml , M2 receives all new and updated information on healthcare facilities and healthcare providers from the M3, located in installed CIS systems from each particular vendor, and then M2 files and indexes all such data. M2 maintains the files containing all demographics and related information about each healthcare facility and each healthcare provider who is using, or who has ever used, one of the deployed systems from this particular CIS vendor. Maintaining of the indices to these files allows M2 to provide very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using, or who has ever used, a deployed system from this CIS vendor.

M2 receives all transaction information concerning the processing of e-APS requests from, the M3 and files, archives, and indexes such data. M2 maintains the files containing all accounting and related information about each transaction associated with a particular CIS vendor and M2 with each of their installed systems. Along with the requests from M2 for retrieval of one the e-APS), M3 receives a digitized copy of the signed authorizations for release of each patient' s computer-based patient record. M3 sends to M2 the notice of receipt of request and authorization for the e-APS and updates the processing status. M3 submits a notification such as a page, e-mail, phone message, etc. to the healthcare facility's systems administrator (SA) at the site, indicating one or more of the following: 1) a request for one or more specified CPRs/EMRs has been received from their vendor's server; 2) the request(s) is awaiting the SA's timely response; and 3) the more rapidly the S A clicks on to "release" the record, the more money the practice will receive for this electronic retrieval.

Transparently, but using M3, the healthcare facility's systems administrator (SA) at the site reviews each request for a medical record. The SA may examine the signed authorization for release of the patient's record and, after verifying all aspects of the transaction, the SA can send the encrypted medical record securely over the Internet to the facilitator's central server. In one alternative embodiment, the record is transmitted to a fourth module, located on the FCS where the record may be normalized or augmented in some way.

M3 monitors the timing of the healthcare facility's systems administrator's (SA) action/inaction in response to the request. If the S A does not take action within the specified and agreed-upon time frame (driven by parameters within M3), automated escalation procedures are invoked to ensure timely release of the desired patient record(s). With M3 embedded and installed at each of CIS vendor's customer's sites, the M3 maintains a record of all aspects of each transaction, including all data required by HIPAA.

In one embodiment, M3 interacts with the CIS system by sending the request and receiving the medical record in a machine readable formats such as an Excel spreadsheet; a MS Word document or a standard Crystal Reports format. M3 then sends to M2 the transaction information (only the "envelope") about each patient record that was transferred by M3 to M4. The actual patient record is not transmitted to M2, the record is encrypted and securely transmitted to the facilitator's central server. M3 receives new and updated information on healthcare facilities and the practicing healthcare providers from the vendor's system-that is, from the deployed CIS system installed at this particular healthcare facility. M3 maintains the files containing all demographics and related information about each healthcare facility and about each healthcare provider who is using, or who has ever used, this particular CIS system installed at this particular healthcare facility. M3 maintains all of the indices to these files to provide very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using, or who has ever used, this installed system from this CIS vendor.

M3 also maintains the files containing all accounting and related information about each transaction associated with the particular installed CIS system from the vendor. M3 maintains the files containing all demographics and related information about each healthcare facility and transmits it to the M-2 installed on the CIS vendor's central system. Furthermore, M3 maintains all of the HIPPA information about each transaction required by the regulations.

M3 sends to the FCS (or M4 on the FCS) the fully populated transaction, including the "envelope" or accounting information and all clinical information about each patient record which was requested by the facilitator. Within the FCS, the M3 installed in each of CIS vendor's customer's site can communicate with the facilitator's central server via the internet. Alternatively, the M3 can communicate with the FCS via a dial-up to an 800 number operated by the facilitator. The FCS then receives the fully populated transaction from M3 and securely transmits it to the authorized underwriter. Authorization for all of the release of the records is conducted preferably using digital certificates, however, other form authorization, such as biometric authorization, may be employed.

FCS retains only the "envelope" information about each transaction. No actual patient record data is retained by the facilitator. The facilitator only acts as conduit to allow the information to flow more easily from the healthcare facility to the authorized requestor.

Example 2 In a second embodiment of the present invention, shown in Figures 9 and 10, a system for retrieving computer-based patient records via computer network allows an insurance underwriter 60 to request computer-based patient records from a CPR facilitator. The system comprises a facilitator's central server 62 connected to the a computer network. The facilitator's server is capable of receiving information and requests from insurance underwriters, vendors of computer information systems for CPRs, and healthcare facilities using a computer network such as the Internet. The facilitator's server is also capable of sending information and requests to the insurance underwriters, vendors of computer information systems for CPRs, and healthcare facilities over the Internet. The facilitator's central server is secure and is not used to retain any infonnation from a CPR. The facilitator server merely makes it possible to electronically request and deliver the CPR to the underwriter.

The facilitator's server networks to servers 64 of a plurality of computer information system vendors. (CIS--V). The CIS~Vs are the vendors that install and maintain the computer information system for CPRs used at healthcare facilities. In this embodiment of the present invention, the facilitator installs a secure, requesting software module onto the facilitator's server. The secure software module (Ml) 63 on the facilitator's server is then networked to a second facilitator software module (M2) 65 installed on each of the CIS - N central servers.

As will be explained more fully below, the facilitator is able to determine which vendor should receive the underwriter's request based on information provided by the underwriter and information provided by the various vendors. The appropriate vendor's server receives the underwriter's request via the facilitator. Each of the CIS vendors is networked to the CISs 72 in the healthcare facilities which the vendor services. Typically, a vendor has a direct network connection to the CISs in the healthcare facilities it services in order to provide maintenance and customer service to the healthcare facility' s CISs. Through the network connection, the vendor is able to transmit the requests and information from the M2 module to a third software module (M3) 73 installed on the healthcare facility CIS for that purpose. The M3 module on the healthcare facility's CIS is connected to the network in a way that allows the M3 to send information to the facilitator's server. In this example the CPR's are maintained on the CIS vendor's servers rather than the healthcare facility's CIS. The vendor communicates with the healthcare facility in order to receive the necessary authorization to release the CPR's to the requestor. The CPR is sent from the vendor to a fourth software module (M4) 75 on the facilitator's server for securely receiving and transmitting it to the requestor the CPR. Additionally, the M4 may augment the information being transmitted. For example, the M4 may normalize the information to a convenient format for transmission or reception or may remove or add information from the CPR as necessary or desired. In this example the underwriter desires to know medical information about an insurance applicant. Using a keyboard and visual interface, such as personal computer, the underwriter logs onto the facilitator's server over the Internet and orders an APS associated with the applicant. As the request is being processed, the underwriter's personal computer receives and displays the current status/progress of APS retrieval. The facilitator's central servers (FCS) receive the request from the underwriter for retrieval of an individual's medical record (APS). The FCS receives status information from Ml and transmits it to the underwriter's personal computer for immediate viewing by the underwriter. The central server delegates the underwriters request to Ml , operational within the facilitator's central servers, to determine if an electronic medical record (e-APS) is likely to exist. Typically the request contains information sufficient to determine which healthcare facility generated the APS. For example the request may include information regarding the physician's demographics, including the DEA number, as well as the detailed information about the healthcare facility where that physician now practices, or has previously practiced. This information from the request, together with information obtained from the vendors, facilitates retrieving the medical record.

The Ml module analyzes the request to determine if the healthcare facility or healthcare facility is using a CIS for CPRs and therefore knows whether to attempt retrieval of an electronic version of the attending physician statement (e-APS) or other similar electronic medical records. If it appears that no e-APS exists, Ml sends negative acknowledgment to the underwriter about the e-APS and may offer to initiate an order for physical-or manual-retrieval of the paper-based APS. If a healthcare facility which vendor's system is installed there at this particular healthcare facility is using a CIS, the M 1 determines which vendor system is installed at the facility. If it appears that an e-APS might exist on a CIS, Ml sends an affirmative acknowledgment to the underwriter indicating that the e-APS retrieval process has commenced. The Ml continues to post further status indicators showing key procedures in the retrieval process as they occur.

M 1 determines which CIS vendor has this e-APS, and also indicates which healthcare facility can grant release of the record. Ml, running on FCS, initiates the sequence to forward the request for the e-APS to the external module, M2, which is running on the specified CIS vendor's central server. Ml then initiates transmission of the request for the e-APS to M2. Upon receipt of the request for the e-APS from Ml, M2 responds by acknowledging receipt of the request, and then continues sending current status information about progress in the handling of the request back to Ml .

In addition to receiving information through M2 about the specific request, Ml may receive new and updated information on the various healthcare facilities and healthcare providers who are using that vendor's computer information system. M2 sends all update information on existing-as well as any additional or new-healthcare facilities which have installed their CIS to Ml . M2 also routinely transmits to Ml any and all infonnation about any changes about any of their existing or newly-registered healthcare providers at any of their installed sites, including when they commenced/terminated practicing at their healthcare facilities.

Ml receives the update information on healthcare facilities and healthcare providers from the M2, and then files and indexes such data. Ml also maintains the files containing all demographics and related information about each healthcare facility, as well as each healthcare provider who is using or who has ever used that vendor's system. Maintaining all of the indices to these files on Ml provides very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using or who has ever used a CIS for CPRs.

When M2 receives the request for retrieval of an e-APS from Ml , the request for the e- APS contains information such as the DEA number of the healthcare provider and the vendor's internal ID of the specific healthcare facility where the healthcare provider practices, to facilitate locating the record. The vendor may keep all of the medical records from the faicilities it services in one large central database from which the record can be extracted and delivered to the requester. However, the records from each facility the vendor services are likely to be kept in discrete databases, so as not to be co-mingled with the records of any other healthcare facility. M2 sends notice of receipt of request to Ml and continues to transmit updates to Ml concerning processing status.

Having identified the specific healthcare facility where the record was generated and thereby located the specific database in which the record is likely to be kept, M2 sends the request for the release of the specific e-APS to M3 at the designated healthcare facility. M2 receives the notice and the processing status from M3 and continues sending status info to Ml.

M3 receives request from M2 at the CIS vendor's server for release of an electronic medical record (e-APS). In this example, the request contains DEA number of the healthcare provider, and the internal ID of the specific healthcare facility where the healthcare provider practices or practiced, that is, the healthcare facility where it is anticipated that the e-AP S was generated. M3 then sends to M2 the notice of receipt of request for the e-APS and updates the processing status.

Each of the vendor's installed CIS maintains a record of all demographics for all healthcare providers who utilize their system to document patient encounters, and M3 receives and tracks the identity of each healthcare provider user, including their DEA number and the internal ID of the specified healthcare facility(s) where each healthcare provider practices. M3 then sends to M2 the complete information about each healthcare provider user registered at the healthcare facility where the CIS is installed. In one embodiment, M3 transfers the e-APS and other relevant data from the CIS through M3 and to M2 where the information is used to populate and update the database. In addition to providing the APS information itself, this information flow provides M2 the information it needs to quickly locate the healthcare facility where release authorization can be obtained. M3 interacts with the healtcare facility's system by sending electronic medical records and information in a machine readable formats such as an Excel spreadsheet; a MS Word document or a standard Crystal Reports format to M2. The electronic patient record is transmitted to M2 and stored on the CIS vendor's database. Naturally, the record is encrypted and securely transmitted to the vendor's server.

Like M 1 , M2 receives all new and updated information on patient records, healthcare facilities and healthcare providers from the M3, located in installed CIS from each particular vendor, and then M2 files and indexes all such data. M2 maintains the files containing all demographics and related infonnation about each healthcare facility and each healthcare provider who is using, or who has ever used, one of the deployed systems from this particular CIS vendor. Maintaining of the indices to these files allows M2 to provide very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using, or who has ever used, a deployed system from this CIS vendor.

M2 receives all transaction information concerning the processing of e-APS requests from the M3 and files, archives, and indexes such data. M2 maintains the files containing all accounting and related information about each transaction associated with a particular CIS vendor and M2 with each of their installed systems. Along with the requests from M2 for release of one the e-APS), M3 receives a digitized copy of the signed authorizations for release of each patient' s computer-based patient record. M3 sends to M2 the notice of receipt of request and authorization for the e-APS and updates the processing status.

M3 submits a notification such as a page, e-mail, phone message, etc. to the healthcare facility's systems administrator (SA) at the site, indicating one or more of the following: 1 ) a request for one or more specified CPRs has been received from their vendor ' s server; 2) the request(s) is awaiting the SA's timely response; and 3) the more rapidly the SA clicks on to "release" the record, the more money the practice will receive for this electronic retrieval. Transparently, but using M3, the healthcare facility's systems administrator (SA) at the site reviews each request for a medical record. The SA may examine the signed authorization for release of the patient's record and, after verifying all aspects of the transaction, the SA can send the release securely over the Internet to the facilitator's central server. M3 monitors the timing of the healthcare facility's systems administrator's (SA) action/inaction in response to the request. If the SA does not take action within the specified and agreed-upon time frame (driven by parameters within M3), automated escalation procedures are invoked to ensure timely release. With M3 embedded and installed at each of CIS vendor's customer's sites, theM3 maintains a record of all aspects of each transaction, including all data required by HIP AA.

M3 receives new and updated information on healthcare facilities and the practicing healthcare providers from the vendor's system-that is, from the deployed CIS system installed at this particular healthcare facility. M3 maintains the files containing all demographics and related information about each healthcare facility and about each healthcare provider who is using, or who has ever used, this particular CIS system installed at this particular healthcare facility. M3 maintains all of the indices to these files to provide very powerful search capabilities relating to any healthcare facility and for any healthcare provider who is using, or who has ever used, this installed system from this CIS vendor.

M3 also maintains the files containing all accounting and related information about each transaction associated with the particular installed CIS system from the vendor. M3 maintains the files containing all demographics and related information about each healthcare facility and transmits it to the M-2 installed on the CIS vendor's central system. Furthermore, M3 maintains all of the HIPPA information about each transaction required by the regulations. M2 sends to the FCS (or M4 on the FCS) the fully populated transaction, including the "envelope" or accounting information and all clinical information about each patient record which was requested by the facilitator. The M2 installed in the vendor's servers can communicate with the facilitator's central server via the Internet. Alternatively, the M2 can communicate with the FCS via a dial-up to an 800 number operated by the facilitator. The FCS then receives the fully populated transaction from M2 and securely transmits it to the authorized underwriter. Authorization for all of the release of the records is conducted preferably using digital certificates, however, other form authorization, such as biometric authorization, may be employed.

The particular embodiments disclosed above are illustrative only, as the invention may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of preferred environments or preferred embodiments herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments may be altered or modified and all such variations are considered within the scope and spirit of the invention. Accordingly, the protection sought herein is as set forth in the claims below.

In at least one embodiment, the present invention comprises the steps of searching for a person' s medical information by first receiving a request for medical information from a requestor and receiving digitally signed authorization to release the medical information. A query is then transmitted to a medical information repository for information pursuant to the request; and a response to the request based on the query is transmitted .

More specifically, in at least one embodiment, the present invention relates to methods and apparatus for electronically providing legally effective medical information release forms electronically in order to obtain electronic access to patient medical records created by health care providers working at healthcare facilities, which includes but is not limited to clinical records, lab records, billing coded information, and prescription drug records. The system works most efficiently when a healthcare facility is utilizing a computer information system (CIS) for creating, managing and/or storing computerized patient records or electronic medical records, but the system can work advantageously with virtually any type of digitized medical record or even to facilitate electronic receipt of authenticated digitally signed authorizations for retrieval of paper-based medical information. The preferred embodiment of the system and method comprise a request facilitator which receives requests for medical records from a requestor such as an insurance company, physician, etc. and forwards the request directly or through a facilitating party to the appropriate healthcare facility or physician. As used herein, the term "healthcare facility" refers to any office, building or location, physical or electronic, where healthcare related services are rendered, including but not limited to clinics, hospitals, pharmacies, laboratories, healthcare providers and other medical information repositories. The request includes a release form that is digitally signed and biometrically authenticated.

By including a release form that is digitally signed and biometrically authenticated, the healthcare provider is alleviated of the need to inquire as to whether the request is legitimate and records can be released with full confidence of the integrity of the signed authorization. For purposes of this application, a healthcare provider can be any person or organization that renders healthcare related services, including but not limited to clinics hospitals, pharmacies and labs. Having received the request and release of the records and after having verified authorization to do so, the healthcare provider manually or automatically releases the records, forwarding them to the facilitator; the records are then forwarded to the requestor. Alternatively, the records may be forwarded directly to the requestor. The health care provider can then electronically store copies of the request, the release form and the information transmitted as may be required.

The use of a combined digital signature and biometric authentication may also be used in the processes of searching the medical information repository for information regarding apatient or healthcare provider for financial transactions and payment to healthcare facilities. Benefits of the present invention is these process include a reduction in response time to requests and better security than faxing the information. Further, a healthcare facility's staff are not overburdened by requests for information because computers process and handle the requests for release. Since access is preferably electronic, information requesters may not have to incur traditional manual retrieval and storage of requested information. Additionally, the technology may be applicable and advantageous to manual retrieval of records where no electronic medical information exists.

The widespread use of the present invention may facilitate a standardized authorization format for the release and transmission of medical information by healthcare providers, helping to integrate otherwise disparate healthcare practices. Healthcare facilities and providers, clinics, hospitals, pharmacies, laboratories and medical information repositories can share and exchange information in confidence, knowing that the flow of information is legally authorized by the patient or owner of the information and that it is secure. This could greatly improve the quality and efficiency of healthcare services. The present invention contemplates the use of one or more methods for securing documents by the use of digital signature and biometric identification. Digital signatures can provide both encoding and authentication of documents being transmitted. The document can be encoded so that only the intended receiving computer can read and decipher the document. The document can also be authenticated using an electronic means or process for verifying that the source of the information being sent is a trusted or known source. Authenticating the document can be done by the use of passwords, check sum verification, hashing algorithms, cyclic redundancy check verification, and other authentication tools and systems.

In the preferred embodiment of the present invention, digital signatures are accomplished using key encryption. Private key encryption may be preferred in circumstances in which it is known which particular computer will send the electronic data and which particular computer will receive the data. A private encryption key is installed on each of the computers allowing them to transmit encoded information over a computer network. In some embodiments of the present invention, circumstances may require the use of public key encryption, wherein the transmitting computer retains the private key and the public key is distributed to other computers for secure communication with the originating computer. In a multiple network environment, such as the internet, in order to employ public key encryption it is necessary to include a certificate authority to verify the authenticity of the parties wishing to communicate securely and to distribute the public encryption keys necessary for a secure communication.

The digital signature technology which, though legally sufficient for the release of the information, by itself may be considered insufficient for security purposes, can be combined with biometric technologies. Biometrics for authentication and identification purposes include the use of measurements of unique visible features such as fingerprints, hand and face geometry, and retinal and iris patterns, as well as the measurement of unique behavioral responses such as the recognition of vocal patterns and the analysis of hand movements. The use of each of these biometrics requires a device to make the biological measurement and process it in electronic form. The device may measure and compare the unique spacing of the features of a person' s face or hand and compare the measured value with a value stored in the device's memory. Where the values match, the person is identified or authorized. The use of internal biometrics based upon physiological, histological and chemical/genetic measurements are being proposed and developed and may also be used in combination with a digital signature. Several types of technologies are used in biometric identification of superficial anatomical traits. For example, biometric fingerprint identification systems may require the individual being identified to place their finger on a visual scanner. The scanner reflects light off of the person's finger and records the way the light is reflected off of the ridges that make up the finge rint including detection of whether the digit is still connected to a living being. Hand and face identification systems use scanners or cameras to detect the relative anatomical structure and geometry of the person's face or hand. Different technologies are used for biometric authentication using the person's eye. For retinal scans, a person will place their eye close to or upon a retinal scanning device. The scanning device will scan the retina to form an electronic version of the unique blood vessel pattern in the retina. An iris scan records the unique contrasting patterns of a person's iris.

Still other types of technologies are used for biometric identification of behavioral traits. Voice recognition systems generally use a telephone or microphone to record the voice pattern of the user received. Usually the user will repeat a standard or predetermined phrase, and the device compares the measured voice pattern to a voice pattern stored in the system. Signature authentication is a more sophisticated approach to the universal use of signatures as authentication. Biometric signature verification not only makes a record of the pattern of the contact between the writing utensil and the recording device, but also measures and records speed and pressure applied in the process of writing.

Figure 1 shows a flowchart of one embodiment using digitally signed and biometrically authenticated information release form, in accordance with the present invention . Medical Information 100 encompasses all information relating to physical and mental health diagnoses and remedies such as physician-patient records, clinical information records and prescription drug records. Clinical information includes laboratory testing, ambulatory, home health, and long-term care among other sources of clinical care and information.

The illustrative method in Figure 1 includes receiving a request for medical information including identification of a subject and a digitally signed and biometrically authenticated information release form 105; transmitting a query and if necessary, the digitally signed release form to a medical information repository for information pursuant to the request 115; and transmitting a response to the request for medical information, including information based on the response to the query 125. A variation of the method and system described in Figure 1 includes the additional steps of using a third party to electronically verify the request and release 110 and receiving a response to the query containing medical information 120. In aid of further description, the illustrative method in Figure 1 will be described according to the several physical environments shown in Figure 3.

Figure 3 illustrates several preferred physical environments in which a digitally signed and biometrically authenticated information release form carried out in search of medical information. Specifically, three front-end physical environments capable of generating and transmitting a digitally signed and biometrically authenticated information release form are shown, a client-server environment 200, an intranet-based environment 205, and an internet- based environment 210. Each front-end physical environment includes one or more requesting and viewing clients ("RVC's), respectively, client-server-based 215, intranet- based 220, and internet-based 225.

An RVC is typically a terminal having at least a video display and keyboard and biometric authentication hardware, i general, each RVC is operated by an authorized user to request and possibly another authorized used who has distinctly separate privileges such as being able to subsequently review retrieved medical information or other search results. In light of the sensitive nature of medical information, security is of utmost importance. A variety of additional security measures could be employed to ensure that only authorized users obtain access.

Each RVC operates to receive a request for medical information according to its configuration. Generally, each RVC will receive such a request via an authorized user's responses to prompts generated by executing software displayed on the RVC video display. More specifically, a client-server RVC 215 would receive a request from an authorized user responding to prompts from software executing on requestor's server 230 or on RVC 215. An intranet-based RVC 220 would receive a request from an authorized user responding to prompts from software executed by RVC 220. An internet-based RVC 225 would receive a request from an authorized user responding to prompts from internet browser software executed by RVC 225 wherein the browser software is executing instructions received by an internet website accessed through the browser software.

In each of the three physical environments shown, RVCs are protected by at least one firewall 235 to deter unauthorized access. In the case of the client-server RVC 215, three firewall layers are shown in Figure 3, double firewall 240 in combination with firewall 235. An RVC is part of a network, wherein network is broadly defined to encompass any configuration of operably connected computers, including wired or wireless connectivity over an intranet, the internet, modems, phone lines, satellites, wireless transmitters and receivers, optical lines, firewalls, servers, relays, bridges, repeaters, etc.

Each request for medical information includes identification of a subj ect and digitally signed and biometrically authenticated information release form. A subject might consist of a human individual or group of humans. The subject is the target of the search for medical information. The identification of the subject could be by way of name, patient number, social security number, driver's license number, address, phone number, biometric identification or any other identification or combination of identification characteristics capable of being correlated with stored medical information, if it exists. The identification may be integral within or in addition to the digitally signed and biometrically authenticated request form.

The request may originate with any party desiring the medical information. The request may originate with insurance agencies, health care providers and professionals, and emergency medical technicians. In some embodiments of the present invention, the request originates with a medical information repository (MLR) itself. The request may be received directly by the MLR via an RVC controlled by the MIR or may be received by an RVC that then routes the request to the MIR. The term medical information repository includes medical information repository or health care provider such as a physician's office or clinical laboratory. In the present method, consent of the subject(s) is required to obtain the medical information. The digitally signed information release form is typically documentation of the subject's consent, or their legal representative's consent, to the disclosure of medical information. Such documentation can be in image or machine-readable format. In the preferred embodiment, the digitally signed and biometrically authenticated information release form is an integral part of the request. This method eliminates the necessity of scanning, transmitting, or sending paper documents, as the subject or their authorized representative electronically signs an information release form. In some situations the requestor, by means equivalent to a digitally signed and biometrically authenticated information release form, may electronically certify their possession of a signed information release, such as where the law requires the presentment of a release but does not require the record provider to maintain a copy of the release.

In the preferred embodiment shown in Figure 3 verification of the release is performed once the request and release are received by an RVC, the request is transmitted to and received by a central server 245. A central server may consist of multiple computers performing specific tasks or executing independent processes. When central server 245 receives a request for medical information 105, it may verify the request 110 before it sends a response to the request 125. Request verification 110 can take many forms, but most likely will be driven by the satisfaction of legal and security requirements. In the preferred embodiment the verification includes confirmation receipt of digitally signed information release form. Verification is communicated to the request handling software executing on the central server 245. An example of request verification 110 also includes electronic verification of an electronic watermark, biometric authentication or digital certificate submitted with the request. A further example includes verification of the user identified as originating the request for information or verification by source recognition, for instance a recognized account code, a request authorization code assigned by software, a hardware address, or the like.

Following receipt of the request for information 105, the Central Server 245 will transmit a query to a medical information repository 275 for information pursuant to the request 115. The query will preferably include a copy of the digitally signed and biometrically authenticated information release form depending on the procedure in place at the medical information repository and legal requirements. As explained above, a medical information repository includes pharmacy benefit managers ("PBM"s), pharmacies, and any other medical information repository such as a physician's office or clinical laboratory. PBMs are companies contracted by health insurers and self-insured employers to manage prescription drug programs. The path of the transmitted query 115 to the medical information repository may include one or more firewalls, 250 and 260, as depicted in Figure 3. Firewall 250 prevents unauthorized access to the central server 245. The particular method of communication is unimportant as long as information security measures are taken. The most common forms of communication are depicted in Figure 3 as leased line or internet 255.

In the preferred embodiment shown in Figure 3 an optional intermediate archived medical information system (AMIS) is employed. There are several benefits to utilizing an AMIS server 265. The AMIS server 265 removes the computing burden from medical information repositories such as MIR 275 by processing requests for information. The AMIS server 265 also allows for system maintenance and upgrades without disrupting medical information repository systems. The AMIS server 265 can also be used to archive medical information for longer periods of time than may be established for MIR 275. The period of archival in the AMIS server 265 could be any length of time. The AMIS server 265 maybe associated with one or more MIRs and may be networked with the MIR to receive data directly from the MIR or may be wholly removed from the MIR, receiving data indirectly.

When central server 245 receives the response to its query 120, it will prepare a response to the request received 105 from an RVC. If more than one query was made, central server 245 will compile the responses to the queries prior to returning the response to the request 125. The response to the request will be based, at least in part, on information contained in the response to the query 120. Depending on the results of the search, the response to the request 125 may even convey no results if that is conveyed in the response to the query 120. Similarly, messages similar to "information repository unavailable" may be required from time to time. The information requested from the various medical information repositories may be stored in formats that are generic, incompatible or in some way undesirable. When information relative to request is located by the search, the information may be advantageously compiled and reformatted. The ATMS server or the central server may operate to reformat and/or compile the responses received, before the response is ultimately transmitted to the intended receiver. The response may be advantageously reformatted in a several ways. For example, the information maybe reformatted to facilitate transmission, to safeguard confidentiality, or to make the information more user friendly. Alternatively, if the various medical information repositories store medical information in formats that are incompatible or undesirable, the repositories themselves maybe advantageouslyreformatted. The information received could also be advantageously reformatted by the RVC or by the intended recipient. Once properly formatted, the response to the request may be sent directly to the intended recipient from the MIR or AIMS. Alternatively the response may be transmitted to the intended recipient through the RVC.

With the inclusion of digitally signed and biometrically authenticated release forms, the computerization of the medical record retrieval is complete and no human-induced delays are encountered. Thus, retrieval of medical information occurs in near real-time as opposed to the usual several week delay in obtaining physician-based records, clinical records, and other paper-based medical records. Because of the speedy authorization and retrieval of medical information and the elimination of the need to fax or exchange release forms, requesters such as insurance companies will not incur unnecessary expenses.

In order to further facilitate the rapid retrieval of medical information, the present invention also contemplates the optional use of real time issuance of digital certificates. Digital certificates can be issued in real time through a process wherein a certificate authority verifies that that person applying for the certificate is in fact the person they claim to be by gathering historical facts and other identifying information about an individual found in various public and private information databases and testing the applicant's knowledge of such facts. Preferably the databases are accessible over a computer network so they can be searched on line. The present invention additionally includes the use of medical related information obtained online as "authenticating" information for real time issuance of digital certificates, exclusive of or in addition to other types of information. The digital certificate, and hence any digital signatures associated with it, is thereby enhanced and made more certain of the identity of the individual including in it clinical information related to the signator. Such information might include but is not limited to the total or selected combination of drugs for a person, prescribing physicians, and pharmacies used to fill such prescriptions, or selected unique elements from certain computer-based patient records or electronic medical records, or from laboratory test results.

Additional benefits provided by a method implemented in accordance with the present invention, aside from overcoming the difficulties associated with the prior art, include: increased confidence in maintaining privacy while distributing medical records over the internet; the potential for real-time application and issuance of insurance policies, benefits for physicians, and especially emergency care physicians, for purposes of diagnosis; and increased revenue for insurance companies who lose business due to delays in retrieving authorization to release medical records The present invention facilitates rapid and potentially realtime retrieval of key, distinctive information that uniquely identifies an individual for rapid issuance of a digital certificate. What is claimed is:

Claims

1. A method of searching for medical information executed by one or more computers comprising:

(a) receiving a request for medical information from a requestor including identification of a subject; (b) transmitting a query to a medical information repository for information pursuant to the request; and

(c) transmitting a response to the request including information based on the response to the query.

2. The method of claim 1, wherein the request further includes a signed information release.

3. The method of claim 2, wherein verifying the request includes verifying the signed information release.

4. The method of claim 1 , further comprising utilizing the medical information as a surrogate for a physician-based medical record.

5. The method of claim 1 , wherein the request is received by an internet website from an internet browser program executing on a computer communicating with the internet website.

6. The method of claim 1, wherein the query is transmitted to the medical information repository by an internet website communicating with the medical information repository.

7. The method of claim 5, wherein the computer communicating with the internet website operates according to input from a device capable of detecting the presence of an authorized user.

8. The method of claim 1 , wherein verifying the request includes verifying the source of the request.

9. The method of claim 1, wherein the response includes medication information, further comprising

(a) determining a probable location of medical information based on the medication information.

10. The method of claim 1, wherein the response includes clinical information, further comprising:

(a) determining a probable location of medical information based on the clinical information.

11. The method of claim 1 , further comprising (a) verifying the request.

12. The method of claim 1 , further comprising (a) receiving a response to the query.

13. A method of claim 1, wherein the response is transmitted directly to the requestor.

14. A method of searching for medical information executed by a network comprising:

(a) requesting medical information including identification of a subject;

(b) verifying the request;

(c) querying a medical information repository for medical information about the identified subject; and

(d) generating a response including any medical information about the subject contained in the medical information repository.

15. The method of claim 14, wherein the response includes medication information, further comprising (a) determining a probable location of medical information based on the medication information.

16. The method of claim 14, wherein the response includes clinical information, further comprising

17. The method of claim 14, further comprising

(a) utilizing the medical information as a surrogate for a physician-based medical record.

18. The method of claim 14, wherein requesting medical information about an identified subject is accomplished through an internet browser program executing on a computer communicating with an internet website.

19. The method of claim 14, wherein querying a medical information repository for medical information about the identified subject is accomplished through an internet website communicating with a medical information repository.

20. The method of claim 14, wherein requesting medical information about an identified subj ect is accomplished by a computer operating according to input from a device capable of detecting the presence of an authorized user.

21. The method of claim 14, wherein verifying the request includes verifying the source of the request.

22. The method of claim 14, wherein verifying the request includes verifying a medical information release form.

23. A program storage device encoding instructions executable by the one or more computers of a specified one of claims 1 through 21, including instructions for performing the operations recited in the specified claim.

24. A method for gathering and formatting medical information regarding an individual, and making that information available to a requestor, the method comprising the steps of:

(a) searching at least one medical information repository for medical information regarding a group of preselected individuals; (b) compiling and formatting at the site of the medical information repository the results of the search in a generic format ascertainable by requester; and

(c) providing the compiled results of at least one of the preselected individuals to a requestor upon verification that the request is authorized.

25. A method of providing relevant medical data from a medical information repository to a requestor in a format ascertainable by a requestor, the method comprising the steps of:

(a) receiving a query regarding the medical history of an individual;

(b) searching and compiling medical information from third party sources; and

(c) providing the compiled medical information to satisfy the query.

26. A method of searching for medical information executed by one or more computers comprising the steps of:

(a) formulating a record request for patient medical information;

(b) forwarding the record request to a facilitator, wherein the facilitator reviews the record request and determines which patient record sources to contact; (c) contacting at least one patient record source with a record query electronically requesting information regarding a patient;

(d) initiating an electronic search of medical records within the patient record source; and

(e) returning a patient record report containing information held by the patient record source.

27. A method as set forth in Claim 26, wherein the information from the patient record source is not released before a physician gives approval.

28. A method as set forth in Claim 26, wherein the information from the patient record source is released automatically.

29. A method as set forth in Claim 26, wherein the facilitator receives the patient record report in a machine readable format augments the report before forwarding it to the requestor.

30. A method as set forth in Claim 26, wherein the facilitator receives the patient record report and normalizes and augments the report before forwarding it to the requestor.

31. A method as set forth in Claim 26, wherein the patient record source is a CIS .

32. A method as set forth in Claim 26, wherein the patient record source is an EMR system.

33. A method as set forth in Claim 30, wherein the search is conducted using software modules installed in a central server, CIS vendor server and a CIS.

34. A method as set forth in Claim 32, wherein if the search determines that the information is available at one of its sources, the information is forwarded in a patient record report to the requestor.

35. A method as set forth in Claim 26, wherein the facilitator receives a patient record report and normalizes that report into a format acceptable to the requestor.

36. A method as set forth in Claim 34, wherein the facilitator receives patient record reports from several patient record sources and combines those reports into an augmented patient record report which is forwarded to the requestor.

37. A method of searching for medical information executed by one or more computers, the method comprising the steps of: (a) formulating a record query requesting information regarding an individual;

(b) forwarding the record query to a patient record source; and

(c) receiving a patient record report from the patient record source.

38. A method as set forth in Claim 37, wherein the patient record source is a computerized patient record manager.

39. A method as set forth in Claim 37, wherein the computerized patient record manager has contact with other patient record sources and queries those patient record sources before responding to the record query with a patient record report.

40. A method as set forth in Claim 37, wherein the step of forwarding the record query and the step of receiving a patient record are carried out using secure and encrypted means for communication.

41. A method for providing medical information executed by at least one computer, the method comprising the steps of:

(a) receiving a record query requesting information regarding an individual;

(b) searching a registry of databases to locate the available records; (c) obtaining the records; and (d) forwarding the records to the requestor.

42. A method as set forth in Claim 41, wherein the step of receiving a record query comes from a voice telephone call supplemented by a form of authorization and verification.

43. A method for determining a location of a patient record created by a healthcare giver at a healthcare facility comprising the steps of:

(a) establishing computer network connectivity between a request facilitator central server and a plurality of healthcare facilities' databases, said plurality of databases being populated by information identifying the healthcare givers using the healthcare facility database and dates for which the healthcare giver was associated with the healthcare facilities' databases to the request facilitator;

(b) transmitting the identifying information from the plurality of healthcare facilities' databases to the request facilitator' s central server including information indicating from which health care facility database the identifying information originates; (c) creating a searchable index of the identifying information;

(d) submitting a request for the patient record to the request facilitator, the request including information identifying the healthcare giver and an approximate date of creation of the patient record;

(e) querying the searchable index based on the request to determine the location of the patient record; and

(f) identifying the location of the patient record.

44. The method of claim 18 wherein at least one of the plurality of healthcare facilities' databases is operated by a healthcare facility.

45. The method of claim 43 wherein at least one of the plurality of healthcare facilities' databases is operated by a CIS vendor.

46. The method of claim 43 wherein the identifying information includes the healthcare giver's DEA number.

47. The method of claim 43 wherein the computer network connectivity is established over the Internet.

48. The method of claim 43 comprising the additional step of releasing and transmitting the patient record from the location to the request facilitator.

49. The method of claim 43 comprising the additional step of releasing and transmitting the patient record from the location to a requestor making the request.

50. The method of claim 48 wherein the step of releasing and transmitting the patient record is specifically authorized by an appropriate healthcare giver.

51. The method of claim 48 wherein the step of releasing and transmitting the patient record is by an appropriate healthcare giver is monitored for timeliness.

52. The method of claim 48 wherein the step of releasing and transmitting the patient record is automatically authorized by an appropriate healthcare giver.

53. The method of claim 40 wherein the location of the patient record is one of aplurality of computer information systems separate from the healthcare facilities' databases.

54. The method of claim 53 further comprising the step of additionally establishing computer network connectivity between the plurality of healthcare facilities' databases and the plurality of computer information systems.

55. The method of claim 54 wherein the healthcare facilities' databases are populated by identifying information transmitted from the plurality of computer systems where the patient records are located.

56. A method of searching for medical information executed by one or more computers comprising: (a) receiving a request for medical information from a requestor including and biometrically authenticated medical information release form bearing a digital signature;

(b) transmitting a query to a medical information repository for information pursuant to the request; and

57. The method of claim 56, wherein the query is transmitted to the medical information repository by an internet website communicating with the medical information repository.

58. The method of claim 57, wherein a computer communicating with the internet website operates according to input from a device capable of detecting the presence of an authorized user.

59. The method of claim 56, further comprising receiving a response to the query.

60. A method of claim 59, wherein the response is transmitted directly to the requestor.

61. The method of claim 56, wherein the digital is accomplished using private key encryption.

62. The method of claim 56, wherein said digital signature is accomplished using public key encryption.

63. The method of claim 56, further comprising verifying the release

64. The method of claim 63, wherein verifying the request includes verifying the source of the request using a digital certificate.

65. The method of claim 63, wherein verifying the request includes verifying the source of the request using cyclic redundancy check verification.

66. The method of claim 63, wherein verifying the request includes verifying the source of the request using passwords.

67. The method of claim 63, wherein verifying the request includes verifying the source of the request using check sum verification.

68. The method of claim 63, wherein verifying the request includes verifying the source of the request using hashing algorithms.

69. The method of claim 56, wherein the biometric authentication is a retinal eye scan.

70. The method of claim 56, wherein the biometric authentication is accomplished using is a hand writing signature recognition system.

71. The method of claim 56, wherein said digital signature is accomplished using electronic watermarks.

72. The method of claim 56, wherein the biometric authentication is a fingerprint scan.

73. The method of claim 56, wherein the biometric authentication is accomplished using a voice recognition system

74. A method of electronically transmitting authorization to release medical information over a computer network comprising:

(a) attaching a digital signature of an authorized individual to an electronic medical information release form requesting the release of a subject's medical information, said request including identification of the subject; (b) biometrically authenticating the identity of the subject digitally signing the release form verifying the request;

(c) verifying said digital signature; and

(d) transmitting said digitally signed request form over a computer internet to a medical information repository.

75. The method of claim 74, wherein said digital signature is accomplished using private key encryption.

76. The method of claim 74, wherein said digital signature is accomplished using public key encryption.

77. The method of claim 74, wherein verifying the request includes verifying the source of the request using a digital certificate.

78. The method of claim 74, wherein verifying the request includes verifying the source of the request using cyclic redundancy check verification.

79. The method of claim 74, wherein verifying the request includes verifying the source of the request using passwords,

80. The method of claim 74, wherein verifying the request includes verifying the source of the request using check sum verification.

81. The method of claim 74, wherein verifying the request includes verifying the source of the request using hashing algorithms.

82. The method of claim 74, wherein the biometric authentication is a retinal eye scan.

83. The method of claim 74, wherein the biometric authentication is accomplished using is a hand writing signature recognition system.

84. The method of claim 74, wherein said digital signature is accomplished using electronic watermarks.

85. The method of claim 74, wherein the biometric authentication is a fingerprint scan.

86. The method of claim 74, wherein the biometric authentication is accomplished using a voice recognition system

87. The method of claim 74, wherein verifying the request includes verifying the digital signature on a medical information release form using a digital certificate.

88. A method for electronically requesting and obtaining a person's medical information comprising:

(a) receiving a request for medical information from a requestor including identification of the subject; (b) receiving a digitally signed authorization of the subject;

(c) authenticating the subject by biometric identification;

(d) authenticating the source of the request by biometric identification;

(e) integrating said authorization into a query;

(f) transmitting said query to a medical information repository for information pursuant to the request; and

(g) transmitting a response to the request based on the query.

89. A program storage device encoding instructions executable by one or more computers including instructions for performing the operations of:

(a) attaching a digital signature of an authorized individual to an electronic medical information release form requesting the release of a subject's medical information, said request including identification of the subject;

(b) biometrically authenticating the identity of the subject digitally signing the release form;

(c) verifying the request;

(d) verifying said digital signature; and

(e) transmitting said digitally signed request form over a computer internet to a medical information repository.