Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
MEDICAMENT MANAGEMENT METHODS
Document Type and Number:
WIPO Patent Application WO/2011/054004
Kind Code:
A1
Abstract:
The invention relates to methods for managing patient medicament and providing intelligent medicament solutions. More specifically, the present invention discloses electronic medicament support methods designed to provide intelligent medicine support solutions, by incorporating advanced therapeutics that integrate smart, wireless medicament dispensers into an interactive process designed to improve clinical outcome across a wide range of chronic diseases by improving patient medicament consumption, compliance, and quality of life.

Inventors:
GLIMM MARKUS (GB)
HARGER ECHO (US)
Application Number:
PCT/US2010/055169
Publication Date:
May 05, 2011
Filing Date:
November 02, 2010
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
TRXCARE HOLDING S A R L (LU)
GLIMM MARKUS (GB)
HARGER ECHO (US)
International Classes:
G06Q10/00; G06Q30/00
Foreign References:
US20080201174A12008-08-21
US20090070136A12009-03-12
US20080027291A12008-01-31
US20070016443A12007-01-18
Attorney, Agent or Firm:
LEVY, Seth, D. et al. (865 South Figueroa StreetSuite 240, Los Angeles CA, US)
Download PDF:
Claims:
CLAIMS

WHAT IS CLAIMED IS:

1. A method for medicament management, comprising:

providing a scheduler comprising a medicament access regimen that includes a predetermined time interval wherein a patient is expected to take a medicament;

monitoring for receipt of an indication of an expected medicament access event from a medicament management device from a remote monitoring location;

analyzing whether the indication of the expected medicament access event is received with regard to the predetermined time interval to determine a behavior of the patient; and

in response to the analyzing, sending a communication to the medicament management device regarding the patient's adherence to the medicament access regimen.

2. The method of claim 1 , wherein the communication comprises a reminder intervention prompting the patient to take a medicament at a specified time.

3. The method of claim 1 , further comprising storing patient-specific information regarding the patient's preferences for receiving communications relating to adherence to the medicament access regimen, wherein the sending a communication is dependent on the patient-specific information.

4. The method of claim 1 , further comprising sending a communication to a device other than the medicament management device regarding the patient's adherence to the medicament access regimen.

5. The method of claim 1 , further comprising:

providing escalation criteria that determines conditions when reminder interventions are to be sent to the patient; and

sending a communication to the medicament management device according to

19

DWT 15851872v2 0090765-002WO0 the provided escalation criteria.

6. The method of claim 1 , wherein the communication is directed to a device other than the medicament management device.

7. The method of claim 1 , further comprising:

storing data for a plurality of patients, the data relating to one or more of patients' profiles, preferences, medicament access schedules, medicament access event histories, and intervention histories; and

integrating the data from multiple patients into homogenous meta-data sets usable for scientific research.

8. The method of claim 7, wherein the stored data comprises data received from a third party.

9. The method of claim 7, further comprising developing an empirically and theoretically derived model for use in analytics based on the stored data.

10. The method of claim 7, further comprising providing a portal to allow third parties access to at least a subset of the integrated data.

11. The method of claim 1 , wherein the analyzing comprises providing a model that is operative to assist in determining the patient's behavior regarding adherence to the medicament access regimen.

12. The method of claim 1 1 , wherein the model comprises at least one of an inferential state model, a predictive model, and a behavior change model.

13. The method of claim 1 , further comprising obtaining case management data and clinical data, wherein the sending a communication is dependent on the received case management data and clinical data.

20

DWT 15851872v2 0090765-002WO0

14. The method of claim 1 , further comprising:

storing data for a plurality of patients, the data relating to one or more of patients' profiles, preferences, medicament access schedules, medicament access event histories, and intervention histories;

segmenting the stored data into analytical data sets based on a field of study for use by a health product or service provider; and

analyzing the segmented data according to predetermined business intelligence analytics to determine a response to a query of the health product or service provider.

15. The method of claim 14, wherein the data is segmented according to one or more factors comprising regional, socio-demographic, disease group, treatment regimen group, hospital, and healthcare provider.

16. A system for medicament management, comprising:

a transaction handling and reminder module operative to communicate remotely with a medicament management device of a patient, the communication including at least monitoring for indications of medicament access events received from the medicament management device and sending reminder interventions to the

medicament management device according to an intervention schedule; and

a coaching intervention module operative to receive data from the transaction handling and reminder module relating to a medicament regimen for the patient, to analyze the received data using model-based analytics, and to modify the intervention schedule of the transaction handling and reminder module based on the results of the analysis.

17. The system of claim 16, further comprising:

a clinical support and coaching module operative to develop a clinical data set and a case management data set, and further operative to provide the clinical data set and the case management data set to the transaction handling and reminder module for use in determining the intervention schedule.

21

DWT 15851872v2 0090765-002WO0

