Abstract:
The current invention addresses the problems that are encountered by patients, medical doctors, pharmacies and health insurance companies relating to filling medical prescriptions and related services. These services include, but are not limited to: scheduling appointments with the doctor electronically through the Internet; filing and paying for a medical prescription online through the Internet; electronic notification of any events related to medical issues, e.g. change in the doctor&#39;s appointments, availability of prescriptions for pickup, etc.; doctor&#39;s online access to the patient&#39;s preferred drug list as specified by the patient&#39;s PBM and Health Insurance plan; the pharmacy&#39;s electronic receipt and confirmation of a patient&#39;s prescription via the Internet; the patient&#39;s electronic notification of the readiness of a filled prescription; and the simplifying the refilling of medical prescriptions.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The current invention addresses the problems that are encountered by patients, medical doctors (MDs), pharmacies and health insurance companies relating to filling medical prescriptions. The method avails it itself to be used in other ways, some of which will be discussed in this invention.  
           [0002]    More than 44% of Americans take prescription drugs daily (source: USA Today, Jan. 31, 2001). MDs handwriting is notoriously illegible, so much so that according to the Institute of Medicine, in 1999 these errors cost $77 billion annually and cause 7,000 deaths a year. Legally, these misinterpreted MDs&#39; prescriptions have resulted in 90,000 malpractice claims over a recent 7-year period. Pharmacists mitigate these risks by calling the MDs for clarification of the prescriptions. These calls amount to 30% of the prescriptions that pass through pharmacists&#39; hands. In call volume this is about 100 million phone calls a year (Source: “A Plan to Send Prescriptions Electronically ”, The New York Times, Feb. 23, 2001).  
           [0003]    Next follows a description of the average process that a consumer, i.e. patient currently undergoes to acquire prescribed medication. A patient, to obtain a prescription for medication from an MD, follows the following steps as described in Table 1:  
                             TABLE 1                       Step   Patient Task Description                                1.   Schedule an appointment with the MD.       2.   Go to the MD&#39;s office for the scheduled           appointment.       3.   Be examined and diagnosed by the MD.       4.   The MD writes out and signs a prescription for the           patient.       5.   The patient takes the prescription to his pharmacy           to be filled.       6.   The patient provides Health Insurance information           to the pharmacist.       7.   The patient has a choice to wait for the filled           prescription, or to return later.       8.   Once the prescription has been filled, the patient           pays for it.                  
 
           [0004]    A pharmacist, to fill a prescription for medication from a patient, follows the following steps as described in Table 2:  
                             TABLE 2                       Step   Pharmacist Task Description                                1.   Read the patient&#39;s prescription.       2.   If any problems occur in understanding the           prescription, call the doctor&#39;s office for           clarification.       3.   Verify the patient&#39;s Health Insurance.       4.   Verify the patient&#39;s Health Insurance coverage for           the prescribed medication.       5.   Fill the prescription.       6.   Hand over the filled prescription to the waiting           patient.       7.   Accept payment for the filled prescription.                  
 
           [0005]    Note that the MD invariably is unaware which medications are covered by the patient&#39;s Health Insurance. This information is usually only confirmed at the pharmacy in Table 1, Step [4]. If the prescribed medication is not covered by the patient&#39;s Health Insurance, then the pharmacist must call the MD, who can fax or give the pharmacist a new prescription over the phone. Furthermore, if the medication is on the FDA&#39;s list of Schedule 4 or 5 drugs, a new written prescription must be obtained, i.e. the patient must return to the doctor&#39;s office and pick up a new prescription. Furthermore, the MD may have to consult with the patient whether or not another replacement medication could have allergic effects, etc.  
           [0006]    Today many employers and insurers hire drug plan managers, i.e. pharmacy benefit managers (PBMs). PBMs create lists of preferred drugs for plan members, which are generally the least expensive drugs. This system works by the pharmacy contacting the PBM to verify the doctor&#39;s prescribed medication. If the MD&#39;s prescribed drug is not on the PBM list, the pharmacy needs to contact the MD for a possible alternative, i.e. Step [2] in Table 2. Examples of PBMs are AdvancePCS, Express Scripts and Merck-Medco. These three companies have over 125 million members who used half of the 2.5 billion prescriptions filled in 2000.  
           [0007]    Recently the three major PBMs in the US, as mentioned above, formed a joint venture called RxHub. The proposed method and system of RxHub is to provide electronic filing of prescriptions between MDs, pharmacies and PBMs. An article in The New York Times, Feb. 23, 2001 titled “A Plan to Send Prescriptions Electronically” succinctly describes this system and hence is not described in detail here. The problem with this system and method is that the patient is still left on the sidelines, although the benefits to the patient are excellent. This invention addresses the inclusion of the patient in the acquisition of an electronically filed medical prescription.  
           [0008]    With the Internet boom, many proposals have appeared in various media regarding the entry of doctors into the computer age. Today only 5% to 10% of the US&#39;s 750,000 doctors use computer systems other than for billing systems, i.e. very few doctors use patient email interaction, online appointment scheduling, electronic filing of prescriptions, etc. (Source: “Physicians Are Entering the Computer Age”, The Wall Street Journal, Aug. 28, 2000). This patent addresses these online patient medical services. WebMD is one company that is tackling these challenges as well as others. The Internet boom has borne the arrival of online drugstores, e.g. VitalRx.com, Walgreens.com, etc. Even these pharmacists require patients to mail prescriptions to them and to verify the prescription with the MD by telephone (Source: “How to Tell Whether That Online Drugstore Is Really a Good Deal”, The Wall Street Journal, Feb. 16, 2001). The present invention addresses these manual interactions.  
           [0009]    There are numerous other patents that address computerizing various aspects of the medical profession. For example, U.S. Pat. No. 5,832,447 by Rieker et al. teaches a system and method to verify a patient&#39;s health insurance eligibility. U.S. Pat. No. 4,858,121 by Barber et al. teaches a method to coordinate and pay the relevant parties in a medical transaction. U.S. Pat. No. 5,301,105 by Cummings, Jr. teaches a comprehensive health care system. None of these mentioned patents fully address the problems that are encountered by patients, medical doctors, pharmacies and health insurance companies relating to filling medical prescriptions, that the present invention addresses.  
         OBJECTIVES OF THE PRESENT INVENTION  
         [0010]    The objective is to provide the medical patient with an array of convenient and easy to use services when interacting with his medical doctor (MD) and related services. These services include, but are not limited to:  
           [0011]    Scheduling an appointment with the MD electronically through the Internet.  
           [0012]    A choice of interacting with the MD electronically.  
           [0013]    Filing and paying for a prescription online through the Internet.  
           [0014]    Being electronically notified of any events related to medical issues, e.g. change in doctor&#39;s appointments, availability of prescriptions for pickup, etc.  
           [0015]    MD&#39;s online access to the patient&#39;s preferred drug list as specified by the patient&#39;s PBM and Health Insurance plan.  
           [0016]    Pharmacists&#39; electronic receipt and confirmation of a patient&#39;s prescription.  
           [0017]    Patient electronic notification of the readiness of a filled prescription.  
           [0018]    Simplifying the refilling of medical prescriptions. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0019]    [0019]FIG. 1 is a schematic of the preferred invention&#39;s embodiment of the patient&#39;s medical online experience.  
         [0020]    [0020]FIG. 2 is a schematic of the preferred invention&#39;s embodiment of the patient&#39;s medical online experience&#39;s processes. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0021]    With reference to FIG. 1 and FIG. 2, a Medical Doctor  1 , a Pharmacy Benefit Manager  2  (PMB), a patient&#39;s Health Insurer  3 , a patient&#39;s Pharmacy  11  and a Medical Supplier  4  connect with one another by means of a Private Medical Network  9  and/or the Internet  10 . Today the communication link via a Private Medical Network  9  is fairly common amongst most of the service providers, whereas the Internet  10  communications is not common. In addition to these various medical service providers inter-connectivity, the Patient  13  is connected as well to the various service providers via the Internet  10 .  
         [0022]    Using encryption technology such as Secure Sockets Layer (SSL) and Public Key Infrastructure (PKI), secure communication between all participants via the Internet  10  is used in this invention&#39;s preferred embodiment. Furthermore, information stored on the various participants&#39; databases is encrypted as well. The reason for using this encryption technology is to ensure patient confidentiality, specifically in compliance with the US Health Insurance Portability And Accountability Act of 1996 (HIPAA). The invention&#39;s preferred embodiment uses available standards for encryption such as Phil Zimmerman&#39;s Pretty Good Privacy (PGP), OpenPGP (the IETF&#39;s RFC 2440) and other available PKI encryption standards.  
         [0023]    Examples of the various participants&#39; databases includes the patient&#39;s medical records database  5  at the Medical Doctor  1 ; the patient&#39;s Health Insurance database  6  at the PMB; the patient&#39;s medical record database  7  at the Health Insurer  3 ; the supply database  8  for a Medical Doctor  1  at the Medical Supplier  4  and the patient&#39;s database  12  at the Pharmacy  11 . These databases are discussed are more detail later in the invention&#39;s preferred embodiment.  
         [0024]    Before continuing with the description of the preferred embodiment, an overview of various cryptography technologies that are used by the preferred embodiment are now discussed.  
         [0025]    Cryptography for Verification, Integrity and Confidentiality  
         [0026]    Two key technologies that the preferred embodiment of the invention uses is public key and conventional cryptography to ensure three things:  
         [0027]    (1) The transaction partner (e.g. Medical Doctor  1 , Pharmacy  11 , Health Insurer  3 , Patient  12 , etc.) is who he claims to be.  
         [0028]    (2) Confidentiality of the data transmitted between the transaction partners.  
         [0029]    (3) The data has not been altered during transmission.  
         [0030]    Various implementations of cryptography are used in the invention&#39;s preferred embodiment, such as Netscape&#39;s Secure Socket Layer (SSL), Phil Zimmerman&#39;s Pretty Good Privacy (PGP), Microsoft&#39;s Secure Electronic Transactions (SET), etc. All of these methods use a combination of public key and conventional cryptography.  
         [0031]    Conventional cryptography is also called secret key or symmetric key cryptography. The Data Encryption Standard (DES), Triple Des and Message Digest 5 (MD5) are examples of symmetric key cryptography. MD5 is described in further detail in the Internet Engineering Task Force&#39;s (IETF) RFC 1321. Use of secret keys to encrypt data is much faster than public key encryption, but the problem of using symmetric keys is the safe distribution of the keys between transaction partners. This key distribution is solved using public key cryptography.  
         [0032]    Public key cryptography is an asymmetric method that uses a pair of keys for encryption: a public key that encrypts data and a private key (i.e. secret key) that decrypts the data. The public key is openly distributed. The key&#39;s owner keeps the private key secret. The secret key cannot readily be derived from the public key.  
         [0033]    The above methods of cryptography are not described in detail in this invention. Excellent references are available that were used to devise the preferred embodiment of the invention. These references include:  
         [0034]    “An Introduction to Cryptography” by Network Associates, Inc.  
         [0035]    “How SSL Works” by Netscape.  
         [0036]    “Internet Cryptography” by Richard E. Smith.  
         [0037]    “Applied Cryptography” by Bruce Schneier.  
         [0038]    The Internet Engineering Task Force RFC library.  
         [0039]    A brief description follows of the various cryptography implementations that the invention&#39;s preferred embodiment uses.  
         [0040]    PGP uses a combination of public-key and conventional encryption to provide security services for electronic mail messages and data files. These services include confidentiality and digital signature. The IETF has a number of RFCs on PGP, which is also known as OpenPGP, e.g. RFC 1991 (“PGP Message Exchange Formats”) and RFC 2440 (“Open Message Format”).  
         [0041]    Some background on PGP now follows. When plaintext is encrypted with PGP, PGP first compresses the plaintext. Data compression saves data transmission time and device memory space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to decode the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements, e.g. of a computer&#39;s mouse and the keystrokes that are typed. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient&#39;s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.  
         [0042]    Decryption works in the reverse. The recipient&#39;s copy of PGP uses her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally encrypted ciphertext.  
         [0043]    The combination of the two encryption methods combines the convenience of public key encryption with the speed of conventional encryption. Conventional encryption is about a thousand times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distributions are improved without any sacrifice in security.  
         [0044]    A cryptographic key is a value that works with a cryptographic algorithm to produce a specific ciphertext. Keys are basically very large numbers. Key size is measured in bits; the number representing a 1024-bit key is computationally very large. In public key cryptography, the bigger the key, the more secure the ciphertext. However, public key size and conventional cryptography&#39;s secret key size are totally unrelated. A conventional 80-bit key has the equivalent strength of a 1024-bit public key. A conventional 128-bit key is equivalent to a 3000-bit public key. Again, the bigger the key, the more secure, but the algorithms used for each type of cryptography are very different. While the public and private keys are mathematically related, it&#39;s very difficult to derive the private key given only the public key; however, deriving the private key is always possible given enough time and computing power. This makes it very important to pick keys of the right size; large enough to be secure, but small enough to be applied fairly quickly. Larger keys will be cryptographically secure for a longer period of time. Keys are stored in encrypted form. PGP stores the keys in two files on the user&#39;s computing device (see Table 4): one for public keys and one for private keys. These files are called keyrings. If the private keyring is lost, the user will be unable to decrypt any information encrypted to keys on that ring. As with any user generated electronic file, it is advisable for the user to back up these PGP keyrings to floppy disk, Zip disk, or any other appropriate electronic media.  
         [0045]    The invention&#39;s preferred embodiment uses PGP to create digital certificates. Digital certificates (certificates) allow the recipient of information to verify the authenticity of the information&#39;s origin. In other words, digital certificates provide authentication and data integrity. Non-repudiation is also provided. A digital certificate consists of three components:  
         [0046]    A public key  
         [0047]    Certificate information, e.g. patient&#39;s name, patient&#39;s logon user ID, patient&#39;s  
         [0048]    address, etc.  
         [0049]    One or more digital signatures.  
         [0050]    The purpose of a digital signature on a certificate is to attest that the certificate information has been electronically notarized by some other person or entity, e.g. from a trusted third party such as a Certificate Authority, e.g. VeriSign. The digital signature does not validate the authenticity of the whole certificate; it only vouches that the signed identity information goes along with the public key. PGP uses a one-way hash function to create a digital signature. Valid hash functions used in the IETF&#39;s OpenPGP include MD2, MD5, SHA-1 and RIPEMD-160. PGP uses a hash function on the certificate information that is being signed. This generates a fixed length data item known as a message digest. Any alteration to the certificate information results in a totally different message digest (digest), i.e. data integrity is established. PGP then uses the message digest and the private key to create the digital signature. Upon receipt of the certificate, the recipient uses PGP to re-compute the message digest, thus verifying the signature. As long as a secure hash function is used, there is no way to take someone&#39;s signature from one document and attach it to another, or to alter a signed message in any way. The slightest change in a signed document will cause the digital signature verification process to fail.  
         [0051]    In June 2000 the US Congress passed an act (the Electronic Signatures in Global and National Commerce Act) to legally accept digital signatures in electronic transactions. In July 2000 President Clinton signed the Electronic Signatures in Global and National Commerce Act.  
         [0052]    The preferred embodiment uses various trusted parties to create digital certificates. Various formats exist for digital certificates including PGP and the International Telecommunications Union&#39;s (ITU) X.509 certificates. The preferred embodiment of the invention uses PGP certificates, but could easily use X.509 certificates, or other certificate formats. The format of a PGP certificate is as follows:  
         [0053]    The PGP version number—identifies which version of PGP was used to create  
         [0054]    the key associated with the certificate.  
         [0055]    The certificate holder&#39;s public key—public portion of the holder&#39;s asymmetric  
         [0056]    key pair together with the algorithm of the key: RSA, Diffie-Hellman, or  
         [0057]    DSA.  
         [0058]    The certificate holder&#39;s information—e.g. Patient  13  name, Patient  13  logon  
         [0059]    user ID, Patient  13  address, etc.  
         [0060]    The digital signature of the certificate owner—uses the private key of the  
         [0061]    certificate holder&#39;s public key.  
         [0062]    The certificate&#39;s validity period—start date and expiration date.  
         [0063]    The preferred symmetric key method for the key—e.g. Triple-DES, CAST, or  
         [0064]    IDEA.  
         [0065]    SSL has been universally accepted on the Internet 10 for authenticated and encrypted communication between clients and servers. Considering the Open Systems Interconnection (OSI) model, the SSL protocol runs above TCP/IP (transport layer, i.e. layer 4 in the OSI model) and below higher-level protocols such as HTTP or SMTP (presentation and application layers, i.e. layers 6 and 7 in the OSI model). SSL runs in the session layer, layer 5 in the OSI model. It uses TCP/IP on behalf of the higher-level protocols, and in the process allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection. These capabilities address fundamental concerns about secure communication over the Internet  10  and other TCP/IP networks such as the Private Medical Network  9 :  
         [0066]    SSL server authentication allows a user to confirm a server&#39;s identity. SSL-enabled client software running on a computing device can use standard techniques of public-key cryptography to check that a server&#39;s certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the client&#39;s list of trusted CAs.  
         [0067]    SSL client authentication allows a server (e.g. the MD Web Site 30, etc.) to confirm a user&#39;s identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client&#39;s certificate and public ID are valid and have been issued by a certificate authority listed in the server&#39;s list of trusted CAs.  
         [0068]    An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition, all data sent over an encrypted SSL connection is protected with a mechanism for detecting tampering, that is for automatically determining whether the data has been altered in transit.  
         [0069]    The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection. This exchange of messages is designed to facilitate the following actions:  
         [0070]    Authenticate the server to the client.  
         [0071]    Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support.  
         [0072]    Optionally authenticate the client to the server.  
         [0073]    Use public-key encryption techniques to generate shared secrets.  
         [0074]    Establish an encrypted SSL connection.  
         [0075]    For more details on SSL, the Netscape web site provides a wealth of information at http://developer.netscape.com/docs/manuals/security.  
         [0076]    TLS (Transport Layer Security) is a new and evolving Internet Engineering Task Force (IETF) standard and is based on SSL. TLS is defined in RFC 2818 (“HTTP Over TLS”). This invention does not exclude the use of TLS in place of SSL when TLS is adopted on the Internet  10 .  
         [0077]    Using PKI, each of the medical participants is assigned a digital certificate and a digital signature. Information contained in the digital certificate includes the provider&#39;s name, address, phone number(s) and other identifying information. When communicating with the relevant recipient party, this digital certificate is encrypted with the recipient&#39;s public key. Sometimes the recipient does not need to be privy to information contained in the certificate, for example the patient&#39;s social security number (SSN). Using a similar method outlined in U.S. Pat. No. 5,790,677 by Fox et al, this information is encrypted with the public key of the final recipient. For example, the patient&#39;s SSN may be needed when the Pharmacy  11  verifies the patient&#39;s information with the Health Insurer  3 . The patient&#39;s SSN would be encrypted with the Health Insurer&#39;s public key and not the Pharmacy&#39;s public key. Hence only the Health Insurer  3  would be able to decrypt and read this information.  
         [0078]    Before describing any of the processes in detail, note that the preferred embodiment of the invention uses the current state of the art of human-computer-interface (HCI) technology. For example computer systems interact with a person by means of a graphical user interface (i.e. a GUI), which is implemented in a programming language such as C++, Java or C#. Currently computer access control is by means of password or a pass phrase, although the use of biometrics is increasing. The conventional HCI today is by means of a keyboard, a pointing device (e.g. a mouse, touch-screen, etc.) and a monitor. HCI by means of voice recognition, e.g. from Dragon Systems Inc., is available today, but is not easy to use to replace the conventional HCI, but the current invention does not exclude use of this type of HCI technology.  
         [0079]    We now consider the invention&#39;s preferred embodiment in implementing the average process that a Patient  13  undertakes to obtain and fill a medical prescription, as detailed in Tables 1 and 2.  
         [0080]    Patient Appointment Scheduling Process (PAS 50)  
         [0081]    The Patient  13  connects to the Internet  10  using his computing device, e.g. a PC, or Wireless Phone, or Wireless Personal Digital Assistant (PDA such as the Palm or Handspring), etc. These computing devices as described in more detail in Table 4. The Patient  13  connects to the web site  30  of his Medical Doctor  1 . A service provider such as WebMD, an Internet Service Provider (ISP) such as America Online, MSN, etc. could host this web site  30 , or it could be hosted on a computer at the Medical Doctor&#39;s office. Once connected to the doctor&#39;s scheduling web site, the patient logs on. All information transmitted between the Patient  13  and the Medical Doctor  1  is encrypted, e.g. by means of SSL and authenticated using his password or pass-phrase. Ideally the patient&#39;s computing device would transmit his issued doctor&#39;s digital certificate as described in the &#39;677 patent. Alternatively using standard computer security methodologies, the Patient  13  provides his name and other private information, e.g. his Social Security Number&#39;s last four digits and his home ZIP code when logging on. This information is transmitted using SSL and is verified in the doctor&#39;s patient database  5 . After verification, the Patient  13  is presented with a menu of options, including the means to schedule an appointment. Today many companies provide the means to view and schedule appointments via the Internet  10 . Examples include Yahoo! Calendar (calendar.yahoo.com/), iPlanet&#39;s Calendar Server product, etc.  
         [0082]    The Patient  13  is presented with available appointment times for his doctor  1  via a GUI, either web based or client software based using a language such as Java or C#. The preferred embodiment uses a web based calendaring system. The doctor&#39;s appointment schedule is kept in a database  31  at the MD Web Site  30 , as well as at her medical office in the master schedule database  20 . The scheduling calendar system automatically retrieves the relevant doctor&#39;s schedule based on information obtained by looking up the patient&#39;s doctor on record in the patient database  5 . Note that it is fairly common for doctors to have multiple offices within her practice, e.g. for discussion purposes, let us consider two medical offices. Hence a patient could schedule an appointment in either of the doctor&#39;s medical offices. Typically, both doctor&#39;s offices would have their own patient scheduling database  5 . This invention implements a snap shot (i.e. patient to doctor relationship) of this database  5  at the MD Web Site  30 . In the case of multiple doctor&#39;s offices, the web site  30  snapshot merges the two scheduling databases. Furthermore, usually there is more than one Medical Doctor  1  in a doctor&#39;s office and hence the doctor&#39;s patient database  5  knows which doctor  1  that the Patient  13  uses. The Patient  13  selects an appropriate date and time for an appointment and where appropriate, the relevant office location as well.  
         [0083]    Note that the doctor&#39;s displayed schedule contains information on her complete schedule, including vacations, conferences, etc. The related dates are simply made unavailable. No detailed information is revealed to the Patient  13 , e.g. whether or not an unavailable date is because the doctor  1  is on vacation, or because her schedule is full seeing other patients. All that the Patient  13  needs to know is on what dates and times he can see the doctor  1 .  
         [0084]    The PAS  50  GUI then presents the Patient  13  with a choice of how he wishes to be contacted for confirmation of the appointment, as well as in the event that the appointment needs to be rescheduled. The Patient  13  can enter his work, home, etc. email address; his work, home, etc. phone number; his pager number; his cell phone number, etc. The patient record database  5  contains the default method of contact and automatically displays this choice in the pick list to the Patient  13 . When scheduling the appointment the Patient  13  is prompted to enter information regarding the nature of the appointment, e.g. annual check-up, frequent headaches, etc. The PAS  50  system allows the Patient  13  to download the scheduled appointment into his personal information manager&#39;s calendar, i.e. into Microsoft Outlook on a PC, the Date Book on a Palm, etc. Various computer data synchronization techniques are available today including the Palm-PC HotSynch Manager from 3COM and the Bluetooth wireless technology. After the Patient  13  has completed setting up his doctor&#39;s appointment, he logs off from the doctor&#39;s web site  30 .  
         [0085]    In the doctor&#39;s office, a staff member usually consults the doctor&#39;s appointments. A number of various options are possible in implementing this step. For example, the staff member could log onto the doctor&#39;s scheduling web site  30  and review all scheduled appointments. This method requires that there is a reliable connection from the Medical Doctor  1  to the Internet  10 . Unfortunately today this is not always the case. Alternatively the preferred embodiment of the invention has implemented a distributed database system. This method has the doctor&#39;s scheduling web site  30  exchange new information with the doctor&#39;s master scheduling database  20  located at the doctor&#39;s office. Hence, a consistently reliable Internet  10  connection is not necessary. The invention&#39;s preferred embodiment has implemented a pull method, i.e. a computer at the doctor&#39;s office logs onto the Internet  10 , or via the Private Medical Networks  9 , and checks for any new scheduling information. This pull step could be scheduled to be triggered by time, e.g. every 30 minutes, or the doctor&#39;s scheduling web site  30  could send, e.g. via email, an encrypted message to the doctor&#39;s master scheduling database  20  computer that new scheduling information is available for downloading. Alternatively, the doctor&#39;s scheduling web site  30  could simply push new information to the doctor&#39;s scheduling database  20  computer. Once the doctor&#39;s staff has the latest information she can send a verification notice to the Patient  13 . The invention&#39;s preferred embodiment&#39;s verification methodology has the medical staff member checking off the scheduled appointment on the PAS  50  system and the system sends the relevant verification message to the Patient  13 . Patient requested verification messages sent via email or to a pager are fairly common today. On the other hand if the Patient  13  has requested that a message is to be called into a phone number, the preferred embodiment&#39;s doctor&#39;s computer generates a digital voice message that is transmitted over the dialed phone number. The tried and tested fail-safe method of a doctor&#39;s staff member picking up the phone and calling the Patient  13  is always available. There are occasions when the Medical Doctor  1  needs to reschedule the patient&#39;s appointment. All the doctor  1  needs to do is modify the patient&#39;s appointment in his scheduling database. The system would then send a message via the patient&#39;s preferred verification method. The patient appointment scheduling process (PAS  50 ) as described above would then be repeated.  
                         TABLE 3                           Patient Messaging            Notification           Method   Description               1. Email   Electronic mail (email) message to is sent to the Patient&#39;s           registered email address. Today email would be primarily           received at home or at work on a computing device (see           Table 4).       2. Wireless   This is a wireless phone with Internet capabilities, such as       SmartPhone   accessing web pages, email, etc. Current examples include           the Kyocera QCP 6035 and the Samsung SPH-I300.       3. Wireless   Standard wireless phone using the standard technologies of       Phone   the day, e.g. GSM, CDMA, TDMA, etc. Both voice           messages and these cell phones can receive text messages.       4. Pager   Today pagers can receive numeric and/or text messages.           The preferred embodiment uses text pagers to contact           patients. Examples of pagers include various Motorola           devices such as the PF 1500, T350 and the CP1250.       5. Phone-   Many people have answering machines at home and at the       voice   office. A voice message can consequently be left on the       message   relevant device.       6. Phone-   Manual messages can be called in as well, i.e. person-to-       manual   person, rather than to a computing device.                  
 
         [0086]    [0086]                             TABLE 4                           Computing Devices                Computing               Device   Description                       PC   Personal Computer, e.g. Microsoft               Windows, Apple, Linux, etc.           PDA   Personal Digital Assistant, e.g. the Palm,               the Handspring, the Revo from Psion, etc.               Communications for a PDA is via a               docking station connected to a PC, or via a               wireless modem or phone. PDA&#39;s can               connect to a Local Area Network via               wireless, e.g. using the 802.11b or               Bluetooth communications.           Wireless   Technology continues to evolve wireless           Phone   phone into the capability of accessing               computer based information systems. For               example, the Motorola i85s can run certain               Java applets. These devices are also               generically known as Smart Phones.           Internet   The devices are specific for accessing the           Appliance   Internet, i.e. not being able to run the               normal slew of PC programs. Examples of               these devices include the Audrey from               3COM, the iPAQ from Compaq, etc.                        
         [0087]    Patient Medical Prescription Process (PMP  51 )  
         [0088]    This process begins with the Patient  13  meeting with his Medical Doctor  1  at the scheduled date and time as determined during PAS  50 . When the doctor  1  is ready to write out a prescription for the Patient  13 , she would access the patient&#39;s medical record database  5  on her computer, or some other electronic device that can access this database  5  (e.g. a wireless PDA, Tablet PC, etc. using wireless LAN technology such as 802.11b, Bluetooth, etc.). The doctor  1  is presented with a choice of medications that are available to the Patient  13  through his Health Insurer  3  or related PBM  2 . Today this information is rarely available to a Medical Doctor  1  when prescribing medication for a Patient  13  and is usually only available at the Pharmacist  11 , who contacts the PBM  2 , if one is provided by the patient&#39;s health plan. If for example, the patient&#39;s Health Insurer  3  does not cover the doctor&#39;s preferred medication, then this medication would not be selectable by the doctor  1 , but will be visually available with a pertinent note. Furthermore, because the patient&#39;s health insurance plan coverage is available to the doctor  1 , she can quickly tell whether or not any necessary medical procedures are covered by the patient&#39;s Health Insurer  3  and hence can make an informed and timely decision for the treatment of the Patient  13 .  
         [0089]    A master list of available medications, by Health Insurer  3  plan and where maintained by the Pharmacy Benefit Manager  2 , is kept in the doctor&#39;s patient database  5 . As in the case of the appointment schedules, the preferred embodiment implements a distributed database scheme. In this implementation, the Health Insurer  3  database  7  sends plan information to the Medical Doctor&#39;s patient database  5  either via the Private Medical Network  9  or via the Internet  10 . The reason that the preferred embodiment uses this implementation is once again to reduce the risk that the doctor&#39;s and the Health Insurer&#39;s Internet connections could be unavailable at the moment the doctor needs the relevant information. A note about the Pharmacy Benefit Manager&#39;s (PBM) interaction, rather than having to electronically interact with another service provider, the preferred embodiment has the PBM&#39;s medication&#39;s database  6  synchronize with the Health Insurer&#39;s medication database  7 . Hence the Medical Doctor  1  only needs to synchronize with the Health Insurer&#39;s database  7 ; both for the patients&#39; health plan coverage and covered medications. On the other hand, to those versed in the art, it is obvious that direct interaction between the Medical.Doctor&#39;s database  5  and the PBM&#39;s database  6  is feasible as well.  
         [0090]    For reliable Internet connections, the doctor  1  could simply log on to the Health Insurer&#39;s patient database  7  via the Internet  10 , or via the Private Medical Network  9 , using SSL or a Virtual Private Medical Network (VPN). The objective behind the invention is to provide secure, timely and reliable accessibility to needed Patient  13  medical information.  
         [0091]    The doctor  1  then inquires from the Patient  13  which Pharmacy  11  he wishes to use to fill the prescription. The doctor  1  selects the relevant Pharmacy  11  from a pick list presented to her on the computer. If the patient&#39;s preferred Pharmacy  11  is not on the available pharmacies pick list, the doctor  1  can type the relevant information into the PMP  51  system, which automatically checks to see if the entered Pharmacy  11  subscribes to the Electronic Prescription Filing System (EPFS).  
         [0092]    The doctor  1  selects the relevant medication from the medications&#39; option list and selects the “Write Prescription” option on her computer. The doctor&#39;s computer and software generates a digital certificate for the relevant pharmacy  11 , which includes all the relevant prescription information. PKI prompts the doctor  1  to digitally sign the certificate, which she does by entering a secret pass phrase. Alternatively the digital signature could be based on biometrics, e.g. a fingerprint, or retina-scan. The preferred embodiment implements digital signatures by means of a secret pass phrase. To those versed in the art, it is obvious that biometrics or another scheme could be used to uniquely identify the doctor&#39;s authority. Furthermore, as computer human voice recognition evolves into a more usable system, all this information could be entered into the system via voice commands, rather than via a keyboard and mouse. The preferred embodiment uses available human-computer interface technology, i.e. keyboard and mouse. The doctor&#39;s PMP  51  system stores a copy of the prescription in the patient database  5  and then transmits the encrypted medical prescription, i.e. prescription digital certificate to the patient&#39;s Pharmacy  11 , either via the Private Medical Network  9 , or via the Internet  10 . The prescription has now entered the doctor-pharmacy medical prescription process (DPP  52 ).  
         [0093]    Doctor-Pharmacy Medical Prescription Process (DPP  52 )  
         [0094]    The prescription order message format between the doctor  1  and the Pharmacy  11  could be an email (e.g. formatted in the Extensible Markup Language [XML] standard), a direct connect to the pharmacy&#39;s prescription order database  12 , or web site. Because Internet email is currently a relay system and there is no guarantee of timely delivery, the preferred embodiment implements this step as a direct, secure connection to the pharmacy&#39;s prescription order web server. The doctor&#39;s PMP  51  system automatically and securely logs on to the pharmacy&#39;s web server using it&#39;s authorized pharmacy logon, e.g. via SSL. Once the Pharmacy  11  has verified the doctor&#39;s PMP  51  system&#39;s access, it receives the new prescription order and places it in its database  12 . The prescription order has now entered the pharmacy&#39;s prescription order system (POS  53 ).  
         [0095]    Pharmacy Prescription Order System (POS  53 )  
         [0096]    The pharmacy&#39;s prescription order system (POS  53 ) electronically verifies the following information:  
                   TABLE 5                       Step   Verification Process                   1   The Medical Doctor&#39;s digital certificate information, including, but           not limited to the doctor&#39;s digital signature, medical practitioner           ID, contact address and phone number, etc.       2   The patient&#39;s Heath Insurer 3 ID, the patient&#39;s pharmacy database 6           record, address, contact information, etc.       3   The availability and Heath Insurer 3 coverage for the patient&#39;s           prescribed medications(s).       4   If the Patient 13 chose to pay by credit card, the patient&#39;s credit           card information is verified. The patient&#39;s credit card information           can be entered at the doctor&#39;s office, prior to transmission of the           electronic prescription. Alternatively, the patient&#39;s credit card           information could be on record in the pharmacy&#39;s patient database           12.                  
 
         [0097]    Once the POS  53  has verified all of the above information, i.e. Steps (1) through (4) in Table 5, the pharmacist is notified on his computing device (see Table 4 for examples) to fill the new prescription order.  
         [0098]    On the other the hand, if a problem arises during the verification process, the pharmacist is notified of the problem on his computing device in order to resolve the problem. A more sophisticated implementation of the POS  53 , electronically contacts the relevant party of the discovered problem. For example, if the doctor&#39;s PMP  51  system were not able to verify that the prescribed medication was covered by the patient&#39;s Health Insurer  3 , and the Pharmacy  11  POS  53  was able to confirm that the medication is not covered for the Patient  13 , then this status would be relayed back to the Medical Doctor  1 . Preferably, this relaying of information would be done through the doctor&#39;s PAS  50  system, or via encrypted email to comply with patient privacy and HIPAA. The Medical Doctor  1  can then take the appropriate action, i.e. possibly returning to the PMP  51  and PAS  50  systems.  
         [0099]    Filled Prescription Delivery (FPD  54 )  
         [0100]    Once the Pharmacy  11  has filled the prescription order, the pharmacist checks off the prescription order status in the POS  53 . The POS  53  then checks to see how the Patient  13  requested to obtain the prescription, e.g. the Patient  13  may have requested that the prescription be:  
         [0101]    (a) Delivered to his home or place of work,  
         [0102]    (b) Made available at the pharmacist&#39;s drive-through facility, or  
         [0103]    (c) Contacted for collection at the pharmacy&#39;s pickup desk.  
         [0104]    In the case (a) for delivery, the POS  53  securely forwards the relevant information to the pharmacy&#39;s shipping department. The shipping department could be the pharmacist&#39;s online web facility, for example such as CVS&#39;s online prescription web site at ww.cvs.com/promotion/rxeasy.  
         [0105]    In the case (b) where the Patient  13  will pick up the filled prescription from the pharmacy&#39;s drive-through facility, the P 0 S  53  securely forwards the relevant information to the Pharmacy  11  packing department.  
         [0106]    In the case (c) where the Patient  13  will pickup the filled prescription from the Pharmacy  13 , the POS  53  contacts the Patient  13  by means of how the Patient  13  requested notification for a filled prescription. Examples of this notification means includes, email (to a patient&#39;s home, cell phone, pager, wireless PDA, etc.), a message to a paging system, a voice message to a phone number, etc.  
         [0107]    A note about other possible features of the POS  53 , in the invention&#39;s preferred embodiment the system prints the relevant prescription&#39;s bottle&#39;s label and other pertinent information for the Patient  13 , e.g. medication instructions, side effects, etc.  
         [0108]    Prescription Refill Process (PRP  60 )  
         [0109]    Often a medical prescription is not filled in total the first time that the Pharmacy  11  receives a prescription order. Prescription refills are part of the order. Sometimes the Medical Doctor  1  has approved a certain number of refills. On the other hand, the refills may have run out and the Patient  13  may continue to need prescribed medication. Both of these prescription refill scenarios are now discussed.  
         [0110]    (a) Prescription Refills Available:  
         [0111]    In the case where the prescription has a certain number of refills, say four for example, and then the pharmacy&#39;s patient database  12  has a record of this information. When the Patient  13  needs to obtain a refill on his prescription, the invention&#39;s PRP  60  offers a number of methods to fill the prescription refill.  
         [0112]    In the first case, the medication is taken on a fixed time schedule and hence the pharmacy&#39;s patient database  12  can predict when the Patient  13  will need a refill. In this case the PRP  60  system can execute any of the following scenarios, as requested by the Patient  13 :  
         [0113]    1. A refill notification  60   a  is sent to the Patient  13 . Refer to Table 3 for the various patient notification options. When the Patient  13  receives the notification  60   a,  he responds to either fill the prescription or not to fill the prescription. If the notification message is electronic, the preferred embodiment provides a simple interface that automatically accesses the Pharmacy Web Site  40  when the Patient  13  responds. For example, email messages can be sent and received in HTML (Internet Hypertext Markup Language) format and hence the relevant URL (Internet Universal Resource Locator) can be embedded in the email&#39;s responses. If the response is affirmative, then the PRP  60  places the patient&#39;s prescription order into the pharmacy&#39;s Prescription Order System (POS  53 ).  
         [0114]    2. Automatic refill requests that do not require any verification by the Patient  13 . In this scenario the PRP  60  automatically places  60   b  the patient&#39;s prescription order into the pharmacy&#39;s Prescription Order System (POS  53 ). The Patient  13  is sent notification (see Table 3) that his prescription is being refilled.  
         [0115]    The POS  53  (see above detailed description) processes the refill order and then forwards the filled prescription to the pharmacy&#39;s Filled Prescription Delivery (FPD  54 , see the above section for a more detailed description) system in order to get the refill to the Patient  13 .  
         [0116]    In the second case, where the pharmacy&#39;s database  12  cannot predict when the patient&#39;s prescription will run out, the Patient  13  initiates the PRP  60 . In this case the Patient  13  securely logs on to the pharmacy&#39;s prescription web site  40  using his computing device (see Table 4). Note that even though in FIG. 1 the pharmacy&#39;s prescription web site  40  is shown to be separate from the Pharmacy  11 , the current invention does not exclude the possibility that both the Pharmacy  11  and the pharmacy&#39;s prescription web site  40  are co-located for Internet  10  access. Once the Patient  13  has been authenticated, he selects the option to order a prescription refill. The PRP  60  system securely, e.g. using SSL, displays all relevant information to the patient, including whether or not the Patient  13  wishes to pay for the refill online. When the Patient  13  is done with ordering his prescription refill, he logs off of the pharmacy&#39;s prescription web site  40 . In this second case the PRP  60  system places the patient&#39;s prescription order into the pharmacy&#39;s Prescription Order System (POS  53 ). The POS  53  (see above detailed description) processes the refill order and then forwards the filled prescription to the pharmacy&#39;s Filled Prescription Delivery (FPD  54 ) system in order to get the refill to the Patient  13 .  
         [0117]    To those versed in the art, it is obvious that it is possible for the Patient  13  to securely log on to the pharmacy&#39;s patient database  12  and access the pharmacy&#39;s Prescription Order System (POS  53 ) directly without having to go via the pharmacy&#39;s prescription web site  40 . The invention&#39;s preferred embodiment provides access to the POS  53  via the pharmacy&#39;s prescription web site  40 , but does not exclude an implementation involving direct, secure POS  53  access via the Internet  10 .  
         [0118]    (b) Prescription Refills Unavailable:  
         [0119]    In this scenario, the Patient  13  needs to contact his Medical Doctor  1 , who then needs to initiate the PRP  60 . The preferred embodiment has the Patient  13  securely logging on to the MD Web Site  30 . Once authenticated, the Patient  13  selects the “Refill Prescription” that the PAS  50  system displays to him. The PAS  50  system forwards the patient&#39;s request the doctor&#39;s patient database  5 . Refer to the section on PAS  50  for a more detailed description of this process.  
         [0120]    The doctor&#39;s patient database  5  notifies the Medical Doctor  1  that her Patient  13  has requested a prescription refill. A number of options are available to the doctor  1 :  
         [0121]    1. The Medical Doctor  1  can deny the request.  
         [0122]    2. The Medical Doctor  1  can approve the request.  
         [0123]    3. The Medical Doctor  1  can schedule to discuss the request with the Patient  13 .  
         [0124]    In the first case i.e. a denial of the request, the PMP  51  system sends a notification (see Table 3) to the Patient  13 . In the second case the prescription refill order is forwarded to the DPP  52  system and the Patient  13  is notified (see Table 3). In the third case the Patient  13  is notified (see Table 3) to either contact the doctor  1 , or to schedule an appointment to see the doctor  1 .  
         [0125]    Other Uses of the Invention  
         [0126]    Even though the invention&#39;s preferred embodiment does not discuss other uses in detail, it is obvious to one versed in the art what a secure, trusted and easy to use medical patient system can offer, besides that which is described in detail above. A quick review of one of these applications is now discussed:  
         [0127]    Medical Supplies:  
         [0128]    Today the doctor&#39;s medical assistant orders supplies through a catalog, which is mailed the medical office. There are different suppliers for different items. For example, medical supplies like instruments are ordered from a surgical supplier over the fax. Other supplies are ordered sometimes from local vendors over the telephone. This includes items such as Betadine, cotton swabs, paper products. Using the invention&#39;s preferred embodiment, the medical assistant would receive either copy of the Medical Supplier&#39;s  4  catalog, which is stored on the disk drive at the medical office&#39;s computer, or the medical assistant would connect to the Medical Supplier&#39;s  4  web site to browse the catalog online. The medical assistant then places an order for the required medical supplies either via the Medical Supplier  4  web site, or by means of an email sent to the Medical Supplier  4 . As described above in Cryptography for Verification, Integrity and Confidentiality, the supply order request would be encrypted appropriately. Payment for the medical supplies could be included in the order by using a digital certificate bearing appropriate credit card information, or the Medical Doctor&#39;s  1  account with the Medical Supplier  4  could be billed.