Patent Publication Number: US-2013246081-A1

Title: Systems and Methods for Supplementing Patient and Provider Interactions to Increase Patient Adherence

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application claims the benefit of United Stated Provisional Application Ser. No. 61/635,613, filed Apr. 19, 2012, and United Stated Provisional Application Ser. No. 61/611,942, filed Mar. 16, 2012, the entireties of which are hereby incorporated by reference. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates generally to systems and methods for supplementing patient and provider interactions, and specifically to systems and methods for electronically enhancing patient and provider interactions using supplemental programs in response to an electronic prescription request to increase patient adherence. 
     BACKGROUND OF THE INVENTION 
     Poor patient adherence is a major concern within the health care industry. After visiting their health care provider and receiving at least one prescription for substances, many patients fail to maintain a level of dedication and adherence to their prescribed substances. This results in increased costs to all parties involved in the health care industry, including, but not limited to the patient, the health care provider, the pharmacies, the pharmaceutical companies, and the health insurance companies. There are currently many methods used with the goal of increasing patient adherence, such as, the distribution of patient educational material, coupons, and patient reminder services. However, there still remains a need for a system that can better utilize these methods to increase patient adherence. 
     One important element to increasing patient adherence is good health care provider-patient interaction. Because this interaction takes place at the point-of-care while the patient is thinking about their current physical state, this interaction is crucial for facilitating patient health, awareness, and adherence. However, there is currently not a system that allows for a health care provider to be fully aware of whether their patient&#39;s are adhering to their prescriptions, while the patients are at the point-of-care. Further, the current methods of increasing patient adherence through educational and financial incentives require the health care provider to not only know whether or not their patient&#39;s are adhering to their prescribed substances, but also requires the health care provider to have the specific education material and coupons/discounts for each patient&#39;s specific diagnoses and prescribed substances at the point-of-care. This is overly burdensome and practically impossible for a health care provider who has patients with a wide variety of health care needs. Therefore, there is also a need for a system that can more easily and efficiently distribute patient educational materials, coupons, and other supplemental programs at the point-of-care. 
     Additionally, pharmaceutical companies are restricted in the number of coupons and other incentives they may distribute. Currently, the coupons and other incentives are distributed to patients without taking into consideration whether the patient receiving the coupon or other incentive needs or will be incentivized by them. Therefore, there also remains a need for a system that can aid pharmaceutical companies in distributing coupons and other incentives to their customers in a more efficient manner. 
     SUMMARY OF THE INVENTION 
     The systems and methods described herein help to fill the needs and solve the issues described above. 
     According to one embodiment, the present invention is directed to a method of supplementing an electronic prescription issued by a health care provider, the method comprising: a) receiving, on a computer apparatus, electronic prescription data generated by a health care provider for a patient for a prescribed substance; b) the computer apparatus determining, from a plurality of available supplemental programs stored on one or more databases, supplemental programs for which the patient is eligible based on the electronic prescription data; c) presenting to the health care provider, in a display device, a list of the eligible supplemental programs, each of the eligible supplemental programs being selectable and de-selectable by the health care provider in the display device; and d) the computer apparatus activating each supplemental program from the plurality of available supplemental programs that have been selected and confirmed by the health care provider in the display device. 
     According to another embodiment, the present invention is directed to a method of supplementing an electronic prescription issued by a health care provider, the method comprising: a) a supplemental program module determining, from program data relating to a plurality of available supplemental programs stored on a program database, supplemental programs for which the patient is eligible based on receipt of electronic prescription data generated by a health care provider for a patient for a prescribed substance via an electronic prescription module; b) presenting to the health care provider, in a display device concurrently with an electronic prescription interface generated by the electronic prescription module, a list of the eligible supplemental programs, generated by the supplemental program module, each of the eligible supplemental programs being selectable and de-selectable by the health care provider in the display device; c) the supplemental program module generating an activation request for each of the eligible supplemental programs that have been selected and confirmed by the health care provider in the display device; and d) the supplemental program module activating each supplemental program from the plurality of available supplemental programs for which an activation request is received. 
     According to yet another embodiment, the present invention is directed to a non-transitory computer-readable storage medium encoded with instructions which, when executed on a processor, perform a method comprising: a) determining, from a plurality of available supplemental programs stored on one or more databases, supplemental programs for which a patient is eligible based on electronic prescription data that is received; b) presenting to the health care provider, in a display device, a list of the eligible supplemental programs, each of the eligible supplemental programs being selectable and de-selectable by the health care provider in the display device; and c) activating each supplemental program from the plurality of available supplemental programs that have been selected and confirmed by the health care provider in the display device. 
     According to yet another embodiment, the present invention is directed to a computer system for supplementing an electronic prescription issued by a health care provider, the computer system comprising: a processor; a memory device; a network interface; a display device; an input device; and instructions residing on the storage unit, which when executed by the processor, causes the processor to: a) determine, from a plurality of available supplemental programs stored on the memory device, supplemental programs for which a patient is eligible based on electronic prescription data that is received; b) presenting to the health care provider, in the display device, a list of the eligible supplemental programs, each of the eligible supplemental programs being selectable and de-selectable by the health care provider via the input device; and c) activating each supplemental program from the plurality of available supplemental programs that have been selected and confirmed by the health care provider in the display device via the input device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention, will become more fully understood from the detailed description and the accompanying drawings, wherein: 
         FIG. 1  is a schematic diagram of a system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 2  is a schematic diagram of a health care provider system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 3  is a schematic diagram of an electronic prescription system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 4  is a schematic diagram of a supplemental program system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 5  is a schematic diagram of a plurality of third party program vendors for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 6  is a schematic diagram of a pharmacy system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 7  is a schematic diagram of payor system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIGS. 8   a - 8   c  is a flow chart of a system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 9  is an illustration of a combined educational material and coupon document according to one embodiment of the present invention; 
         FIGS. 10-15  are screen shots of graphical user interfaces used for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention; 
         FIG. 16  is a flow diagram of a method of acquiring patient medication history data according to an embodiment of the present invention; 
         FIGS. 17-28  are event diagrams of methods for supplementing patient and provider interactions to increase patient adherence according to embodiments of the present invention; and 
         FIG. 29  is a schematic diagram of a system for increasing patient adherence through the activation of supplemental programs according to one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. 
     System Overview 
     Referring to  FIG. 1 , a schematic diagram of a system  1000  for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention is illustrated. Generally, the system  1000  comprises a health care provider (HCP) system  100 , an electronic prescription (EP) system  200 , a supplemental program (SP) system  300 , at least one third party program vendor  400 , a pharmacy system  500 , and a payor system  600  all in operable communication with one another to form a wide area network (WAN). 
     As exemplified by  FIG. 1 , the components of the system  1000  are in operable communication via the internet. However, the invention is not so limited and other electronic communication means may be utilized, such as a satellite network, a cellular network, a common carrier network(s), Wi-Fi, WiMAX or any combination thereof. Further, it should be noted that operable communication includes any means of electronic communication, such as but not limited to wired and wireless electronic communication, in which data can be transmitted and received between the systems and modules of the system  1000 . Moreover, it should also be noted that operable communication includes both direct and indirect communication, as well as bi-directional communication between the systems and modules of the system  1000 . 
     As discussed in more detail below, the system  1000  of the present invention may be configured in other ways. Therefore, it should be noted that the invention is not limited only to those configuration explicitly described herein and, in alternate embodiments the system  1000  may take on other configurations and/or layouts. For instance, any of the systems and/or modules of the system  1000  may be connected via a local area network (LAN). For example, according to one embodiment of the present invention, the EP system  200  and the SP system  300  reside on the same LAN, and therefore, may communicate via Ethernet and/or Wi-Fi over a LAN. 
     Referring to  FIG. 2 , a schematic diagram of an HCP system  100  according to one embodiment of the present invention is illustrated. The HCP system  100  comprises a server  110 , a terminal  120 , and a printer  130  in operable communication. Further, as discussed in more detail below, the HCP system  100  may also be said to comprise at least one health care provider  101 . Although exemplified as comprising the above components, the HCP system  200  may comprise any number, more or less, of the components listed above. For example, a particular HCP system  100  may comprises a plurality of providers  101 , a plurality of servers  110 , a plurality of terminals  120 , and/or a plurality of printers  130 . 
     Generally, the HCP system  100  is an institution or organization that provides general and/or specific health care for those in need. For example, an HCP system  100  may be an entire hospital or health care system, a specialized practice group within a larger hospital or health care system, a private general practice, or a private specialized practice. The health care provider  101  may be a medical doctor, a nurse practitioner, or a staff administrator who is authorized to issue prescriptions. As noted above, the HCP system  100  may comprise any number of providers  101 , and a particular provider  101  may be associated with more than one HCP system  100  at any given time. 
     The server  110  of the HCP system  100  comprises a properly programmed processor (or central processing unit (CPU))  111 , a network interface  112 , and a memory device  113  all in operable communication. It should be noted the processor  110  may be considered the processor of the HCP system  100 . Further, although exemplified as a single server  110 , the invention is not so limited and in alternate embodiments the HCP system  100  may comprise any number of servers  110 . Additionally, although not exemplified, it should be understood that the processor  111  can have integrated memory. The network interface  112  connects the server  110  to the over systems and modules of the system  1000  via the internet. The properly programmed processor  111  of the HCP system  100  effectuates the performing of the processes and functions described below, including but not limited to, the storage of data to the memory  113  of the HCP system  100 , the performance of the processes and functions of a thin-client portion of an electronic prescription (EP) module  203  and a supplemental program (SP) module widget  302 , and the transfer (transmission and receipt) of data from HCP system  100  to the other systems and modules of the system  1000 . 
     In the exemplified embodiment, the memory  113  comprises the thin-client portion of the EP module  203  and the SP module widget  302 , both of which are described in more detail below. Although exemplified as a single memory unit, it should be noted that the memory  113  may comprise any number of databases used to store data, modules, or other information. For example, the memory may be used to store provider information, patient information, prescribed substance information, and appropriate software to allow the provider  101  to interact with the thin-client portion of the EP module  203  and the SP module widget  302 . 
     Although exemplified as part of the memory  113 , in other embodiments the thin-client portion of the EP module  203  may reside elsewhere on the HCP system  100  or on another system altogether. Further, in the exemplified embodiment the SP module widget  302  is integrated into the thin-client portion of the EP module  203 . However, it should be noted that the invention is not so limited and in alternate embodiments, any portion of the SP module may be integrated into any portion of the EP module. Further, in one embodiment of the present invention, the SP module is not integrated with the EP module, but is rather a completely separate module altogether. 
     The terminal  120  of the HCP system  100  may be a personal computer (PC) or a mobile electronic unit. Each terminal  120  of the HCP system  100  comprises a properly programmed processor (not shown), a memory device (not shown), a power supply (not shown), a video card (not shown), a display device  121 , firmware (not shown), software (not shown), a network interface (not shown) and a user input device  122  (e.g., a keyboard, mouse and/or touch screen). Although not exemplified, it should be understood that the processor of the terminal  120  can have integrated memory. The properly programmed processor of the terminal  120  is configured to effectuate the processes and functions described below, including, but not limited to the effectuation of the graphical user interfaces (GUI) for display on the display device  121  of the terminal  120  for the provider  101  and the transmission of user inputs from the provider  101  via the input device  122  to the other systems and modules of the system  1000 . 
     As discussed in more detail below, after the provider  101  generates a prescription for a substance using the thin-client portion of the EP module  203 , the electronic prescription is transmitted by the HCP system  100  to the pharmacy system  500  for processing. Further, as also discussed in more detail below, at any point during the prescription writing processes using the EP module  203 , the SP module widget  302  may receive electronic prescription data relating to the electronic prescription and transmits the electronic prescription data to the to the SP system  300  for further processing. 
     Referring to  FIG. 3 , a schematic diagram of an EP system  200  according to one embodiment of the present invention is illustrated. Generally, the EP system  200  comprises a server  210  which comprises a properly programmed processor (CPU)  211 , a network interface  212 , and a memory unit  213  in operable communication. It should be noted that the processor  211  may be considered the processor of the EP system  200 . Further, although exemplified as a single server  210 , the invention is not so limited and in alternate embodiments the EP system  200  may comprise any number of servers  210 . Additionally, although not exemplified, it should be understood that the processor  211  can have integrated memory. The network interface  212  connects the server  210  to the over systems and modules of the system  1000  via the internet. 
     As discussed in more detail below, the processor  211  of the EP system  200  effectuates the performance of the processes and functions described herein, including but not limited to the performance of the processes carried out by the central portion of the EP module  202 , the storage of data to the EP database  201 , and the transfer of data between the EP system  200  and the other systems and modules of the system  1000 . 
     The memory  213  of the EP system  200  comprises an electronic prescription (EP) database  201  and a central portion of the electronic prescription (EP) module  202 . The EP database  201  stores information relating to electronic prescriptions that are generated using and effectuated by the EP module, such as, but not limited to, provider data, patient data, prescribed substance data, payor data, and patient medication history data. Further, although exemplified as a single memory unit, it should be noted that the memory  213  may comprise any number of databases used to store data, modules, or other information. 
     Generally, the EP module is one or more computer programs configured to allow a provider  101  to generate and transmit electronic prescriptions to the pharmacy system  500 . In embodiments where the EP module comprises a central portion  202  and a client portion  203 , the central portion  202  is configured to do most of the heavy processing of the EP module. Further, in such embodiments, the client portion  203  is a thin-client portion that dues light processing and generates/displays user interfaces for the provider  101  on the display device  121  of their terminal  120 . 
     As used herein, the central portion  202  and the thin-client portion  203  of the EP module may be collectively defined as the “EP module.” Although exemplified as comprising a thin-client portion  203  that resides within the memory  113  of the HCP system  100  and a central portion  202  that resides within the memory  213  of the EP system  200 , the EP module is not so limited. In alternate embodiments, the central portion  202  of the EP module may reside elsewhere on the system  1000  or be combined with the thin-client portion  203  of the EP module and reside on any of the systems of the system  1000 . In embodiments where the central portion  202  and the thin-client portion  203  are combined, the provider  101  may access the EP module via a web interface (portal) or an applicant user interface using their terminal  120 . One non-limiting example of an EP module is Rcopia® by DrFirst®. 
     Referring to  FIG. 4 , a schematic diagram of a SP system  300  according to one embodiment of the present invention is illustrated. Generally, the SP system  300  comprises a server  310  which comprises a properly programmed processor (CPU)  311 , a network interface  312 , and a memory unit  313  in operable communication. It should be noted that the server  310  may be considered the supplemental program server and the processor  311  may be considered the processor of the SP system  300 . Further, although exemplified as a single server  310 , the invention is not so limited and alternate embodiments the SP system  300  may comprise any number of servers  310 . Additionally, although not exemplified, it should be understood that the processor  311  can have integrated memory. The network interface  312  connects the server  310  to the over systems and modules of the system  1000  via the internet. 
     As discussed in more detail below, the processor  311  of the SP system  300  effectuates the performance of the processes and functions described herein, including but not limited to the performance of the processes carried out by the central portion  301  of a supplemental program (SP) module (e.g., the determination of eligibility performed by the SP module, the transfer of content to a patient or the HCP system  100 , the enrollment of a patient into a service, etc.), the storage of data to a supplemental program database  303  and a record database  304 , and the transfer of data between the SP system  300  and the other systems and modules of the system  1000 . 
     The memory  313  of the SP system  300  comprises a central portion of the SP module  301 , a supplemental program database  303 , and a records database  304 . Although exemplified as a single memory unit, it should be noted that the memory  113  may comprise any number of databases used to store data, modules, or other information. As used herein, the central portion  301  and the widget  302  of the SP module may be collectively defined as the “SP module.” 
     Generally, the SP module is one or more computer programs configured to determine, from a plurality of available supplemental programs, specific supplemental programs for which a patient is eligible. Further, as also discussed in more detail below, the SP module is configured to, among other things: (1) receive electronic prescription data generated by a provider  101  for a patient for a prescribed substance from either the FICP system  100 , the EP module, or the EP system  200 ; (2) retrieve patient data, prescribed substance data, provider data, and/or payor data from one or more databases of the system  1000 ; (3) determine, from a plurality of available supplemental programs, specific supplemental programs for which a patient is eligible; (4) determine delivery modes that are available for each supplemental program in which the patient, is eligible; (5) generate graphical user interfaces (GUIs) that are displayed to the provider  101  on the display device  121  of the HCP system  100 ; (6) receive inputs from the provider  101  via the input device  122  of the HCP system  100 ; (7) generate an activation signal for each supplemental program that is selected by the provider  101 ; (8) receive the activation signal from the HCP system  100 ; (9) activate supplemental programs that are selected and confirmed by the provider  101 ; (10) tailor content associated with an activated supplemental program for a specific delivery mode; and (11) deliver the content associated with the activated supplemental program to the patient. 
     As also discussed in more detail below, the central portion  301  of the SP module determines eligible supplemental programs, out of a plurality of available supplemental programs, for a patient based on at least electronic prescription data and the piles of each available supplemental programs. Although not exemplified, the central portion  301  of the SP module comprises a rules engine that determines the eligibility of each of the available supplemental programs for a patient being prescribed a particular substance. Further, the central portion  301  of the SP module also comprises agents that reach out to the third party content providers  400  to retrieve content relating to the plurality of supplemental programs. However, the invention is not so limited and in one embodiment, the central portion  301  of the SP module does not comprise the rules engine, but rather just transmits at least the electronic prescription data to the third party content providers  400 , which in turn determines the eligibility of each of the available supplemental programs. 
     In the exemplified embodiments, the central portion  301  does most of the heavy processing of the SP module, while the SP widget  302  routes data to the central portion  301  and provides an interface for the provider  101  to access the SP module. Although exemplified as comprising a SP module widget  302  that resides within the memory  113  of the HCP system  100  (and more specifically, a SP module widget  302  that is integrated into the EP module) and a central portion  301  that resides within the memory  313  of the SP system  300 , the SP module is not so limited. In alternate embodiments of the present invention, the central portion  301  and/or the SP widget  302  may reside elsewhere on the system  1000 , or the central portion  301  may be combined with the SP module widget  302  and the combined SP module may reside on any system or module of the system  1000 . Further, as described herein, it should be understood that any of the processes or functions performed by either the central portion  301  or the SP widget  302  may be performed partially or wholly by the other portion of the SP module in an alternate embodiment of the present invention. 
     The supplemental program database  303  stores general supplemental program data, including, but not limited to the names of a plurality of available supplemental programs, general information relating to each of the plurality of available supplemental programs, and the rules of each of the available supplemental program. As discussed in more detail below, according to one embodiment of the present invention, a supplemental program is a document or service that is activated for a patient based on the defined rules of the supplemental program. Further, according to one embodiment of the present invention, each supplemental program is designed to increase the patient&#39;s adherence to a prescribed substance. 
     As also discussed in more detail below, the rules of each supplemental program dictate which patients are eligible for the supplemental program. Generally, each rule may be based on, among other things, a substance currently being prescribed to the patient, the patient&#39;s medical history, information relating to the provider, and/or information relating to the patient&#39;s payor or health insurance company. According to one embodiment of the present invention, the rules of the supplemental programs are defined by a combination of an administrator of the SP system  300  and one or more pharmaceutical companies. However, the invention is not so limited, and in alternate embodiments the rules may be defined by any combination of the administrator of the SP system  300 , the pharmaceutical companies, and/or the third party program vendors  400 . 
     it should be noted that although exemplified as residing entirely in the memory  313  of the SP system  300 , in alternate embodiments, the supplemental program database  303  may reside entirely on another system of the system  1000  or be broken up and reside partially on two or more of the systems of the system  1000 . Specifically, in one alternate embodiment the supplemental program database  303  resides entirely on the HCP system  100 , while in another alternate embodiment the supplemental program database  303  resides entirely on the EP system  200 . 
     Further, as also discussed in more detail below, in one embodiment of the present invention the supplemental program database  303  may comprise the underlying supplemental programs themselves. In such embodiments, the SP module does not have to reach out to the third party content providers  400  to retrieve content relating to a, supplemental program or to enroll a patient in a supplemental program. 
     The record database  304  stores information relating to the parties and the processes involved in supplementing an electronic prescription, such as, but not limited to, patient data, prescribed substance data, provider data, payor data, and patient medication history data. Further, the record database  304  may further store provider preference data and patient preference data. It should be noted that although exemplified as residing entirely on the SP system  300 , in alternate embodiments, the record database  304  may reside entirely on another system of the system  1000  or be broken up and reside partially on two or more of the systems of the system  1000 . Specifically, in one alternate embodiment the record database  304  resides entirely on the HCP system  100 , while in another alternate embodiment the record database  304  resides entirely on the EP system  200 . 
     Finally, according to one embodiment of the present invention, the SP system  300  further comprises an administrator. The administrator is an individual (or group of individuals) who has access to the databases, modules, and engines of the SP system  300 , and may configured to databases, modules, and engines as they see fit. For example, in some embodiments of the present invention, the administrator may configure the settings of the SP module (both central portion  301  and SP widget  302 ), may configure the data stored in the one or more databases of the SP system  300 , may configure the rules of the available supplemental programs, and/or may configure the rules engine of the SP module. Therefore, the administrator of the SP system  300  has the ability to access and control the processes and functions of all of the components of the SP system  300 . 
     Referring to  FIG. 5 , a schematic diagram of a plurality of third party content providers  400  according to one embodiment of the present invention is illustrated. Generally, the present invention is not limited to any specific number of third party content providers  400 . Therefore, although four third party content providers ( 410 ,  420 ,  430 ,  440 ) are illustrated in  FIG. 5 , the present invention may comprise more or less than four third party content providers  400 . For example, in an alternate embodiment of the present invention, one or more of the third party content providers  400  may be combined. 
     Each third party content provider  400  comprises a server  410 ,  420 ,  430 ,  440  which comprises a properly programmed processor (CPU)  411 ,  421 ,  431 ,  441 , a network interface  412 ,  422 ,  432 ,  442 , and a memory unit  413 ,  423 ,  433 ,  443  in operable communication. Although each third party content provider  400  is exemplified as comprising a single server  410  (or  420 ,  430 ,  440 ), the invention is not so limited and in alternate embodiments any of the third party content provider  400  may comprise any number of servers. Additionally, although not exemplified, it should be understood that the processors  411 ,  421 ,  431 ,  441  can have integrated memory. Finally, the network interfaces  412 ,  422 ,  432 ,  442  connects their respective server  410 ,  420 ,  430 ,  440  to the over systems and modules of the system  1000  via the internet. 
     As discussed in more detail below, the processors  411 ,  421 ,  431 ,  441  of each third party content providers  400  effectuates the performance of the processes and functions described herein, including but not limited to the storage of data to the databases  401 ,  402 ,  403 , and  404 , the transfer of content to a patient, the enrollment of a patient into a service, and the transfer of data between each third party content providers  400  and the other systems (specifically the SP system  300 ) of the system  1000 . 
     The memory unit  413  comprises a coupon database  401 , the memory unit  423  comprises an educational information database  402 , the memory unit  433  comprises a patient/medication reminder service database  403 , and the memory unit  443  comprises a patient adherence service database  404 . Although exemplified as a single memory unit, it should be noted that any of the memory units  413 ,  423 ,  433 ,  443  may comprise any number of databases used to store data, modules, or other information. 
     The coupon database  401  stores supplemental program coupon data relating to a plurality of different coupon documents and coupon services for a plurality of substances that may be prescribed to a patient. The supplemental program coupon data may include the amount of a coupon, the rules relating to the eligibility of a coupon or a coupon service, the delivery modes of the coupon or coupon service, and other information relating to a particular coupon or coupon service. Further, it should be noted that a coupon may be, but is not limited to, a discount for prescribed substances, a rebate for prescribed substances, or a voucher for a free trial of prescribed substances. 
     The educational information database  402  stores supplemental program educational data relating to a plurality of different educational documents for a plurality of different substances and diseases states for which a patient may be prescribed or diagnosed. The supplemental program educational data may include general educational documents relating to a plurality of different substances or disease states, specific educational documents relating to a plurality of different substances or disease states, general educational services that relate to a plurality of different substances or disease states, specific educational services that relate to a plurality of different substances or disease states, and the rules relating to the eligibility of the documents and services listed above. 
     The patient/medication reminder service database  403  stores supplemental program reminder data relating to a plurality of different patient reminder services and substance (or medication) reminder services. The supplemental program reminder data may include information relating to appointment reminder services for a patient, prescription filling reminder services for a patient, refill reminder services for a patient, and the rules relating to the eligibility of the services listed above. 
     The patient adherence service database  404  stores supplemental program adherence data relating to a plurality of adherence services for patients. The supplemental program adherence data may include information relating to a variety of different adherence programs and services for patients, including the rules relating to the eligibility of the services. 
     Referring to  FIG. 6 , a schematic diagram of a pharmacy system  500  according to one embodiment of the present invention is illustrated. In the exemplified embodiment, the pharmacy system  500  comprises a prescription routing sub-system  501  and at least one prescription filling sub-system  502 , all in operable communication with one another. Generally, the prescription routing sub-system  501  is configured to electronically receive a prescription for a substance from the HCP system  100  or the EP system  200  and route the prescription to a prescription filling sub-system  502 . 
     The prescription routing sub-system  501  comprises a server  510  that comprises a properly programmed processor  511 , a network interface  512 , and a memory device  513  in operable communication. Although not exemplified, each of the prescription filling sub-systems  502  comprises a properly programmed processor, a network interface, and a memory unit. Although exemplified as a single server  510 , the invention is not so limited and in alternate embodiments the prescription routing sub-system  501  may comprise any number of servers  510 . Additionally, although not exemplified, it should be understood that the processor  511  can have integrated memory. The network interface  512  connects the server  510  to the over systems and modules of the system  1000  via the internet. The processor  511  of the pharmacy system  500  effectuates the processes and functions described herein, including but not limited to, the reception of prescription data from the EP module, the transfer of prescription history information to the SP module, and the transfer of data between the pharmacy system  500  and the other systems and modules of the system  1000 . 
     In the exemplified embodiment, the memory  513  of the prescription routing sub-system  501  comprises a prescription filling system database  504  and a patient prescription history database  505 . The prescription filling system database  504  stores the names, addresses and other information relating to each of the prescription filling sub-system(s)  502 . The patient prescription history database  505  stores information relating to previous prescriptions routed by the pharmacy system  500  for patients. 
     The prescription filling sub-system  502  is a system that fills the prescribed substance for an end user. For example, prescription filling sub-system  502  may be a local pharmacy used by a patient. 
     Referring to  FIG. 7 , a schematic diagram of a payor system  600  according to one embodiment of the present invention is illustrated. Generally, the payor system  600  comprises a server  610  which comprises a properly programmed processor (CPU)  611 , a network interface  612 , and a memory unit  613  in operable communication. It should be noted that the processor  611  may be considered the processor of the payor system  600 . Further, although exemplified as a single server  610 , the invention is not so limited and in alternate embodiments the payor system  600  may comprise any number of servers  610 . Additionally, although not exemplified, it should be understood that the processor  611 , can have integrated memory. The network interface  612  connects the server  610  to the over systems and modules of the system  1000  via the internet. 
     As discussed in more detail below, the processor  611  of the payor system  600  effectuates the performance of the processes and functions described herein, including but not limited to the storage of data to the database  601  of the memory  613  and the transfer of data (e.g., patient insurance information) between the payor system  600  and the other systems and modules of the system  1000 . 
     The memory  613  of the payor system  600  comprises a patient insurance database  601 . The patient insurance database  601  stores information relating to the payor of prescriptions for substances of patients, such as, but not limited to, the patient&#39;s insurance company, the patient&#39;s co-pay amount, and the patient&#39;s other deductibles. Further, although exemplified as a single memory unit, it should be noted that the memory  613  may comprise any number of databases used to store data, modules, or other information. 
     Therefore, it may be said that the system  1000  comprises a plurality of databases or one or more databases. Specifically, as noted above, the system  1000  comprises the EP database  201  on the EP system  200 , the supplemental program database  303  and the records database  304  on the SP system  300 , the coupon database  401 , the educational information database  402 , the patient medication/reminder service database  403 , and the patient adherence service database  404  of the third party content providers  400 , the prescription filling sub-system database  504  and the patient prescription history database  505  of the pharmacy system  500 , and the patient insurance database  601  of the payor system  600 . 
     Supplemental Programs 
     A supplemental program, as used herein, may be any document that is provided to a patient or any service in which a patient is enrolled that is designed for increasing patient adherence to a prescribed substance. Stated another way, a supplemental program may be a document or service designed to help patients understand their medication regimen and comply with it. For example, a supplemental program may be a coupon (or a coupon service) that is provided to a patient for a particular prescribed substance, educational material (either general or specific) that is provided to a patient for a particular prescribed substance or disease state, a combined coupon/educational document (referred to herein as an “EduSAVE™” document, one example of which is exemplified in  FIG. 9 ), a loyalty card, a prescription reminder service, an appointment reminder service, a health care coaching service, or any other patient adherence service or document. In one embodiment, the available supplemental programs are all patient adherence programs. However, the invention is not, so limited and in alternate embodiments, some or all of the available supplemental programs may not relate to patient adherence. 
     As discussed in more detail below, eligibility of a supplemental program is determined by comparing one or more of a plurality of different data elements (such as, but not limited to, a patient&#39;s general information, a patient&#39;s medical history, a brand name or formula of a substance prescribed to a patient, other information relating to a substance prescribed to a patient, a patient&#39;s payor&#39;s information (e.g., a patient&#39;s health insurance company and/or health insurance plan), a provider&#39;s general or specific information) with the rules of each of the available supplemental programs. If the data element(s) meets the rules for a specific supplemental program, then the patient is determined to be “eligible” for that program. For example, a specific program may only be eligible to patients who are being prescribed a particular substance, patients who reside within a particular geographic region, patients who have a specific history with a particular substance, patients who have at least specific co-pay for a particular substance, or patients whose providers meet certain qualifications. 
     As discussed in detail below, the determination of eligibility is determined by the SP module, and more specifically, by the rules engine of the SP module. Generally, the SP module receives and/or retrieves a plurality of data relating to the patient, the prescribed substance, the provider, and/or the payor, and applies that data to the rules of each of the available supplemental programs to determine supplemental programs in which the patient is eligible. 
     Method for Supplementing Patient and Provider Interactions 
     Generally and in accordance with one embodiment of the present invention, a method for supplementing patient and provider interactions to increase patient adherence generally comprises three steps: (1) determining, from a plurality of available supplemental programs, supplemental programs for which a particular patient receiving a prescription for a particular substance is eligible; (2) receiving confirmation/approval from the patient&#39;s health care provider that the eligible supplemental program should be activated; and (3) activating the eligible supplemental programs that the provider has confirmed/approved in order to increase patient adherence to the prescribed substance. 
     1. Determining Eligible Supplemental Programs for a Patient 
     Referring to  FIGS. 8   a - 8   c , a flow chart of a system for supplementing patient and provider interactions to increase patient adherence according to one embodiment of the present invention is illustrated. 
     According to one embodiment of the present, invention, the process begins when a patient visits their health care provider  101  seeking health care advice, and the provider  101 , after diagnosing the patient, decides to write an electronic prescription for a particular substance for the patient. The electronic prescription is typically generated by the provider  201  using the EP module. Specifically, in one embodiment of the present invention, the provider  101  drafts an electronic prescription using the thin-client portion of the EP module  203 , which resides on the HCP system  100 . 
     Referring to  FIG. 10 , a screen shot of a graphical user interface (GUI) generated by the EP module (and specifically the thin-client portion  203  of the EP module) to allow the provider  101  to generate an electronic prescription for a patient according to one embodiment of the present invention is illustrated. As shown in  FIG. 10 , the GUI comprises information relating to the provider (at least their name)  1001 , information relating to the patient  1002 , information relating to the pharmacy  1003  where the electronic prescription will be transmitted, information relating to the formulary of the patient  1004 , information relating to the patient&#39;s medical history  1005 , and information relating to a substance  1006  to be prescribed to the patient. Moreover, the GUI is not so limited and may further comprise information relating to the other medications previously prescribed to the patient, current allergies or adverse reactions of the patient, or other previously recorded problems of the patient. 
     Referring to  FIGS. 11-14 , multiple, sequential graphical user interfaces (GUIs)  1011 ,  1012 ,  1013 ,  1014  generated by the EP module to allow the provider  101  to generate an electronic prescription for a patient according to one embodiment of the present invention are illustrated. In the GUI  1011  exemplified in  FIG. 1I , the provider  101  may select a medication for prescription. As shown, the provider  101  may search for a new substance to prescribe by name or may choose a substance from a pre-established list of favorites. As shown in the GUI  1012  of  FIG. 12 , after a provider  101  chooses a substance to prescribe to the patient, the EP module generates and displays the GUI  1012 , which comprises drug interaction warnings, formulary alerts based on the patient&#39;s formulary status, and other medication alerts and warnings. 
     After the provider  101  confirms the substance in the GUI  1012 , the EP module generates and displays GUI  1013  (shown in  FIG. 13 ), which allows the provider to enter the details of the substance to be prescribed  1006 . For example, substance details such as the names, dosage, strength, form, duration, quantity, and refills are displayed for provider  101  input, along with directions to the patient and/or pharmacist and other details relating to the filling pharmacy and provider  101 . After the provider  101 , has entered all the required information using the input device  122  of their terminal  120  of the HCP system  100 , the EP module generates a displays GUI  1014 . As exemplified in  FIG. 14 , the GUI  1014  provides a summary of the electronic prescription for the substance for the provider&#39;s review. After the provider  101  reviews and confirms that the prescription is accurate, the electronic prescription for the substance is created. 
     Still also referring to  FIGS. 8   a - 8   c , in the exemplified embodiment, after an electronic prescription for the substance is created by the provider  101 , the SP widget  302  retrieves data relating to the electronic prescription from the thin-client portion of the EP module  203 . The SP widget  302  then transmits the electronic prescription data to the central portion  301  of the SP module residing on the SP system  300 , such that the central portion  301  of the SP module receives the electronic prescription data, thereby completing step  801  in  FIG. 8   a . The electronic prescription data comprises first patient data that is specific to the patient, first prescribed substance data that is specific to the prescribed substance, first provider data that is specific to the provider  101 , and first payor data that is specific to the payor. 
     The first patient data comprises the information that is part of the prescription and relates to the patient, such as but not limited to, the patient&#39;s name, gender, date of birth (DOB), contact information (telephone and address), and the patient&#39;s formulary status. 
     The first prescribed substance data comprises information that is part of the prescription and relates to the prescribed substance, such as but not limited to, the name of the prescribed substance, the dosage, strength, form, duration, and quantity of the prescribed substance, and the number of refills listed on the prescription. 
     The first provider data comprises information that is part of the prescription and relates to the provider  101 , such as but not limited to, the provider&#39;s name, the address and phone number of the provider&#39;s practice, and national provider identifier (NPI) number. 
     The first payor data comprises information that is part of the prescription and relates to the payor of the patient, such as but not limited to, the payor&#39;s name and the formulary status (or health care plan) of the patient. 
     However, the invention is not so limited, and in an alternate embodiment of the present invention, the electronic prescription data may not relate to an electronic prescription currently being prescribed by the provider  101  for the patient, but rather relate to a refill, a renewal, or a previously prescribed substance. In such embodiments, the electronic prescription data may be received by the SP module from one of the other databases of the system  1000  (e.g., the EP database  201 , the records database  304 , the patient prescription history database  505 , etc.). 
     Once the central portion  301  of the SP module receives the electronic prescription data, the central portion  301  of the SP module retrieves additional data prior to determining supplemental programs for which the patient is eligible. However, it should be noted that the invention is not so limited and in alternate embodiments, the central portion  301  of the SP module may only retrieve a portion of the data listed herein or may not retrieve any additional data prior to determining supplemental programs for which the patient is eligible. 
     In the exemplified embodiment, the central portion  301  of the SP module retrieves patient data that is specific to the patient from the record database  304 , thereby completing step  802 . The patient data comprises one or more of the patient&#39;s current medication, the patient&#39;s recent drug fills, the patient&#39;s drug fill history, the patient&#39;s demographics, the patient&#39;s health care plan or payor information, the patient&#39;s adherence information, and the patient&#39;s clinical trial cohort (if the patient is part of a clinical trial cohort). The patient adherence information may relate to the patient&#39;s past adherence to prescriptions for the same prescribed substance, for prescriptions to prescribed substances for the same disease state, and/or the patient&#39;s general adherence to any combination of the substances they have previously been prescribed to the patient. It should be noted that this information is in addition to the first patient data that was retrieved by the centralized portion of the SP module  301  from the created electronic prescription. 
     Further, the central portion  301  of the SP module may also retrieve prescribed substance data relating to the substance prescribed by the electronic prescription from the record database  304 , thereby completing step  803 . The prescribed substance data comprises one or more of the prescribed substance&#39;s drug properties, the prescribed substance&#39;s therapeutic class(es), a prescribed substance substitution code, the prescribed substance&#39;s formulary data, and a prescription indicator. It should be noted that this information is in addition to the first prescribed substance data that was retrieved by the central portion  301  of the SP module from the created electronic prescription. 
     The central portion  301  of the SP module may also retrieve provider data relating to the health care provider  101  from the record database  304 , thereby completing step  804 . The provider data comprises one or more of the provider&#39;s geographic location, the provider&#39;s state of residency, and the specialty of the provider  101 . It should be noted that this information is in addition to the first provider data that was retrieved by the central portion  301  of the SP module from the created electronic prescription. 
     The central portion  301  of the SP module may also retrieve payor data relating to the payor (e.g., a health care insurance company) of the patient from the record database  304 , thereby completing step  805 . Further, according to one embodiment, if the record database  304  does not have any of the patient&#39;s payor information stored therein (or even if it does), then the central portion  301  of the SP module may transmit a request to the payor system  600  and receive back the patient&#39;s payor information from the patient insurance database  601 . The payor data comprises one or more of the formulary status (or health care plan) of the patient, the co-pay of the patient, and any other information relating to the payor of the patient. It should be noted that this information is in addition to the first payor data that was retrieved by the central portion  301  of the SP module from the created electronic prescription. 
     According to one embodiment of the present invention, the central portion  301  of the SP module first attempts to retrieve the relevant data from the records database  304 . Thereafter, if the records database  304  does not comprise the relevant data required by the central portion  301  to determine the eligible supplemental programs, then the central portion  301  reaches out to at least one other database on the system  1000 , such as, but not limited to the EP database  201  and the patient insurance database  601 . In one embodiment, upon retrieving the relevant data from one of the other databases of the system  1000 , the central portion  301  stores the relevant data in the records database  304  for future processing. 
     After the central portion  301  of the SP module retrieves the additional data required, the central portion  301 , using the rules engine, determines, from a plurality of available supplemental programs, supplemental programs for which the patient is eligible based on the electronic prescription for the substance. As discussed above, a plurality of available supplemental programs are stored within one or more databases, which includes but is not limited to the supplemental program database  303  and the databases  401 ,  402 ,  403 ,  404  of the third party content providers  400 . As noted above, according to one embodiment of the present invention each available supplemental program is a document that is provided to a patient or a service in which a patient is enrolled. Moreover, according to one embodiment, each available supplemental program is designed to increase patient adherence to the prescribed substance. 
     As also noted above, each supplemental program out of the plurality of available supplemental programs comprises one or more rules. Generally, the rules of a supplemental program must be met in order for the patient to be “eligible” for the supplemental program. The rules may relate to information relating to the patient, the prescribed substance, the provider; and/or the payor of the patient. Therefore, the rules of each of the available supplemental programs may act as constraints and/or restrictions dictating the eligibility of a patient for a particular available supplemental program. 
     Examples of rules include, but are not limited to, restricting a supplemental program to a specific prescribed substance or disease state, restricting a supplemental program to a specific prescribed substance of a specific dosage strength, restricting a supplemental program to patients or providers of a specific geographic region, restricting a supplemental program to patients who have a certain adherence history (whether with the prescribed substance or in general), restricting a supplemental program to patients who have a specific persistency rate for the prescribed substance (e.g., a persistency rate under 60%, a persistency rate between 30%-60%, or a persistency rate between 10%-85%), restricting a supplemental program to patients of a certain age or age range, restricting a supplemental program to patients who have been prescribed the substance for at least a predetermined time period, restricting a supplemental program to patient&#39;s who have a certain co-pay for a specific prescribed substance, restricting a supplemental program to patient&#39;s having a certain health insurance carrier, etc. 
     Therefore, for example, a specific supplemental program is only eligible to patients who meet the rules described above. Restricting the dissemination of supplemental programs on the basis of the rules listed above may be beneficial since supplemental programs will only go to those patients with which they will have the greatest effect. Therefore, for example, a pharmaceutical company is not blindly handing out coupons to patients whose habits may not be affected by the receipt of a coupon. Rather, the coupons are distributed on the basis of predetermined rules to increase the likelihood that the coupons will result in increased adherence by the patient, and in turn, sales of the prescribed substance and reduced costs to the other parties involved. Further, since the determination of eligibility is performed by the rules engine of the SP module, the health care provider  101 , may, but is not required to calculate or analyze whether a patient would be incentivized by a supplemental program. This helps to alleviate some of the burden typically placed on health care providers  101  with regards to disseminating documentation to their patients. 
     Further, according to another embodiment of the present invention, rules may further include a patient&#39;s specific usage stage for a substance. Therefore, in one embodiment, a patient may only be eligible for supplemental program that provides a specific coupon if they are at a specific usage stage for a particular substance. For example, a patient may only be eligible for a coupon if they are after their second refill for a particular substance, or if they are between their third and fourth refill of a particular substance. In such embodiments, providing coupons to a patient based on their specific usage stage for a substance may encourage continued patient adherence for that substance. 
     The rules engine of the central portion  301  of the SP module determines the eligibility of each of the plurality of available supplemental programs for the patient by comparing the data received/retrieved by the SP module with the rules of each available supplemental program. As noted above, the data used in the comparison includes, but is not limited to, the first patient data received from the electronic prescription, the first prescribed substance data from the electronic prescription, the first provider data from the electronic prescription, the first payor data from the electronic prescription, the patient data retrieved by the central portion  301  of the SP module, the prescribed substance data retrieved by the central portion  301  of the SP module, the provider data retrieved by the central portion  301  of the SP module, and the payor data retrieved by the central portion  301  of the SP module. Therefore, the eligibility of each of the available supplemental programs is determined by the rules engine of the central portion  301  of the SP module using any combination of the data (or data elements) listed above. 
     Still referring to  FIG. 8   a , in decision step  806 , the central portion  301  of the SP module, using the rules engine, determines the eligibility of the plurality of available supplemental programs by comparing the data received and retrieved (e.g., the patient data, the prescribed substance data, the provider data, and the payor data discussed above) with the rules of each of the available supplemental programs. If the received/retrieved data does not meet the rules of any of the plurality of available supplemental programs, then the process ends at step  807 . However, if the received/retrieved data meets the rules of at least one available supplemental program, then the process continues to step  808 . It should be noted that those supplemental programs whose rules are determined by the rules engine to meet the received and retrieved data are considered eligible supplemental programs. 
     Further, it should be noted that although exemplified as a single determination step, the invention is not so limited. In one embodiment of the present invention, the determination of eligible supplemental programs by the rules engine of the SP module is a multi-step comparison process. For example, in one embodiment of the present invention, during a first comparison step the central portion  301  of the SP module compares the prescribed substance data (including either the first prescribed substance data retrieved from the electronic prescription and/or the prescribed substance data retrieved from the record database  304 ) with the rules of each of the available supplemental programs. More specifically, the rules engine of the SP module may compare the brand name or formula of the prescribed substance with each of the plurality of available supplemental programs. If the brand name or formula of the prescribed substance matches the brand name or formula of a rule an available supplemental program, then that supplemental program passes the first comparison step of the rules engine. 
     If the prescribed substance data does meet the rules of at least one available supplemental program, then the central portion  301  of the SP module performs a second comparison step, whereby the SP module compares the patient data (including either the first patient data retrieved from the electronic prescription and/or the patient data retrieved from the record database  304 ) with the rules of each of the supplemental programs that passed the first comparison step. Thereafter, the SP module may perform subsequent comparison steps using the provider data and/or the payor data. In such embodiments, a patient is “eligible” for a supplemental program, if and only if, the supplemental program passes each step of the multi-step comparison process. 
     It should be noted that in such multi-step comparison embodiments, the invention is not limited to any specific number of comparison steps, the order of the comparison steps, or the types of comparison steps (e.g., steps using prescribed substance data, using patient data, using provider data, or using payor data). 
     Further, it should be noted that in an alternate embodiment of the present invention, the central portion  301  of the SP module transmits the data received and retrieved from the one or more databases (e.g., the patient, prescribed substance, provider, and payor data discussed above) to a third party system (e.g., one of the third party content providers  400 ). Thereafter, the third party system compares the data against the rules of each of the available supplemental programs to determine eligibility. After testing the data against the rules, the third party system transmits a signal back to the central portion  301  of the SP module indicating which of the available supplemental programs are eligible. Therefore, in such embodiments, the SP module determines the eligibility of the available supplemental programs by transmitting the appropriate data to a third party system and receiving back a signal indicating for which of the available supplemental programs the patient is eligible. 
     Although not exemplified, in one embodiment of the present invention, prior to performing step  806 , the central portion  301  of the SP module retrieves provider preference data (and/or patient preference data) from the records database  304  and/or the supplemental program database  303 . Provider preference data is information that relates to the preferences of the specific provider  101  who drafted the prescribed substance. Similarly, patient preference data is information that relates to the preferences of the patient which whom the substance is being prescribed. The preference data includes, but is not limited to, specific modes of delivery (e.g., print, email, SMS, etc.) and supplemental program types (e.g., educational material, coupons, reminder services, etc.) that the provider  101  and/or patient prefers. 
     If the SP module locates and retrieves preferences for the provider  101  and/or patient, then the following steps are limited to those supplemental programs and delivery modes that are preferred by the provider and/or patient. For example, if the provider  101  sets their preferences to select only a specific type of supplemental program (e.g., educational material), then the SP module will only determine eligible supplemental programs that are of that specific type of supplemental program. For purposes of this discussion, we will assume that the SP module does not retrieve any provider or patient preference data. 
     According to one embodiment of the present invention, the SP module receives provider  101  and/or patient preference data directly from the provider  101  via the input device  122  of the FICP system  100 . However, it should be noted that in other embodiments of the present invention, the SP module may learn the preferences of a provider  101  and/or a patient based on one or more previous instances where the provider  101  and/or patient used the SP module. Upon receiving or learning provider  101  and/or patient preference data, the central portion  301  of the SP module stores the preference data in the record database  304 . 
     After the SP module determines which of the available supplemental programs the patient is eligible, the central portion  301  of the SP module retrieves supplemental program data relating to each of the eligible supplemental programs from the supplemental program database  303 , thereby completing step  808 . It should be noted that, according to one embodiment of the present invention, the supplemental program data is not the actual supplemental program itself, but rather information relating to each of the supplemental programs. 
     In the exemplified embodiment, the supplemental program data comprises information about the eligible supplemental program, such as, but not limited to, the name of the eligible supplemental program, the specific type of document or service the eligible supplemental program comprises, and delivery mode data relating to the available delivery modes of each of the eligible supplemental programs. Further, it should be noted that if the received/retrieved data meets the rules of more than one available supplemental program, then the central portion  301  of the SP module retrieves supplemental program data relating to each of the plurality of eligible supplemental programs from the supplemental program database  303 . 
     However, the invention is not so limited, and in another embodiment of the present invention, the central portion  301  of the SP module retrieves the supplemental program data from the one or more databases  401 ,  402 ,  403 ,  404  of the appropriate third party content provider  400 . Further, in another alternate embodiment, the central portion  301  of the SP module may actual receive the supplemental programs itself at step  808 . 
     After retrieving the supplemental program data in step  808 , the central portion  310  of the SP module retrieves patient delivery mode data relating to the delivery modes that are available for the patient from the record database  304  of the SP system  300 , thereby completing step  809 . The patient delivery mode data comprises information relating to the patient, such as but not limited to, an email address of the patient, a phone number of the patient, and a mailing address of the patient. It should be noted that the central portion  301  of the SP module can retrieve information about the patient that is currently stored in the record database  304 , along with patient data that is stored in the other, one or more databases of the system  1000 . 
     After retrieving patient delivery mode data, the central portion  301  of the SP module compares the patient delivery mode data with the delivery mode data for each of the eligible supplemental programs, thereby completing step  810 . As noted above, the delivery mode data for the eligible supplemental programs is retrieved by the central portion  301  in step  808 . The comparison is done in order to determine qualified delivery modes for each of the eligible supplemental programs. A qualified delivery mode is a delivery mode that is available for a supplemental program and a delivery mode in which the patient delivery mode data (e.g., the patient&#39;s email address, phone number, etc.) relating to that delivery mode is stored in the SP system  300  and has been retrieved by the SP module. 
     As discussed in more detail below and according to one embodiment of the present invention, eligible supplemental programs that do have qualified delivery modes may be preselected by the SP module for those specific delivery modes. Further, in another embodiment of the present invention, eligible supplemental programs that do not have at least one qualified delivery modes associated therewith may be locked so as to be incapable of selection by the provider  101  in such embodiments, if the provider  101  may be required to enter patient delivery mode information into the GUI of  FIG. 15  described below in order to unlock the selection mechanism for that particular supplemental program. Further, it should be noted that the invention is not so limited, and in other alternate embodiments the qualified delivery modes may just be preselected by the SP module, while the non-qualified delivery modes are grayed-out or only selectable upon the provider  101  entering the appropriate patient delivery mode information. 
     Further, in yet another embodiment of the present invention, the SP module does not retrieve patient delivery mode data and, therefore a comparison between patient delivery mode data and delivery mode data for each of the eligible supplemental programs is not performed by the SP module. In such instances, all of the available delivery modes for each of the eligible supplemental programs may be displayed in the GUI to the provider  101  using the display device  121 . 
     2. Receiving Confirmation from the Health Care Provider to Activate the Supplemental Programs 
     After the SP module has determined supplemental programs for which the patient is eligible, the SP module generates and displays a GUI to the provider  101  in order to receive confirmation from the provider  101  regarding which of the eligible supplemental programs should be activated. 
     Referring to  FIG. 8   b  and after step  810 , the SP module generates a GUI that comprises a list of the eligible supplemental programs for the provider&#39;s selection and confirmation by the health care provider  101 , thereby completing step  811 . In one embodiment of the present invention, the central portion  301  of the SP module generates the GUI that comprises the list of eligible supplemental programs for the patient, and then transmits the GUI to the SP widget  302  for display to the provider  101  in the display device  121 . However, in alternate embodiments of the present invention, the GUI is generated and displayed by the SP widget  302 . 
     After the GUI is generated, the SP widget  302  displays the GUI in the display device  121  of the terminal  120  to the provider  101 , thereby completing step  812 . One example of a GUI is shown in  FIG. 15 . As exemplified by the GUI of  FIG. 15 , the GUI comprises a pop-up window  1010 , which comprises information relating to the substance  1011  for which eligible supplemental programs are being presented, information relating to the eligible supplemental programs  1012 , selection mechanisms  1013  for each of the eligible supplemental programs, information relating to delivery modes  1014  available for the eligible supplemental programs, delivery mode selection mechanisms  1015  for each of the delivery modes available for each of the eligible supplemental programs, delivery mode input fields  1016 , a confirmation mechanism  1017 , and a cancellation mechanism  1018 . 
     Still referring to  FIG. 15 , although only one substance is listed in the window  1010 , it should be noted that section  1011  may comprise information relating to a plurality of prescribed substances. For instance, if the provider  101  drafts more than one prescription relating to more than, one substance for the patient and the SP module determines that there are eligible supplemental programs relating to more than one of the prescribed substances, then the window  1010  will comprises a list of each of the substances  1011  along with a list of each of their associated eligible supplemental programs  1012 . 
     As further exemplified by the window  1010 , section  1012  which comprises a list of the eligible supplemental programs for each of the prescribed substances, also comprises a selection mechanism  1013  to allow the provider  101  to determine which of the eligible supplemental programs they would like to activate for their patient. The selection mechanism  1013  allows each of the eligible supplemental programs to be selected and/or deselected by the provider  101  using the input means  122  of the HCP system  100 . As discussed in more detail below, the eligible supplemental programs that are selected (e.g., via a check box) by the provider  101  using the selection mechanism  1013  when the confirmation mechanism  1017  is actuated by the provider  101  will be activated by the SP module for the patient upon the provider  101  actuating the confirmation mechanism  1017 . Although exemplified as a check box, the invention is not so limited and in alternate embodiments the selection mechanism  1013  may be changed to include any selection mechanism known in the art. 
     Moreover, as discussed above, it should be noted that if the supplemental program database  303  and/or the records database  304  comprises provider preference data and/or patient preference data, then the SP module will upload that information and generate the window  1010  based on that information. For instance, if the preference data relates to specific types of supplemental programs or delivery modes preferred by the provider  101  or patient, then the selection mechanisms  1013 ,  1015  for those supplemental program and/or delivery modes will be pre-selected when the window  1010  is generated by the central portion  301  of the SP module and displayed by the SP widget  302  on the display device  121  for the provider  101 . 
     Still referring to the window  1010  shown in  FIG. 15 , a list of available delivery modes  1014  for the eligible supplemental programs is also displayed for the provider  101 . As shown, each delivery mode comprises a delivery mode selection mechanism  1015  that may be selected and/or deselected by the provider  101  using the input means  122 . The delivery mode selection mechanisms  1015  allow the provider  101  to determine how the supplemental programs will be delivered to the patient. Further, it should be noted that more than one delivery mode may be selected by the provider  101 . In such instances, the supplemental programs will be delivered to the patient via all of the selected delivery modes. Although the delivery modes are shown to comprise print, email, and text/SMS, the invention is not so limited and in alternate embodiments, the delivery modes may also include mailing to the patient&#39;s address, along with other methods of delivering documents to the patient. 
     Further, the window  1010  also comprises the delivery mode input fields  1016 , which allow a provider  101  to manually enter in the patient&#39;s mobile phone number, email address, or other patient delivery mode information required for delivery of a supplemental program. If the provider  101  enters patient delivery mode information into a delivery mode input field  1016 , then upon the provider  101  actuating the confirmation mechanism  1017 , the SP module stores the patient&#39;s delivery mode information in one or more databases of the system  1000  (e.g., the records database  304 ) for future instances. Additionally, it should be noted that if the patient&#39;s delivery mode information (e.g., email, phone number, address, etc.) is previously stored in one or more of the databases of the system  1000  (e.g., the record database  304 , the EP database  201 , etc.), then the SP module will retrieve the patient&#39;s delivery mode information from the one or more databases and auto-populate the delivery mode input fields  1016  in window  1010 . 
     Further, one of the delivery mode input field  1016  shown in the window  1010  is a preview field. The preview field allows the provider  101  to preview the eligible supplemental program(s) before activating the program(s) for the patient. If the supplemental program is a coupon, education material, or other document, then another window displaying the document or information relating to the document will be generated and displayed by the SP module in the display device  121 . According to one embodiment of the present invention, if the supplemental program is a service, then another window displaying general information relating to the service will be generated and displayed by the SP module in the display device  121 . 
     As noted above, according to one embodiment of the present invention, prior to generating and displaying the window  1010 , the SP module retrieves delivery mode data relating to the eligible supplemental program and the patient. In the list of delivery modes  1014  exemplified in  FIG. 15 , “print” is a qualified delivery mode and the delivery mode input field  1016  for print has been pre-selected by the SP widget  302 . Since the other delivery modes, such as email and mobile, do not comprise patient delivery mode data, they are not qualified delivery modes and are not pre-selected by the SP module. 
     Referring to both  FIG. 8   b  and  FIG. 15 , after the provider NI has selected the eligible supplemental programs and the delivery mode(s) for the eligible supplemental programs that they would like to activate for the patient, the provider  101  actuates the confirmation mechanism  1017 . Upon actuating the confirmation mechanism  1017 , the SP widget  302  generates and transmits an activation signal for each of the supplemental programs that have been selected by the provider  101  to the central portion  301  of the SP module, thereby completing step  813 . Each of the activation signals comprises information relating to the eligible supplemental program itself, along with the deliver mode selected by the provider  101 . However, the invention is not so limited and in alternate embodiments, the SP widget  302  generates and transmits a single activation signal that comprises information relating to all of the eligible supplemental programs that were selected by the provider  101 . 
     Although exemplified as an icon in the window  1010 , the confirmation mechanism  1017  is not so limited. In alternate embodiments, the confirmation mechanism  1017  may be a button, switch, lever, etc. that can be actuated by the provider to confirm the selected eligible supplemental programs and delivery modes. 
     However, if the provider  101  decides that they do not want to have any of the eligible supplemental programs activated for the patient, then the provider  101  may actuate the cancellation mechanism  1018 . Upon actuating the cancellation mechanism  1018 , the SP widget  302  generates and transmits a cancellation signal to the central portion  301  of the SP module. In such instances, none of the eligible supplemental programs are activated for the patient. 
     As shown in  FIG. 15 , the window  1010  is displayed concurrently with the electronic prescription interface that was used to generate the electronic prescription data previously received by the SP module. More specifically, the window  1010  overlays the electronic prescription interface and is automatically generated and displayed by the SP module in the display device  121  during the electronic prescriptions session undertaken by the provider  101 . By using such a system, the provider  101  does not have to leave their electronic prescription writing interface in order to be presented with eligible supplemental programs for their patients. Stated simply, the SP module, due in part to the SP widget  302  being integrated into the EP module, provides one continuous interface for the provider  101  during their prescription writing/supplemental program activating process. 
     This is beneficial because it allows the provider  101  to know what sorts of supplemental programs are available for their patient and, specifically for the substance the provider  101  is currently prescribing for their patient, without having to leave their electronic prescription writing interface. Such a system encourages providers  101  to disseminate documents and enroll their patients in services to increase their patient adherence in their prescribed substances. 
     Further, additional benefits arise from granting the provider  101  the ability not only to select what specific supplemental programs will be activated for each and every one of their patients, but also the ability to preview the supplemental programs before they are activated for the patient. Additionally, the provider  101  may select the specific delivery mode for each patient. Therefore, the provider  101  may tailor the supplemental programs depending on the particular preferences of the patient, as well as what the provider  101  believes will result in the most beneficial results. Finally, allowing the provider  101  to be the gatekeeper between the supplemental programs and the patient encourages communication between the provider  101  and patient, which ultimately results in better care for the patient. 
     Although exemplified as pop-up window  1010 , it should be noted that the invention is not so limited. In alternate embodiments, the provider interface created by the SP module may be any interface designed to allow the provider  101  to select and confirm the specific supplemental programs they would like to be delivered to the patient. For example, the interface may be a screen that takes up the entirety of the display device  121  or a window that is separate from the EP module (as opposed to pop-up window  1010 , which is displayed on top of the electronic prescription writing interface). Stated simply, the current invention is not limited to the type of interface generated and displayed to the provider  101 . 
     3. Activating the Eligible Supplemental Programs that have been Confirmed by the Health Care Provider 
     In general, activation of an eligible supplemental program begins when the provider  101  actuates the confirmation mechanism  1017  after selecting the programs they would like to be activated for their patient. In the embodiments discussed with reference to  FIGS. 8   a - 8   c , activation begins with step  813  and continues to step  818 . However, it should be noted that in alternate embodiments of the present invention, activation further includes step  819  and sometimes even step  820 . Moreover, in another embodiment of the present invention, activation only includes step  813 , which comprises the SP widget  302  generating and transmitting an activation signal to the central portion of the SP module  301  upon the provider  101  actuating the confirmation mechanism  1017 . 
     Referring to  FIG. 8   b , after the SP widget  302  generates and transmits the activation signal for each of the supplemental programs, the central portion  301  of the SP module receives the activation signals, thereby completing step  814 . Using the received activation signals, the central portion  301  of the SP module determines which of the eligible supplemental programs the provider  101  has confirmed. 
     Thereafter, the central portion  301  of the SP module transmits the relevant data for one of the confirmed supplemental program to the appropriate third party content provider  400 , thereby completing step  815 . For instance, if the confirmed supplemental program is a document (e.g., a coupon, educational material, EduSAVE™, etc.), then the central portion  301  of the SP module transmits at least a request for the document(s) to the appropriate third party content provider  400 . Similarly, if the supplemental program is a service (e.g., a prescription reminder service, a medication reminder service, an appointment reminder service, a patient adherence service, etc.), then the central portion  301  of the SP module transmits a request for patient enrollment in the service. Therefore, depending on the specific document or service requested, the central portion  301  of the SP module transmits the relevant request to the appropriate server  410 ,  420 ,  430 ,  440  of the third party content provider  400 . 
     It should be noted that in some embodiments of the present invention, the central portion  301  of the SP module may also transmit patient delivery mode data to the third party content provider  400 . This may be required if the third party content provider  400  is to deliver the content directly to the patient or enroll the patient directly into the service. 
     Upon receiving the request from the central portion  301  of the SP module, the appropriate third party content provider  400  determines whether the request is for a document or a service. If the request is for a document, then the third party content provider  400  generates the document and returns the document to the central portion  301  of the SP module. If the request is for a service, then the third party content provider  400  configures the service and transmits a configuration signal back to the central portion  301  of the SP module. Specifically, the corresponding document or service is retrieved from the appropriate one of the databases  401 ,  402 ,  403 ,  404 . 
     Thereafter, the central portion  301  of the SP module receives the document(s) and/or enrollment confirmation signal from the third party content system  400 , thereby completing step  816 . Next, the central portion  301  of the SP module determines if there are any other eligible supplemental programs for which a request has yet to be delivered to the third party vendor system  400  at decision step  817 . If there are additional confirmed supplemental programs for which relevant data has not yet been transmitted to the third party content system  400 , then the process returns to step  815  and, the central portion  301  of the SP module transmits the relevant data for another of the confirmed supplemental program to the appropriate third party content provider  400 . However, if the relevant data has been transmitted to the third party content system  400  for each of the confirmed supplemental programs, then the process continues to step  819 . 
     It should be noted that in one embodiment of the present invention, the central portion  301  of the SP module transmits the relevant data for all of the confirmed supplemental programs to the appropriate third party content provider  400  at step  815 . In such instances, decision step  817  may be omitted. 
     Therefore, after a request has been delivered by the central portion  301  of the SP module to the appropriate third party content provide  400  for all of the eligible supplemental programs that were confirmed by the provider  101 , the SP module has activated each of the supplemental programs. Generally, by activating a supplemental program the SP module either receives content, such as a document to the patient, that is to be delivered to the patient or enrolls the patient in one of the aforementioned services via the appropriate third party content provider  400 . 
     A non-limiting list of examples whereby the SP module activates a supplemental program is discussed below. It should be noted that the invention is not limited to the explicit examples presented herein. In one embodiment, in which the supplemental program is a coupon service, the SP module activates the supplemental program by retrieving coupon data relating to the prescribed substance from the coupon database  401  of the appropriate third party content provider  400  and integrating the coupon data into the electronic prescription. The integration of the coupon data into the electronic prescription is done by the SP widget  302 , which is integrated into the thin-client portion  320  of the EP module residing on the HCP system  100 . Thereafter, the HCP system  100  may transmit the electronic prescription with integration coupon to the pharmacy system  500  for further processing. 
     In another embodiment, in which the supplemental program is a coupon service, the SP module activates the supplemental program by retrieving the coupon data and provisioning a coupon based on the coupon data. Further, in one embodiment, activation further includes the SP module delivering the coupon to the patient via the selected delivery mode. For instance, the coupon may be delivered to the HCP system  100  so the provider  101  may print the coupon out for the patient using the printer  130 , or the coupon may be delivered directly to the patient via one of the delivery modes discussed above. 
     For further example, in one embodiment in which the supplemental program is a prescribed substance education service, the SP module activates the supplemental program by retrieving educational content relating to the prescribed substance from the educational information database  402  of the appropriate third party content provider  400 . Thereafter, according to one embodiment, activation may further include the SP module delivering the education content to the patient via the selected delivery mode. Therefore, the education content may be delivered to the patient by transmitting the educational content to the HCP system  100  so the content may be printed by the provider  101  for the patient using the printer  130 , or the educational content may be delivered directly to the patient via one of the delivery modes discussed above. 
     Additionally, in another embodiment in which the supplemental programs is a prescribed substance education service and/or a coupon service, the SP module activates the supplemental program by retrieving education content relating to the prescribed substance from the educational information database  402  of the appropriate third party content provider  400  and integrating the educational content into a coupon (such as the EduSAVET™ document shown in  FIG. 9 ). Further, according to one embodiment of the present invention, activation may further include delivering the combined educational coupon to the patient via the selected delivery mode. Similarly, the combined educational coupon may be delivered to the patient by transmitting the educational content to the HCP system  100  so the educational coupon may be printed by the provider  101  for the patient using the printer  130 , or the educational coupon may be delivered directly to the patient via one of the delivery modes discussed above. 
     In one embodiment, in which the supplemental program is a patient adherence service, the SP module activates the supplemental program by enrolling the patient in the patient adherence service. According to another embodiment of the present invention, in which the activated supplemental program is a prescription reminder service, the SP module activates the supplemental program by enrolling the patient in the prescription reminder service. In yet another embodiment of the present invention, in which the activated supplemental programs is an appointment reminder service, the SP module activates the supplemental program by enrolling the patient in the reminder service. 
     In the exemplified embodiments, the SP module enrolls the patient in the service by transmitting the relevant data to the appropriate third party content provider  400 , and the appropriate third party content provider  400  signs the patient up for the service. For example, the relevant data may include data relating to the patient, data relating to the patient&#39;s past adherence, data relating to the electronic prescription, and data relating to the patient&#39;s appointment schedule. However, in alternate embodiments of the present invention the SP module may enroll the patient into the service without the use of the appropriate third party content provider  400 . In such embodiments, the SP module may further comprise an enrollment engine in order to effectuate the enrollment of the patient in the appropriate service directly. 
     For example, in embodiments where the SP module further comprises an enrollment engine, the central portion  301  of the SP module would effectuate the enrollment of patients into the services that were activated for them, without the need of the SP module transmitting patient enrollment data to a third party content provider  400 . 
     Referring back to  FIG. 8   c , after the SP module is done activating the eligible supplemental programs that have been confirmed by the health care provider  101 , the SP module tailors the content relating to each of the activated supplemental programs for the specific delivery mode that was selected and confirmed by the provider  101 , thereby completing step  819 . Generally, the central portion  301  of the SP module alters the specific document depending on the specific delivery mode selected and confirmed by the provider  101 . For instance, if the delivery mode is selected to be via email, then the content is configured to be most easily viewable by a web browser. If the delivery mode is selected to be via text/SMS to the patient&#39;s mobile phone, then the content is configured to be most easily viewable on the smaller screen of a mobile device. Further, if the delivery mode is selected so that the content is printed at the printer  130 , then the content is configured to be most easily printed. 
     It should be noted that if the supplemental program is a service, the step of tailoring the content is typically not be performed. However, in some embodiments, the SP module may tailor a confirmation message of the patient&#39;s enrollment in the service for delivery to the patient via the specific delivery mode selected and confirmed above. 
     After the SP module tailors the content for the selected and confirmed delivery mode, the SP module delivers the content of each of the activated supplemental programs to the patient via the selected and confirmed delivery modes, thereby completing step  820 . Generally, the central portion  301  of the SP module will delivery the content if the selected delivery mode is to the patient&#39;s mobile phone, email, or mailing address. However, if the selected delivery mode is for the content to be printed at the printer  130 , then the central portion  301  of the SP module will transmit the content to the SP widget  302  residing on the HCP system  100 , and the SP widget  302  thereby effectuates the printing of the content by a printer  130  of the HCP system  100 . 
     As noted above, according to one embodiment of the present invention, one or both of steps  819  and  820  may be considered part of the activation step performed by the SP module. However, as also noted above, the invention is not so limited and the processing performed by steps  819  and  820  may also be considered separate, subsequent steps that are performed after the activation step of the SP module. 
     In one alternate embodiment, the supplemental program data relating to all of the available supplemental programs resides on the SP system  300  in its one or more databases. In such embodiments, the third party vendor system  400  is omitted, and the central portion  301  of the SP module does not have to reach out to the third party vendor system  400  to provide the patient with the documents or enroll the patient in the services. 
     In another embodiment of the present invention, the third party vendor system  400  may transmit the document directly to the patient or enroll the patient in the service upon receiving the request and the patient delivery module data. Therefore, in such embodiments, the central portion  301  of the SP module does not receive a document or confirmation signal from the third party content provider  400 . 
     Moreover, it should be noted that some of the services require the patient to confirm their enrollment in the service. Therefore, enrollment cannot be fully effectuated by the SP module or the third party vendor system  400 . In such instance, the SP module or the third party vendor system  400  would transmit the appropriate confirmation to the patient via the delivery mode chosen by the provider. Thereafter, if the confirmation is received by the SP module, then the SP module would transmit another enrollment signal back to the third party content provider  400 . However, if the confirmation is received by the third party content provider  400 , then the third party content provider  400  would enroll the patient in the service upon receiving the confirmation from the patient. 
     Referring to  FIG. 9 , an EduSAVET™  900  document according to one embodiment of the present invention is illustrated. The EduSAVE™  900  document comprises a provider information section  901 , an educational information section  902 , and a coupon section  903 . The provider information section  901  comprises information relating to the provider  101  who issued the prescription for the substance to the patient. The educational information section  902  comprises either general and/or specific information relating to the substance being prescribed and/or the disease state of the patient for which the substance is being prescribed. Finally, the coupon section  903  comprises coupon information relating to a discount, a rebate, or a voucher for the patient for the substance being prescribed. Although described as combining provider information, educational information, and coupon information, it should be noted that in alternate embodiments of the present invention, the EduSAVE™  900  document may comprises just educational information and coupon information, or any combination of provider information, patient information, and payor information along with educational information and coupon information. 
     One reason the EduSAVE™  900  document is beneficial is because it provides for a single document that comprises both educational information and coupon information. Therefore, when the patient brings the EduSAVE™  900  document to their pharmacy for redemption of the coupon, they are encouraged to read the educational information provided therewith. Further, if the patient has any questions or concerns regarding the substance after they have left the provider&#39;s office, the patient may easily access the provider&#39;s contact information on the EduSAVE™  900  document. 
     In accordance with one embodiment of the present invention, the central portion  301  of the SP module generates the EduSAVE™  900  document using the process described above. In such embodiments, the central portion  301  of the SP module parses out educational information data from an eligible supplemental program that relates to educational material and coupon data from an eligible supplemental program that relates to a coupon. Thereafter, the central portion  301  of the SP module combines the educational information data, the coupon data, and provider data into a single data format to create the EduSAVE™  900  document. Therefore, the EduSAVE™  900  document may be transmitted by the SP module to the HCP system  100  as a single document of a single data format. After generating the EduSAVE™  900  document, the central portion  301  of the SP module then stores the generated EduSAVE™  900  document in the supplemental program database  303  of the SP system  300  for subsequent applications. 
     As noted above, the supplemental programs comprise both general educational content and specific educational content. In one embodiment of the present invention, the general educational content comprises information relating to the prescribed substance, while the specific educational content comprises information relating, not only to the prescribed substance, but also the specific diagnostic reason(s) that the substance was prescribed to the patient, such as but not limited to, the specific disease(s) for which the substance was prescribed, along with a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances, and external causes of injury or disease for which the substance was prescribed. 
     In one embodiment of the present invention, the SP widget  302  receives an International Classification of Diseases, Ninth Revision (ICD-9) code entered by the provider  101  during the patient&#39;s visit. Specifically, the provider  101  enters an ICD-9 code into the SP widget  302  using the input device  122  of the terminal  120 . The receipt of the ICD-9 code may, but does not necessarily have to be received in conjunction with an electronic prescription. 
     After receiving the ICD-9 code, the SP widget  302  transmits ICD-9 data, relating to the code itself, to the central portion  301  of the SP module to determine whether any supplemental programs relating to the ICD-9 code is available for the patient. Thereafter, the central portion  301  of the SP module uses the ICD-9 data, potentially along with other relevant data, to determine if eligible supplemental programs relating to the ICD-9 code are available. Therefore, the ICD-9 data may be used in addition to the data listed above (e.g., the patient, prescribed substance, provider, and payor data discussed above) by the SP module to determine, from the plurality of available supplemental programs, if there are any supplemental programs for which the patient is eligible based at least partially on the ICD-9 data. If there are eligible supplemental programs available that relate to specific educational content, then the SP module continues as discussed above with reference to  FIGS. 8   a - 8   c  (specifically, picking up at step  808 ). 
     By using the ICD-9 code to determine if there are any eligible supplemental programs, the present invention may provide both general and specific educational material to the patient. For instance, the patient may receive general information relating to the substance they are being prescribed or the disease state in which they are diagnosed, while also receiving specific educational material directed to the specific reason(s) the patient has been prescribed the particular substance. 
     Further, in one embodiment of the present invention, a clinical staff personnel may perform the steps initiated by the provider  101 . A clinical staff personnel may be a nurse, an office or hospital administrator, or any other personnel involved in the health care industry. In such embodiments, the clinical staff personnel would choose a previously prescribed substance to begin the process. Thereafter, the process would continue as described above, ultimately resulting in the patient receiving a document (e.g., coupon, educational material, etc.) or being enrolled in a service. 
     Finally, it should be noted that the SP system  300 , and specifically the SP module, of the present invention further comprises control and management options for the provider  101  or an administrator of the HCP system  100 . Therefore, using the control and management options, the provider  101  or administrator may adjust the look, functionality, and processes of the SP module, including but not limited to, adding, removing, or editing provider and patient preferences, altering the GUIs generated and displayed by the SP module, etc. 
     Referring now to  FIG. 16 , a flow diagram of one method of acquiring patient medication history data according to an embodiment of the present invention is illustrated. As shown, the process begins when the SP module residing on the SP system  300  retrieves data relating to an electronic prescription from the EP module, thereby completing step  1601 . This may be accomplished in a manner similar to as discussed above. 
     Upon receiving the electronic prescription data, the SP module parses the data to determine information relating to the patient, such as, but not limited to the name of the patient, the age of the patient, and other identifying information. Further, the SP module may also parse the electronic prescription data to determine information relating to the prescribed substance, the provider, and/or the payor. Next, the SP module transmits the retrieved patient data (potentially along with other relevant data) to a Medication History Poller System, thereby completing step  1602 . 
     The Medication History Poller System receives and stores the patient data. Next, the Medication History Poller System transmits some of the patient data along with a request for patient medication history information to the pharmacy system  500  and/or the payor system  600 , thereby completing step  1603 . Thereafter, the Medication History Poller System receives medication history data relating to the patient from the pharmacy system  500  and/or the payor system  600 . It should be noted that in other embodiments of the present invention, the Medication History Poller System may be part of the SP module. Further, it should be noted that, as discussed above, the pharmacy system  500  may comprise a prescription routing sub-system  501  (e.g., Surescripts™) and the prescription filling sub-systems  502 . 
     Upon receiving the medication history data relating to the patient, the Medication History Poller System transmits the medication history data relating to the patient back to the SP module residing on the SP system  300 . It should be noted that in some embodiments of the present invention, the Medication History Poller System parses and analyzes the medication history data relating to the patient to determine adherence data relating to the patient, including but not limited to, the patient&#39;s adherence history in general, the patient&#39;s adherence history over a specific time frame, and/or the patient&#39;s adherence history in relation to a specific prescribed substance or plurality of prescribed substances for the same disease state. 
     Upon receiving the medication history data relating to the patient from the Medication History Poller System, the central portion  301  of the SP module uses the patient&#39;s medication history data when determining eligibility of each of the plurality of available supplemental programs. Further, the central portion  301  of the SP module may further store the patient&#39;s medication history information in either or both of the records database  304  or a patient adherence database residing within the memory  313  of the SP system  300 . 
     Referring now to  FIGS. 17-28 , event diagrams for supplementing patient and provider interactions to increase patient adherence according to other embodiments of the present invention are illustrated. It should be noted that the diagrams and methods described in reference to  FIGS. 17-28  are in no way limiting of the present invention. 
     Referring to  FIG. 17 , an event diagram of one method for acquiring provider  101  preference data according to an embodiment of the present invention is illustrated. The method of  FIG. 17  begins when the health care provider  101  logs into the EP module using their terminal  120 . Thereafter, the EP module displays the startup screen to the provider  101  on the display device  121 . Next, the EP module prompts the SP widget  302  to acquire provider preference information from the SP module. Upon being prompted by, the EP module, the SP widget  302  calls the central portion  301  of the SP module. Specifically, as exemplified in  FIG. 17 , the SP widget  302  calls a layout portion of the central portion  301  of the SP module to set the provider&#39;s preferences. 
     According to one embodiment of the present invention, the central portion  301  of the SP module comprises two sub-portions, a layout and an adapter. The layout of the SP module generates the GUIs that are displayed to the provider  101  via the display device  121 . The adapter of the SP module performs, the transmission and receipt of data between the central portion  301  of the SP module and the other modules and systems of the system  1000 . 
     After being called by the SP widget  302 , the layout calls the adapter to set the provider&#39;s preferences. Thereafter, the adapter obtains a plurality of different provider preferences offered by the SP module. Next, the layout determines whether any provider preferences had been previously set by the provider  101  by searching the records database  304  of the SP system  300 . If all of the preferences have been set by the provider  101 , then the process ends. However, if there is at least one unset provider preference, then the layout generates a GUI comprising the unset preferences and transmits the GUI to the SP widget  302 . Upon receiving the GUI, the SP widget  302  displays the GUI comprising the unset provider preferences to the provider  101  via the display device  121 . 
     Next, the provider  101  sets their preferences using the input means  122  and via the GUI displayed on the display device  121 . Thereafter, the SP widget  302  transmits a signal to the layout to set the provider&#39;s preferences. Upon receiving the provider&#39;s preferences, the layout calls the adapter to set the provider&#39;s preferences, and the adapter stores the provider preference information in the records database  304  of the SP system  300 . 
     Referring to  FIG. 18 , an event diagram of one method for storing provider  101  preference data according to an embodiment of the present invention is illustrated. The method begins after the provider  101  selects their preferences in an appropriate GUI generated by the SP module and displayed via the display device  121 . After selecting their preferences, the provider  101  actuates a save button on a GUI displayed by the SP widget  302 . Actuating the save button causes the SP widget  302  to call the layout of the SP module, which in turn calls the adapter of the SP module, which causes the SP module to store the prescribed preference data in the records database  304 . 
     Referring to  FIG. 19 , an event diagram of one method for cancelling provider  101  preferences according to an embodiment of the present invention is illustrated. The method begins when the provider  101  actuates a cancel button on a GUI displayed by the SP widget  302 . This causes the SP widget to close or cancel out of the preference GUI. 
     Referring to  FIG. 20 , an event diagram of one method for selecting supplemental programs according to an embodiment of the present invention is illustrated. The method begins when the provider  101  uses the EP module to create a new electronic prescription for a substance. After creating the electronic prescription, the provider  101  has the ability to modify the prescription using the EP module. Thereafter, the EP module prompts the SP widget  302  with data relating to the electronic prescription. After being prompted by the EP module, the SP widget  302  retrieves electronic prescription data relating to the electronic prescription from the EP module. Upon retrieving the electronic prescription data, the SP widget  302  transmits the data to the layout of the SP module, which in turn transmits the electronic prescription data to the adapter of the SP module. 
     Upon receiving the electronic prescription data, the adapter determines if there are any programs, out of the plurality of available supplemental programs, for which the patient and the electronic prescription are eligible. If there are not any eligible programs, then the process ends. However, if there are eligible supplemental programs, then the layout of the SP module formats the supplemental program option in a created GUI. Formatting may include a selection of the available delivery modes of each supplemental program and the generation of the GUIs that are to present the eligible supplemental programs to the provider  101 . At least one GUI is then displayed by the SP widget  302  to the provider  101 , so that the provider  101  may select and confirm which of the eligible supplemental programs they would like activated for the patient. 
     After the provider  101  makes a selection of eligible supplemental programs, the SP widget  302  transmits the provider&#39;s selections to layout of the SP module. The layout then transmits the provider&#39;s selection to the adapter. Thereafter, the adapter retrieves the selected supplemental programs from the supplemental program database  303  and transmits the selected eligible supplemental programs to the SP widget  302  for display to the provider  101  via the display device  121 . Thereafter, the provider  101  may print the eligible supplemental programs for delivery to the patient. 
     Referring to  FIG. 21 , an event diagram of another method for selecting supplemental programs according to an embodiment of the present invention is illustrated. The method of  FIG. 21  is vastly similar to the method of  FIG. 20 . It should be noted that processes performed by the layout of the SP module in  FIG. 20  are instead performed by the SP widget  302  in the method of  FIG. 21 . Such a system and method may be preferred to reduce the processing that occurs outside of the HCP system  100 . 
     Referring to  FIG. 22 , an event diagram of one method for presenting unexercised options according to an embodiment of the present invention is illustrated. An unexercised option is an eligible supplemental program that the provider  101  did not select and confirm for activation. In one embodiment, the provider  101  may go back at a later time, and select unexercised options for activation by the SP module. This allows the provider  101  to activate supplemental programs for a patient outside of the prescription writing workflow. 
     According to one embodiment of the present invention, the method begins when the provider  101  selects and views a prescription report generated and display by the EP module. The EP module displays a prescription report that comprises icon placeholders, the icon placeholders representing prescriptions that the provider  101  previously selected for a subsequent selection of eligible supplemental programs. Next, the EP module prompts the SP widget  302  with report prescription identification data. Although exemplified as being displayed by the EP module, it should be noted that in alternate embodiments, the prescription report may be generated and displayed by the SP module. 
     Upon receiving the report prescription identification data, the SP widget  302  calls the layout of the SP module for the unexercised options that relate to each of the prescriptions identified by the report prescription identification data. Thereafter, the adapter obtains the unexercised options off the identified prescriptions, and the layout generates HyperText Markup Language (HTML) for placeholders for the unexercised options. Finally, the SP widget  302  instantiates icon Uniform Resource Locators (URLs) for the prescription report. 
     Referring to  FIG. 23 , an event diagram of one method for displaying supplemental program options according to an embodiment of the present invention is illustrated. This process begins when the provider  101  actuates a program icon from the prescription report, discussed above with reference to  FIG. 22 . The EP module receives the provider&#39;s input and prompts the SP widget  302  with the prescription identification. The SP widget  302  then obtains the prescription content from the prescription identification, retrieves the supplemental program options for the prescription and displays the supplemental program options to the provider  101  in an overlay, similar to that exemplified in  FIG. 15 . It should be noted that the SP widget  302  does not have to reach back out to the central portion of the SP module, because in such embodiments the SP widget  302  comprises local memory in which the program options are stored. 
     Referring to  FIG. 24 , an event diagram of one method of the adapter acquiring unexercised options according to an embodiment of the present invention is illustrated. The method exemplified in  FIG. 24  is used when the SP widget  302  does not have stored the unexercised options of the prescriptions identified in the prescription report cached locally on the HCP system  100 . As shown, the method of  FIG. 24  begins with the adapter retrieving the unexercised options. Next, the adapter of the SP module checks to see if the prescription statuses are cached, and determines whether all the prescriptions have statuses that are cached. If not, then the adapter calls the SP module to get prescription statuses for all uncached prescriptions, and the SP module retrieves the prescription statuses from the records database  304 . Thereafter, the adapter combines the statuses of the prescriptions and returns URLs for the unexercised options of each of the electronic prescriptions to the SP widget  302  for provider input. 
     Referring to  FIG. 25 , an event diagram of one method for displaying supplemental program options according to an embodiment of the present invention is illustrated. The method begins with the SP widget  302  displaying supplemental program options to the provider  101  via the display device  121 . The SP widget  302  then reads the electronic prescription context XML and calls the adapter of the central portion  301  of the SP module to get the options for the supplemental program. The SP module then evaluates the prescription context using the rules engine to obtain a list of eligible supplemental programs for the electronic prescriptions. After a list is obtained, the SP module obtains preference data relating to the provider  101  and the patient and composes a display for the supplemental program options. Finally, the SP widget receives a GUI comprising the supplemental program options and displays the GUI to the provider  101  via the display device  121 . 
     Referring to  FIG. 26 , an event diagram of one method for acquiring patient preference data according to an embodiment of the present invention is illustrated. The method begins with the adapter of the SP module receiving a request for patient preference data from the SP widget  302 . The adapter determines whether the patient preferences are cached, and if so the adapter retrieves the patient preferences from the cached memory if not, then the adapter retrieves the patient preferences from the record database  304 . 
     Referring to  FIG. 27 , an event diagram of another method for acquiring provider  101  preference data according to an embodiment of the present invention is illustrated. The method of  FIG. 27  is very similar to that of  FIG. 26 . The method begins with the adapter of the SF module receiving a request for provider preference data from the SP widget  302 . The adapter determines whether the provider preferences are cached, and if so the adapter retrieves the provider preferences from the cached memory. If not, then the adapter retrieves the provider preferences from the record database  304 . 
     Referring to  FIG. 28 , an event diagram of one method for acquiring supplemental programs from a third party content provider  400  according to an embodiment of the present invention is illustrated. The method begins with the adapter calling the SP module for supplemental program documents that have been selected and confirmed by the provider  101 . The SP module obtains one supplemental program at a time. The SP module first determines which supplemental program to fetch and then retrieves the third party content provider  400  identifiers for that particular supplemental program. The identifiers comprise information relating to the third party content provider  400  that stores the supplemental program. After retrieving the identifiers, the SP module calls the third party content provider system  400 . 
     Upon receiving the signal from the SP module, the third party content provider  400  determines whether the request is for a document or a service based on the identifier of the supplemental program. If the request is for a document, then the third party content provider  400  generates the document. If the request is for a service, then the third party content provider  400  configures the service for the patient. Thereafter, the third party content provider  400  transmits a response to the SP module. The SP module then adds the document to a response and repeats the process for each of the supplemental programs that were selected and confirmed by the provider  101 . After documents for all of the supplemental programs has been received by the SP module, the SP module returns the documents to the adapter, which in turn returns the documents to the SP widget  302  for presentation to the provider  101  via display device  121  and provider input. 
     Referring to  FIG. 29 , a schematic diagram of a system for increasing patient adherence through the activation of supplemental programs according to another embodiment of the present invention is illustrated. As shown, the system comprises an HCP system  100 , an EP system  200 , an SP system  300 , and third party content providers  400 . 
     While the embodiment of the present invention has been described with reference to the accompanying drawings, it can be understood by those skilled in the art that the present invention can be embodied in other specific forms, without departing from its spirit or essential characteristics. Therefore, the foregoing embodiments and advantages are merely exemplary and are not to be construed as limiting the present invention. The present teaching can be readily applied to other types of apparatuses. The description of the foregoing embodiments is intended to be illustrative, and not to limit the scope of the claims. Many alternatives, modifications, and variations will be apparent to those skilled in the art. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents but also equivalent structures.