18. The system of claim 17, wherein the clinical data set comprises at least one of treatment plan and prescriptions, general health data and co-conditions, and lab reports for the patient.

19. The system of claim 17, wherein the case management data set comprises a coaching data set and information provided by the patient.

20. The system of claim 16, further comprising:

a research data clearinghouse module operative to receive data gathered from the transaction handling and reminder module, and further operative to integrate and fuse the data into homogenous meta-data sets usable for scientific research.

21. The system of claim 20, wherein the received data comprises data regarding patients' health state indicators and data regarding patients' adherence to medicament regimens.

22. The system of claim 20, wherein the research data clearinghouse module is further operative to receive data from a third party.

23. The system of claim 20, wherein the research data clearinghouse module comprises a portal for allowing third parties to access or submit data to the system.

24. The system of claim 16, further comprising:

a pharmaceutical and health product support module operative to receive empirical data from the transaction handling and reminder module, the empirical data relating to a plurality of patients' adherence to medicament regimens, and further operative to perform business intelligence analytics on the data to answer a query received from a health product or service provider.

25. The system of claim 24, wherein the pharmaceutical and health product

22

DWT 15851872v2 0090765-002WO0 support module is further operative to segment the received data based on a field of study for a particular health product or service provider.

26. The system of claim 24, wherein the pharmaceutical and health product support module is further operative to send a data collection plan to the transaction handling and reminder module.

27. An article of manufacture, comprising a computer readable medium having computer readable program code embodied therein for medicament

management, the computer readable program code in said article of manufacture comprising computer readable program code operative to cause a computer to execute: a transaction handling and reminder process operative to communicate remotely with a medicament management device of a patient, the communication including at least monitoring for medicament access events received from the medicament management device and sending reminder interventions to the medicament

management device according to an intervention schedule; and

a coaching intervention process operative to receive data from the transaction handling and reminder process relating to a medicament regimen for the patient, to analyze the received data using model-based analytics, and to modify the intervention schedule of the transaction handling and reminder process based on the results of the analysis.

28. The article of manufacture of claim 27, further comprising computer readable program code operative to cause a computer to execute:

a clinical support and coaching process operative to develop a clinical data set and a case management data set, and further operative to provide the clinical data set and the case management data set to the transaction handling and reminder process for use in determining the intervention schedule.

29. The article of manufacture of claim 27, further comprising computer readable program code operative to cause a computer to execute:

23

DWT 15851872v2 0090765-002WO0 a research data clearinghouse process operative to receive data gathered from the transaction handling and reminder process, and further operative to integrate and fuse the data into homogenous meta-data sets usable for scientific research.

30. The article of manufacture of claim 27, further comprising computer readable program code operative to cause a computer to execute:

a pharmaceutical and health product support process operative to receive empirical data from the transaction handling and reminder process, the empirical data relating to a plurality of patients' adherence to medicament regimens, and further operative to perform business intelligence analytics on the data to answer a query received from a health product or service provider.

31. A method for medicament management, comprising:

monitoring for medicament access events received from the medicament management device of a patient;

sending reminder interventions to the medicament management device according to an intervention schedule;

developing a clinical data set and a case management data set; and

modifying the intervention schedule dependent on the content of the clinical data set and the case management data set.

32. The method of claim 31 , further comprising:

receiving data relating to a medicament regimen for the patient;

analyzing the received data using model-based analytics; and

modifying the intervention schedule based on the results of the analysis.

24

DWT 15851872v2 0090765-002WO0

Description:
MEDICAMENT MANAGEMENT METHODS

FIELD OF THE INVENTION

The present invention relates to methods for managing patient medicament and providing intelligent medicament solutions. More specifically, the present invention relates to electronic medicament support methods designed to improve patient medicament consumption, compliance, and quality of life.

BACKGROUND OF THE INVENTION

All publications cited herein are incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference. The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

Advancements in pharmacology and medicine have afforded numerous individuals the opportunity to prolong and improve their lives with the aid of drugs and therapies. Advancements in treating cancer, AIDS, diabetes and various other ailments have produced various drugs that substantially enhance physical or mental well-being. Although most ailments may be treated by one drug, various ailments require treatment with one or more combination of drugs. In addition, various dosage regimens require irregular intervals and asystematic increases and decreases in dosage. Combined with the fact that a majority of individuals taking drugs are elderly, disabled, cognitively impaired, or patients with psychiatric disorders, it is not uncommon to have patients forget to take their medication, forget their recommended dosage, or forget that they have already taken a dose. In addition, due to large shifts in a patient's psychological disposition, usually caused by their condition or medication, medication compliance may be erratic or inconsistent, rendering medication management by a physician very difficult and unpredictable.

Unfortunately, the result of the medicament miscues may affect the course of the

1

DWT 15851872v2 0090765-002WO0 ailment, treatment of patients and/or reactions to misdosage. Despite great advances in medicine, there are numerous studies listing the mismanagement of drug dosage and treatment as the primary cause for unsatisfactory drug therapy. Some factors attributing to this mismanagement include poor compliance with medicament regimen as patients forget to take their medicaments; frequent need for refills and visits to the health care professional's office to monitor and amend medicament regimen; lack of adequate health education and inadequate reinforcement thereof; under or over dosing of medicament; altered dosing regimen; and incorrect administration of medicament.

Further frustrating the matter is the common practice of patients failing to inform their physicians of their non-compliance, leading to changes in medicament dose and/or the addition or substitution of other drugs.

Due to the disadvantages associated with the current methods for medicament monitoring and dispensing, as evidenced above, there exists a need in the industry for a method of monitoring, recording, and predicting medicament consumption and compliance, leading to consistent medicament regimens and improved quality of life for the patient. Additionally, there exists a need for medicament dispensing methods capable of regimenting, refilling, and dispensing medicament, and for reminding a patient when and how much of a given medicament to take. BRIEF DESCRIPTION OF THE FIGURES

Exemplary embodiments are illustrated in referenced figures. It is intended that the embodiments and figures disclosed herein are to be considered illustrative rather than restrictive.

Figure 1 depicts a flow chart of a smart medicament management method in accordance with an embodiment of the present invention.

Figure 2 depicts a flow chart of a transaction handling and reminder sub-process of a smart medicament management method in accordance with an embodiment of the present invention.

Figure 3 depicts a flow chart of a coaching intervention selection sub-process of a smart medicament management method in accordance with an embodiment of the present invention.

2

DWT 15851872v2 0090765-002WO0 Figure 4 depicts a flow chart of a research data clearinghouse sub-process of a smart medicament management method in accordance with an embodiment of the present invention.

Figure 5 depicts a flow chart of a clinical support and coaching sub-process of a smart medicament management method in accordance with an embodiment of the present invention.

Figure 6 depicts a flow chart of a pharmaceutical product support sub-process of a smart medicament management method in accordance with an embodiment of the present invention.

Figure 7 depicts a flow chart of the flow of data between the sub-processes of the smart medicament management method shown in Figure 1.

Figure 8 depicts an example of a hardware and operating environment in which the smart medicament management method may be practiced. DETAILED DESCRIPTION

All references cited herein are incorporated by reference in their entirety as though fully set forth. One skilled in the art will recognize many methods, apparatus and materials similar or equivalent to those described herein, which could be used in the practice of the present invention. Indeed, the present invention is in no way limited to the methods, apparatus and materials described.

The invention relates to methods for managing patient medicaments and providing intelligent medicament solutions. More specifically, the present invention relates to electronic medicament support methods designed to provide intelligent medicament support solutions, by incorporating analytics, algorithms, and computer, network, and telecommunications technologies that integrate smart, wireless

medicament dispensers into an interactive process designed to improve clinical outcomes across a wide range of chronic diseases by improving patient medicament consumption, compliance, and quality of life.

The inventive methods provide vital health-state indicators for patients to access, share and self-manage. The inventive methods further select appropriate interventions

3

DWT 15851872v2 0090765-002WO0 to improve patient behavior and may advance actionable information to physicians or healthcare professionals in advancing the quality of care.

The inventive systems (and methods) provide greatly needed medicine support for patients living with long-term illnesses. This is accomplished by linking-in patients to the right health care resources at the right time and building a care plan that evolves with the patient over time.

With the inventive method, system, and article of manufacture described herein, health care professionals and patients can monitor treatment progress in real-time. The systems improve case management for chronic diseases with focus on self

management enabling adherence and access to health advisors, counselors, psychologists, and community treatment advocates as required. The systems also link or network smaller clinics to larger centers, improve patient education (na ' ive, pregnancy, nutrition), and leverage health promotion services.

The systems' early interventions (real-time) improve adherence and outcome, significantly reduce skipped appointments and reduces the number of patients

'dropping-in' clinics without an appointment to refill. The systems improve clinician - patient communication, patient access to pharmacist, and may lead to less frequent hospital visits. The systems also monitor patients and their progress in real-time, thereby improving quality of clinical care, reducing costs, and increases efficiencies. The systems' long-term interventions may evolve based on the patient's past behaviors, clinical progress, and treatment goals.

The systems also provide for partner notification and customized content. They feature medication initiation support (information on side effect coping), information and feedback tools, thereby promoting self-management, reduced number of clinic visits, improved clinical outcome, and improved quality of life (evidenced-based).

Referring now to the drawings, Figure 1 depicts a flow chart of a smart medicament management method 100 in accordance with an embodiment of the present invention. Figure 1 provides an outline of a process (or system) by which a transaction handling and reminder sub-process 200 ("XTP"), a coaching intervention selection sub-process 500 ("CCP"), a research data clearinghouse sub-process 400 ("RDCP"), a clinical support and coaching sub-process 300 ("CISP"), and a

4

DWT 15851872v2 0090765-002WO0 pharmaceutical product support sub-process 600 ("PPSP") interact and communicate to accomplish aspects of the inventive methods. Each sub-process (or module) may work independently (i.e., as a stand-alone system), semi-independently or in an integrated fashion with the other sub-processes described herein, to achieve the desired medicament management objectives. Figures 2-6 each provide functional diagrams of the individual sub-processes 200, 300, 400, 500, and 600, respectively, of the smart medicament management method 100 shown in Figure 1. Figure 7 depicts a flow chart of the flow of data between the sub-processes 200, 300, 400, 500, and 600. Each of these sub-processes is now described.

TRANSACTION HANDLING AND REMINDER SUB PROCESS (XTP)

Figure 2 depicts a detailed flow chart of the interrelationship between

components, processing of information, and exchange of data in the transaction handling and reminder sub-process (XTP) 200 of the smart medicament management method 100 shown in Figure 1. Figures 1 and 7 also depict the relationship between the XTP 200 and other sub-processes of the inventive methods.

The XTP 200 receives communications from remote sources such as patient devices, web portals 60, direct uplink, or manual entry. In the case remote monitoring and electronic transmission, data enters the process 200 through the XTP server 210 (see Figure 2). Once within the process the XTP 200 stores and maintains patient data 68 (see Figure 7) in a patient data set storage 224, including treatment plan,

medicament, preferences, socio-demographic data, physician information, historical medication reports, condition management data, medicament side-effects, quality of life surveys, motivational data, informational background data, and/or other information pertinent to medicament management and care. The XTP's 200 primary role is to issue short-term medicament adherence messages and reminders 210 (or "interventions" 62) to a patient.

Medicament access events, medicament alerts, and other data 64 are

transmitted via wireless signals from remote monitoring locations, such as patients' medicament dispensers, to the XTP 200. The wireless signals are received at the server 210 and enter the XTP 200. In an alternative embodiment, patient and

5

DWT 15851872v2 0090765-002WO0 medicament information may be uploaded to the XTP 200 by a healthcare professional or at the direction of a healthcare professional. If a medicament access event is registered, step 236, and the event time is consistent with the prescribed medicament regimen, step 232, the event is logged in an events data set 216 (see Figure 2). If no event arrives, or if an event arrives outside a prescribed window, then a scheduler 240 initiates an intervention process 204. Intervention parameters (e.g., time, type, number, escalation criteria, etc.) may vary greatly from patient to patient, and are stored in a patient preferences data set 224. An intervention along with the appropriate channel 208 (SMS message to cell phone, e-mail, medicament dispenser vibration, medicament dispenser touch screen, etc.) are selected, step 212, and transactions are logged in the intervention data set 220 as well as in the events data set 216.

Dependent on whether escalation criteria have been met, step 228, multiple interventions of differing types may be issued by the XTP 200. In one example, a cellular phone message is sent to the patient after a 10-minute access grace period. After an additional 20 minutes have passed, if no medication access event has occurred, then an e-mail is sent to a patient-elected family member or other designated individual (escalation). In some cases, patients may be given an opportunity to

"snooze" reminders or halt escalation mid-process if, for instance, reminders are intrusive.

Interventions may be issued directly to patients, to elected third parties, or to healthcare providers. Interventions may be issued by various means, including cellular phone, medicament dispenser device, web portal, clinic staff, telephone, e-mail, and other means known in the art, including any and all communication means capable of real-time or similar communication.

Patient data sets 224 (including patient profiles, preferences, and schedules), events 216, and intervention data sets 220 are accessible by the RDCP 400, the CCP 500, and the CISP 300 (see also Figure 7). In addition, the CISP 300 may trigger interventions. If an intervention process is triggered by the CISP 300, the intervention will be logged in the Interventions data set 220 (see Figure 2) and issued via the XTP 200.

6

DWT 15851872v2 0090765-002WO0 In the XTP 200, the server 210 prompts medicament intake by a patient at a prescribed time interval. If the medicament is accessed by the patient, step 236, the XTP 200 is reset for the next prescribed intake. If the medicament is not accessed by the patient, the event is escalated to Interventions. Additionally, if the medicament is accessed at a non-prescribed time, the event is escalated to Interventions 220. An intervention prompts the patient to take the medicament satisfying certain criteria at the prescribed time. If the patient accesses the medicament and meets the criteria, the XTP 200 is reset for the next prescribed intake. If the medicament is not accessed by the patient or the patient does not meet the criteria, the event is again escalated to Intervention 220. Interventions 220 are capable of various degrees of intervening prompts to the patient, therefore the XTP cycle is boundless. In certain instances, a medicament access event may take place without a prompt and/or intervention, such as medicament that is not a prescribed a dosage time {e.g. take as needed). Throughout the entire process, all medicament access events, non-access events, intervention events, and information related to the events are logged in the Patient Profile

Preferences Schedules data set ("PPPS") 224, and logged in the comprehensive events data set ("ED") 216. Detailed information logged in the PPPS 224 and ED 216 may be shared with the RDCP 400, CISP 300, CCP 500, and PPSP 600 (see Figure 7).

The benefits of the XTP 200 to the patient include assisting patients in

remembering when to take medication, without overly intrusive reminder messages, as well as providing disease-management and motivational information for patients via real-time communication means. Further attributes of the XTP 200 include the collection of patient contributed data directly or via portal (e.g., the patient portal 60), such as quality of life ("QoL") and side effects, for patient self-analysis and

management.

RESEARCH DATA CLEARINGHOUSE SUB PROCESS (RDCP)

Figure 4 depicts a detailed flow chart of the interrelationship between

components and exchange of data in a research data clearinghouse sub-process (RDCP) 400 of the smart medicament management method 100. Figures 1 and 7

7

DWT 15851872v2 0090765-002WO0 further depict the relationship between the RDCP 400 and other sub-processes of the inventive methods.

The RDCP 400 functions to provide general pharmacoviligence and disease specific treatment data for both internal research 426 and external (e.g., third party) research 74 (see Figure 1 ). This is accomplished by incubating new technologies, scientific insights, and clinical correlations for analytical uses within the process 400, third party researchers, or customer support. The RDCP 400 comprises a Research Clearinghouse Database 406 that includes an infrastructure and process for storing and disseminating large quantities of research data, for use in internal research 426, for use in research by 3rd party organizations 70, or for release to the public domain 72.

Algorithms are incorporated for cataloging research data.

Patient data 414 and 418 such as health state indicators, adherence, and other data generated by the inventive process's patient support services are collected via the XTP 200 (see also Figure 7). The data is anonymized and cleared through all relevant patient confidentiality, ethical and other appropriate guidelines, regulations and systems (e.g., HIPPA and contractual review processes), step 410, before being released into the Research Clearinghouse Database 406 (see Figure 4). Once within the Research Clearinghouse Database 406, the data may be included with data 422 donated from third party researchers and/or other third party references 70. The multiple,

heterogeneous data sets 414, 418, and 422 may be available in their original forms, available for search by meta-descriptions, abstracts, or free text. In addition, the data may be fused using a data integration and fusion process 402 to generate

homogeneous, yet scientifically usable, meta-data sets for additional studies.

Within the data integration and data fusion process 402, data feeds are profiled for correctness, completeness, and relevance. Where useful to data consumers, relevant data is extracted and transferred into new data sets. Where transfer is required, ontological mapping may be used to ensure data quality and provide maximum utility to future researchers. The new data sets are loaded into the Research Clearinghouse Database 406 for use.

DWT 15851872v2 0090765-002WO0 The RDCP 400 includes the 3rd party research portal 70 that allows for third parties to access data from the RDCP 400 using the process and/or provide data to the RDCP 400 using the process.

Within the inventive methods, the fused data sets may be used for development of models 404 (see Figure 1 ) for use in model-based analytics that support patient, pharmaceutical, and clinic support. These models 404 are experimentally derived using the provided data and are used for inferential, predictive, and other model-based analytics within the Coaching Intervention Selection Sub Process (CISP) 300 (see Figures 3 and 7).

The end result benefits of the RDCP 400 are abridgment of quality assured and anonymized data sets available in the public domain, and by private subscription, for the purpose of third party research to further scientific knowledge of disease domains.

COACHING INTERVENTION SUB PROCESS (CISP) Figure 3 depicts a detailed flow chart of the interrelationship between

components, processing of information, and exchange of data within the coaching intervention selection sub-process (CISP) 300 of the smart medicament management method 100. Figures 1 and 7 further depict the relationship between the CISP 300 and other sub-processes of the inventive methods.

Unlike the XTP 200, which is targeted towards issuing short term, tactical interventions, the CISP 300 exists to generate longer-term, strategic interventions aimed at long-term disease management goals. The CISP 300 may also select short- term interventions whenever these interventions require model-based analytics. The CISP 300 applies model-based analytics, algorithms, and artificial intelligence techniques to develop patient support and disease management activities. The CISP 300 relies on the application of theoretically and empirically derived models 460 for model-based analytics. The models 460 are developed as part of the RDCP 400 system and are employed within the CISP 300 (see also Figure 7). The CISP 300 may also include models selected from the public domain 40. Individual models 460 may be specific to a patient group, drug regimen, geographic region or other relevant factors. For this reason, the process 300 starts with segmenting patient records or data into the

9

DWT 15851872v2 0090765-002WO0 appropriate factors for model selection, step 312. One or more models are then chosen for analysis, step 310, as described below.

The primary types of analysis are performed using three different types of models stored in an Al model storage database 306. First, inferential state models 314 (see Figure 3) allow the process 300 to derive a conclusion about a patient's state given preexisting data about the patient. An example of an inferential state model 314 would be a Patient Current State Appraisal model 326. In an example of the Patient Current State Appraisal model, the remote monitoring capabilities of the XTP 200 record when a patient accesses the medication. However, the XTP 200 has no direct evidence proving whether the patient consumed the medication (an intake). In some cases, patients may access medication several times an hour. For example, a patient may open a medicament dispenser at 10:05 am, and then open the medicament dispenser again at 10:10 a.m. It is unlikely the patient took two doses - especially if a blister pack or tub is being used. An intake inference model contains previously observed patterns of behavior, collected either from the individual patient or from a representative group of patients. The behaviors of the current patient are then matched against the observed patterns, and a conclusion, whether one or two doses were consumed, is developed. In this example, the process has used a model-based approach to infer if medication was consumed from data regarding pill access times.

A secondary type of model is a Predictive Model 318. Predictive models are probabilistic in nature, based on statistical analysis of large data sets. Predictive models utilize known patient past events, a known patient current state, and a probabilistic model representing a similar patient groups outcomes to generate probabilities of certain outcomes. An example of a probabilistic model would be a Bayesian model predicting adherence rates based on socio-demographic data.

A third type of model is a Behavior Change Model 322. The Behavior Change model 322 provides a map of empirically or theoretically defined stages of behavior change. The patient's progress through the states of change are tracked while appropriate stage-specific interventions are used to promote change. One example of a Behavior Change Model 322 in the public domain is the Transtheoretical Model ("TTM"). The TTM is based on six stages of change: precontemplation, contemplation,

10

DWT 15851872v2 0090765-002WO0 preparation, action, maintenance, and termination. Within the TTM, interventions are matched to specific stages for maximum effectiveness.

Once appropriate models are applied and evaluated, a strategic intervention goal is selected, step 334. Interventions from the CISP 300 may be strategic in nature and may include clinical intervention tactics such as patient training or educational suggestions, patient interview suggestions like guided environmental re-evaluation, or direct contact interventions such as operant conditioning.

Once the intervention goal and content are selected, a communication plan may be selected, 330. The communication plan further frames the intervention for maximum effectiveness. Models 338 including persuasion, neuro-linguistic programming (NLP), or corrective communication theory may be used to frame the intervention in a way that increases the probability that the patient will heed the advice.

Finally, the intervention plan and communication plan are returned to either the

XTP 200 or the CCP 500 for issuing (see also Figure 7). Direct, short-term

communication events are sent to the XTP 200, which will handle the intervention transaction. Interventions intended for the patient portal 60 also are processed by the

XTP 200. Longer term, coaching interventions are sent to the CCP 500 for clinic staff to execute immediately, at a specified time, or at the scheduled coaching sessions.

As discussed above, the models data sets ("MD") 306 are used in conjunction with the individual Patient Segmentation Appraisal 312 to determine the patient's

Strategic Intervention Goal Selection 334 and Patient Current State Appraisal 326. The

Strategic Intervention Goal Selection 334 and Patient Current State Appraisal 326 are utilized by communication models to choose the Communication Plan Selection 330 specific to the patient. Models used in communication plan selection may include, but are not limited to, Framing, Congruency, NLP, and persuasion communication models

338. The Communication Plan Selection 330 is then implemented by the XTP 200, through direct intervention, and the CCP 500, through clinical intervention.

The CISP 300 provides actionable strategies and support content for clinical and direct interventions that are based on insights derived from knowledge gained within the larger patient group, and from the specific patient. The inferential and predictive capabilities incorporate by the CISP 300 establish long-term techniques to support

11

DWT 15851872v2 0090765-002WO0 patient disease management, which are congruent with patient perceptions leading to acceptance and adoption.

CLINICAL SUPPORT AND COACHING SUB PROCESS (CCP) Figure 5 depicts a detailed flow chart of the interrelationship between

components and exchange of data in the clinical support and coaching sub-process (CCP) 500 of the smart medicament management method 100. Figures 1 and 7 further depict the relationship between the CCP 500 and other sub-processes of the inventive methods.

The CCP 500 encompasses activities for implementing patient support through healthcare professionals and for gathering patient care data for implementation into the inventive methods. Patient information, including Treatment Plan & Prescription 528, General Health Data Co-Conditions 524, and Lab Reports 520 are gathered to establish a patient Clinical Data Set 516. In addition, a patient's Historical Adherence Reports and Analysis 536, and Coaching Plan 540 are gathered to establish a Coaching Data Set 532. The Coaching Data Set 532 is supplemented with Client/Patient Meetings 506 to review medicament management and to determine the educational and medicament compliance goals 502 (see Figure 1 ) of the patient. Various goals of the Client/Patient Meetings are to collect information 510 from the patient (e.g., via a patient portal 50 shown in Figure 1 ), including medicament side effects, privacy preferences,

treatment/QoL goals, Necessity-Concerns, and socio-demographics. The information 510 is further compiled with the Coaching Data Set 532 to provide a patient specific Case Management Data Set 508. The Case Management Data Set 508 is then combined with the Clinical Data Set 516 and sent to the XTP 200 for aiding in implementing a patient medicament compliance regimen. This data may be sent using any suitable format 512 (e.g., web portal, PDF, FAX, e-mail, XML, or the like).

Benefits attributed to the CCP 500 may include building strategic case management relationship that promotes self-adoption of healthy behaviors in the patient, improving QoL, and providing an avenue for patients to share and receive support for their treatment concerns.

12

DWT 15851872v2 0090765-002WO0 PHARMACEUTICAL & HEALTH PRODUCT SUPPORT SUB PROCESS (PPSP)

Figure 6 depicts a detailed flow chart of the interrelationship between

components and exchange of data in the pharmaceutical product support sub-process (PPSP) 600 of the smart medicament management method 100. Figures 1 and 7 further depict the relationship between the PPSP 600 and other sub-processes of the inventive methods.

The PPSP 600 is designed to help patients and health product / service providers to collaborate and increase the options and effectiveness of treatment options on the market. The PPSP 600 starts with business intelligence analysis of data 450 collected within the Research Data Clearinghouse sub-process (RDCP) 400. Appropriate data is queried for analytics. Optionally, non-anonymized data (e.g., patient data sets 224, clinical data sets 516, events data sets 216, and case management data sets 506) could be used directly from the XTP 200 if patients have consented to participate directly in the research (see also Figure 7). Otherwise, only data donated by patients for the purposes of anonymized research may be used.

The data is segmented into appropriate analytical data sets based on the field of study for the particular health product / service providers 80 ("Client"), step 602.

Factors for segmentation may include, regional, socio-demographic, disease group, treatment regimen group, hospital, healthcare provider, or other factors believed to be relevant in the content and bounds of the Client's query.

Once the data set is selected, business intelligence analytics 606 are used to answer the questions at hand. Several samples of analytics used are listed below, but the process is not limited to those samples.

For example, a patient lifecycle view reports, tracks, and analyzes patient preferences, outcomes, and biomarkers over the lifecycle of the patient's enrollment in the process. The patient lifecycle view allows researchers to look for commonalities in patient groups that occur during long-term treatment and treatment change events, such as medication changes.

As another example, the market constraint view analytical process is based on the five focusing steps of the Theory of Constraints introduced by Dr. Eliyahu Goldratt in 1984. The market constraint view reports, tracks, and identifies the constraining study

13

DWT 15851872v2 0090765-002WO0 population that is not responding to an improvement initiative. An example of an improvement initiative could be a patient education campaign to reduce the quality of life impacted by medicament having a drowsiness side effect. The market constraint view may show that most of the patients who are reporting drowsiness are taking the medication in the morning, although the medication can be taken at any time of the day. Patients taking the medication at night are not reporting drowsiness. Based on this information, the Client may wish to provide advice to the morning dose patient population suggesting they try taking the medication at night.

In addition to the Patient Lifecycle analysis and Market Constraint analysis, the PPSP 600 also supports post market surveillance, clinical trial surveillance, and general statistical analytics.

Based on the results of the analysis, Clients 80 may wish to proceed with their internal decision making process or solicit more feedback from the study population or donated data sets. If more feedback is needed, patient surveys, solicitations, and other support can be provided through the multi-channel communications system of the XTP 200.

If the Client 80 desires patient feedback, step 612, the PPSP 600 may solicit the feedback, and in combination with the results of the computations and analysis, to establish an Integrated Multi-Channel Product/Service Plan 604. In this regard, the PPSP 600 may send data 605 comprising data collection plans and Multi-channel

Product/Service Plans to the XTP 200. The Integrated Multi-Channel Product/Service Plan 604 outlines the strategies for using the inventive method's communication channels of the XTP 200 for communication with patients. If the Client 80 does not desire patient feedback, the results of the computations and analysis may be used to establish Product Support Conclusions 616 and proper channels for

Marketing/Research and Development Investing. In an alternative embodiment, a Client may decide to solicit patients after the initial computations and analyses are reported to the Client. Furthermore, the Client may wish to conduct multiple rounds of patient feedback for using the Integrated Multi-Channel Product/Service Plans 604 in order to refine Marketing/Research and Development Investment Plans.

14

DWT 15851872v2 0090765-002WO0 As evidenced above, the benefits of the PPSP 600 include optimization of product and service Client investments in marketing, education, and research and development avenues that focus on large impact in organizational goals. Furthermore, the PPSP 600 allows patients to participate in product or service provider development processes including product development, marketing, and clinical trial participation, which increases treatment effectiveness and patient satisfaction.

Figure 8 is a diagram of an example hardware and operating environment in which implementations of the smart medicament management method 100 described above may be practiced. The description of Figure 8 is intended to provide a brief, general description of suitable computer hardware and a suitable computing

environment in which implementations may be practiced. Although not required, implementations are described in the general context of computer-executable

instructions, such as program modules, being executed by a computer, such as a personal computer, a server, or the like. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.

Moreover, those skilled in the art will appreciate that implementations may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Implementations may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through one or more communications networks. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The exemplary hardware and operating environment of Figure 8 includes a general-purpose computing device in the form of a computing device 812. As can be appreciated, the processes and sub-processes described above may be implemented using one or more computing devices similar the computing device 812.

The computing device 812 includes the system memory 822, a processing unit 821 , and a system bus 823 that operatively couples various system components, including the system memory, to the processing unit. There may be only one or there

15

DWT 15851872v2 0090765-002WO0 may be more than one processing unit 821 , such that the processor of computing device 812 comprises a single central-processing unit (CPU), or a plurality of

processing units, commonly referred to as a parallel processing environment. The computing device 812 may be a conventional computer, a distributed computer, or any other type of computer.

The system bus 823 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory may also be referred to as simply the memory, and includes read only memory (ROM) 824 and random access memory (RAM) 825. A basic input/output system (BIOS) 826, containing the basic routines that help to transfer information between elements within the computing device 812, such as during start-up, is stored in ROM 824. The computing device 812 further includes a hard disk drive 827 for reading from and writing to a hard disk, not shown, a magnetic disk drive 828 for reading from or writing to a removable magnetic disk 829, and an optical disk drive 830 for reading from or writing to a removable optical disk 831 such as a CD ROM, DVD, or other optical media.

The hard disk drive 827, magnetic disk drive 828, and optical disk drive 830 are connected to the system bus 823 by a hard disk drive interface 832, a magnetic disk drive interface 833, and an optical disk drive interface 834, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer- readable instructions, data structures, program modules, and other data for the computing device 812. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, USB drives, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may be used in the exemplary operating environment. As is apparent to those of ordinary skill in the art, the hard disk drive 827 and other forms of computer- readable media (e.g., the removable magnetic disk 829, the removable optical disk 831 , flash memory cards, USB drives, and the like) accessible by the processing unit 821 may be considered components of the system memory 822.

16

DWT 15851872v2 0090765-002WO0 A number of program modules may be stored on the hard disk drive 827, magnetic disk 829, optical disk 831 , ROM 824, or RAM 825, including an operating system 835, one or more application programs 836, other program modules 837, and program data 838. A user may enter commands and information into the computing device 812 through input devices such as a keyboard 840 and pointing device 842.

Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 821 through a serial port interface 846 that is coupled to the system bus 823, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). A monitor 847 or other type of display device is also connected to the system bus 823 via an interface, such as a video adapter 848. In addition to the monitor 847, computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computing device 812 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 849. These logical connections are achieved by a communication device coupled to or a part of the computing device 812 (as the local computer). Implementations are not limited to a particular type of communications device. The remote computer 849 may be another computer, a server, a router, a network PC, a client, a memory storage device, a peer device or other common network node, and typically includes some or all of the elements described above relative to the computing device 812. The remote computer 849 may be connected to a memory storage device 850. The logical connections depicted in Figure 8 include a local-area network (LAN) 851 and a wide-area network (WAN) 852. Such networking environments are commonplace in offices, enterprise- wide computer networks, intranets and the Internet.

When used in a LAN-networking environment, the computing device 812 is connected to the local area network 851 through a network interface or adapter 853, which is one type of communications device. When used in a WAN-networking environment, the computing device 812 typically includes a modem 854, a type of communications device, or any other type of communications device for establishing communications over the wide area network 852, such as the Internet. The modem

17

DWT 15851872v2 0090765-002WO0 854, which may be internal or external, is connected to the system bus 823 via the serial port interface 846. In a networked environment, program modules depicted relative to the personal computing device 812, or portions thereof, may be stored in the remote computer 849 and/or the remote memory storage device 850. It is appreciated that the network connections shown are exemplary and other means of and

communications devices for establishing a communications link between the computers may be used.

The computing device 812 and related components have been presented herein by way of particular example and also by abstraction in order to facilitate a high-level view of the concepts disclosed. The actual technical design and implementation may vary based on particular implementation while maintaining the overall nature of the concepts disclosed.

Various embodiments of the invention are described above in the Detailed Description. While these descriptions directly describe the above embodiments, it is understood that those skilled in the art may conceive modifications and/or variations to the specific embodiments shown and described herein. Any such modifications or variations that fall within the purview of this description are intended to be included therein as well. Unless specifically noted, it is the intention of the inventors that the words and phrases in the specification and claims be given the ordinary and

accustomed meanings to those of ordinary skill in the applicable art(s). It is, therefore, evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the invention.

DWT 15851872v2 0090765-002WO0