WO2001022330A1 - Medical information system and method to obtain reasoning for therapeutic events - Google Patents

Abstract

An interactive medical information system query process is used to learn the reasons that a medical practitioner initiates a therapeutic event for a patient. The practitioner's reasons are expressed in responses to context specific queries generated by the system. A database maintains an electonically searchable library of drug prescriptions with dose characteristics. The prescription database is used to generate a prescription based upon patient profile characteristics. The system operator selects a generated prescription. The medical information system tracks prescription samples, narrative records, and notes and conducts flash surveys of participating practitioners.

Description

TITLE OF THE INVENTION

MEDICAL INFORMATION SYSTEM AND METHOD TO OBTAIN REASONING

FOR THERAPEUTIC EVENTS

COPYRIGHT NOTICE AND AUTHORIZATION

Portions of the documentation in this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

Conventional medical information systems allow medical practitioners to maintain accurate and detailed electronic records of the treatments of their patients. Virtually every therapeutic event of a patient can be electronically recorded. Insurance companies and government agencies use such information for benefit payment processing and treatment efficacy studies. Companies that sell medical goods and services, such as pharmaceutical companies, often arrange to purchase electronic medical data to assist in sales and marketing efforts. Conventional medical information systems merely create and record therapeutic events. For example, U.S. Patent No. 5,845,255 (Mayaud), U.S. Patent No. 5,737,539 (Edelson et al.), and U.S. Patent No. 5,758,095 (Albaum et al.) describe electronic prescription creation systems that allow prescribers to easily create electronic prescriptions which are stored in a database.

One deficiency with conventional medical information systems is that they do not collect information about the therapeutic event being recorded other than the preprogrammed information that the system expects to receive. Inquiries such as "why is the present therapeutic event being initiated for the patient?" are not part of an automated, structured, input process. Accordingly, companies that mine and analyze medical data records cannot be certain as to why particular therapeutic events have occurred. Paper questionnaires may be sent out to medical practitioners to obtain such "why" type of information. However, this process is time-consuming and costly. Also, it is often difficult to obtain accurate information from patients or medical practitioners after the therapeutic event has occurred, even if the patient or medical practitioner is cooperative in responding to a questionnaire. Although the patient's medical record will be complete, the medical practitioner may not remember exactly what all of the factors were that led to their decision for a particular course of treatment.

Accordingly, there is an unmet need for a medical information system that automatically queries users upon initiation of a therapeutic event for a patient as to why the medical practitioner has initiated the therapeutic event. The practitioner reasoning query process described below meets this need. On-line, automated surveys are an excellent way for companies and organizations to collect information from customers and potential customers. Surveys may be created as an HTML file and placed on the web for respondents to read, reply and submit. Surveys may be sent by e-mail to the e-mail address of selected or targeted persons. The survey may be initiated as an attachment to the e-mail, or may be provided directly in the body of the e-mail message as a plain-text document. The surveys are then automatically returned to a designated e-mail address. Software products such as SurveyTracker, available from Training Technologies, Inc., Mason, Ohio (www.surveytracker.com), allow the user to create and implement such on-line, automated surveys. There are significant disadvantages associated with surveying users or customers via such conventional tools. One disadvantage is that it requires the user to take proactive steps, such as locating and then navigating to a particular web site or e-mail account. Many e- mail account holders do not check their e-mail accounts on a regular or timely basis, and frequently abandon their e-mail accounts. Furthermore, limited demographic information may be available regarding e-mail account holders, thereby making it difficult to provide highly targeted e-mail surveys. Accordingly, there is an unmet need for an automated survey process that can provide regular and timely surveys to a properly targeted audience without requiring the respondent to take proactive steps to reach the survey. The flash survey process described below meets this need.

Electronic prescription systems, such as those described in the patents highlighted above, provide a variety of automated tools to more easily create, distribute and store electronic prescriptions. However, there is still a need for additional functionality in such systems. The present invention provides a plurality of features to add such functionality, including the creation and use of a prescription library of profiled prescriptions, the ability to track the dispensing of prescription samples, and the ability to annotate electronic prescription records with narrative information (i.e., script notes).

BRIEF DESCRIPTION OF THE DRAWINGS The following detailed description of preferred embodiments of the present invention would be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present invention, there are shown in the drawings embodiments which are presently preferred. However, the present invention is not limited to the precise arrangements and instrumentalities shown. In the drawings:

Fig. 1 is a high level schematic block diagram of an interactive querying process in a medical information system in accordance with one preferred embodiment of the present invention; Figs. 2A-2O show query and response sets for each event pathway in Fig. 1;

Figs. 3 A-3F show sample reports that may be generated from the data collected by the process shown in Figs. 1 and Figs. 2A-2O;

Fig. 4 is a database schema for the medical information system that incorporates the present invention; Fig. 5 is a survey database schema for the present invention; Figs. 6 A and 6B, taken together, is a list of tables, and a brief description thereof, in the database of the system in the present invention;

Fig. 7 is an order history table of medication prescriptions, as stored in the medical information system of the present invention; Fig. 8 is a sample screen display for presenting a flash survey to a medical practitioner in accordance with the present invention;

Fig. 9 shows a sample screen display for entering a script note in accordance with the present invention;

Fig. 10 show sample screen displays of how the entered script note is tracked and provided for retrieval and display;

Fig. 11 shows a database schema for the script notes feature of the present invention;

Fig. 12 shows sample screen displays for entering and viewing "sample" information associated with medication orders entered into the system of the present invention.

Fig. 13 shows a database schema for the sample tracking feature of the present invention;

Figs. 14A-14D show sample screen displays that show the prescriber library feature of the present invention; Figs. 15A-15D, taken together, show a sample longitudinal data set created by the present invention; and

Figs. 16A-16D, taken together, show contents of a sample flash survey presented to a medical practitioner in accordance with the present invention.

BRIEF SUMMARY OF THE INVENTION The present invention provides a medical information system that interactively queries an operator of a medical information system to learn the reasons that a medical practitioner initiates a therapeutic event for a patient. The practitioner's reasons are expressed in one or more operator responses to context specific queries generated by the medical information system that explains why the medical practitioner has initiated the therapeutic event for the patient. Another embodiment of the present invention also provides a database system for maintaining a library of drug prescriptions. The system includes a database of prescriptions. Each prescription includes drug and drug dosage characteristics. The system also includes an electronically searchable prescribing profile for each of the prescriptions, wherein each prescribing profile includes a plurality of prescribing characteristics. The database of prescriptions may be used to generate a prescription by inputting into the system one or more characteristics of a prescribing profile for a patient who needs a drug prescription. One or more prescriptions are received from the library of prescriptions that match the inputted characteristics of the prescribing profile. The operator of the system selects one of the prescriptions.

Another embodiment of the present invention also provides the ability to track the dispensing of prescription samples.

Another embodiment of the present invention provides the ability to annotate electronic prescription records with narrative information, thereby making script notes. Another embodiment of the present invention provides the ability to conduct a flash survey of selected medical practitioners who use the medical information system.

DETAILED DESCRIPTION OF THE INVENTION Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention. In the drawings, the same reference letters are employed for designating the same elements throughout the several figures.

The present invention is described in the context of a medical information system software program developed by InfoScriber Corporation, San Diego, California. The software program is called InfoScriber and has an underlying database schema called Prospero™. All examples, patient and prescriber names, and medical cases shown in this application are fictitious and are provided for illustration purposes only.

I. PRACTITIONER REASONING QUERY PROCESS

^' A. OVERVIEW The present invention provides a scheme for collecting questionnaire data from medical practitioners. In this scheme, an operator of a medical information system is interactively queried to learn the reasons that a medical practitioner initiates a therapeutic event for a patient (i.e., why did the medical practitioner initiate a particular therapeutic event?). The medical information system includes a workstation for receiving input information from the operator. The workstation may be a conventional desktop computer, or may be any input device that accepts information from the operator, such as a voice-activated device, touchscreen, or a handheld computer, such as a PALM-type organizer. The practitioner's reasons are expressed in one or more operator responses to context specific queries generated by the medical information system that explains why the medical practitioner has initiated the therapeutic event for the patient. The scheme operates as follows: ( 1 ) The recording of a therapeutic event is initiated via the workstation.

(2) At least one query (i.e., question or inquiry) is provided to the workstation regarding the therapeutic event.

(3) The operator inputs one or more responses to each query via the workstation.

(4) Any inputted responses are stored in association with the corresponding therapeutic event.

The therapeutic event may be the renewal of a drug prescription for the patient, or the ordering of a new drug prescription for the patient. If so, at least one of the queries may request an explanation of any safety considerations that influenced the choice of the drug prescription. The therapeutic event may also be the alteration or discontinuance of an existing drug prescription of the patient. If so, at least one of the queries may solicit information regarding patient side effects encountered from the existing drug prescription. An alteration may be a change in dose, form, frequency, duration, or the like, or may be a switch from one drug to another drug in the same class. A panel of medical practitioners may be formed that provides a statistically representative panel for a particular data collection purpose. Panel member responses may then be tagged so that additional analysis can be performed on the panel member responses. One particular data collection purpose is to obtain query responses that are representative of the entire population of medical practitioners. The operator of the medical information system may be the medical practitioner or an assistant to the medical practitioner. At least one of the queries solicits information regarding patient symptoms. The query and response may both occur at the time of initiation of therapeutic event. Alternatively, the query may occur at the time of the initiation of the therapeutic event, and the response may occur at a later point in time, such as when the medical practitioner has more free time to answer the queries. For example, a nurse may input a medication order into the system (e.g., a telephone order for a prescription) and may request that the system place the queries in a work queue for review by the medical practitioner at a time which is convenient for the medical practitioner.

In one alternative embodiment of the present invention, a panel of medical practitioners is randomly selected from among the medical practitioners who use the medical information system. Furthermore, a group of patients is selected for each of the medical practitioners in the panel. The query process is then performed every time that a medical practitioner in the panel initiates a therapeutic event for any one of the selected group of patients. Alternatively, the group of patients may be selected without regard to which medical practitioner the patient is assigned to. In either scheme, a longitudinal database is created for the selected group of patients from the inputted and stored responses.

The present invention has broad applicability to any area of therapeutics (i.e., the medical treatment of disease). In the examples provided herein, the therapeutic event is the prescribing of medications. Other therapeutic events that are within the scope of the present invention include at least the following events:

(1) an order for a laboratory test (e.g., EKG, MRI, EEG test, opthomology exam)

(2) an order for a medical device

(3) a hospital admission or discharge (4) a request for a consult (e.g., neurological consult for recommendations regarding treatment of patient's epilepsy)

The same database structures and query processes as described herein may be used for these other types of therapeutic events. It is only necessary to change the logic and text of the questions to logic and text that is appropriate for the particular therapeutic event. In the scheme described above, the stored responses become an electronic database of practitioner reasoning associated with therapeutic events, wherein the practitioner reasoning is information explaining why the operator has initiated the therapeutic event for a patient. The electronic database has significant commercial value to medical suppliers and vendors, as well as clinical and economic value for direct users of the system. Medical suppliers may be able to obtain marketing advantages by gaining access to data that help them to understand the prescribing rationale behind decisions to either select a particular medication, or to discontinue one medication in favor of another. They can also use the data to understand why a particular medicine may be used for medical indications other than those for which it was originally approved. Additional analyses of the data can help vendors to segment the population of prescribers into meaningful clusters, and they can test the differential effects of various promotional campaigns on prescriber thinking and on prescriber behavior. Direct end-users of the system benefit by understanding the rationale for use of various combinations of medications, or for use of one set of medications versus another set. Since both cost and clinical outcome can depend upon how these medicines are used, having a system that can ascertain the reasons why medication decisions are made is beneficial in helping to shape clinical and financial policy. For example, if prescribers indicate that they believe that multiple medications in the same medication category either are, or not clinically interchangeable, such information can be used be used to make informed policy decisions regarding formulary availability. To implement the scheme described above, a database system is provided which includes a database of queries related to therapeutic events and a query engine. The queries relate to why the medical practitioner initiates a particular therapeutic event for a patient. The query engine presents one or more queries for response by the medical practitioner upon the initiation of a therapeutic event. The database system further includes a database of query responses which stores the query responses of the medical practitioner in association with the corresponding therapeutic event.

B. PATIENT SAMPLING PROCESS

(i) Overview

The prescription writing component of the system automatically triggers a survey questionnaire based on an inquiry that checks three sets: (1) Survey Members, (2)

Survey Providers, and (3) Survey Drugs. In one preferred embodiment of the present invention, the survey questionnaire is presented only if the prescriber appears in the Survey Providers set, the drug being prescribed appears in the Survey Drugs set, and the prescriber' s patient appears in the Survey Members set. The survey questionnaire will not appear if any of the required data elements do not exist. For instance, if Provider A does not appear in the Survey Providers set, the Provider will never be given the questionnaire (even if he or she prescribes drugs in the Survey Drugs set to members in the Survey Members set).

(ii) Choosing Survey Members

Sample members will be chosen randomly on a facility by facility basis, such that P percentage of the facility's active patients will reside in the Facility Survey Members set at any given time.

N= Count of Active members for a given facility (count of Active Facility Members set m) n = Count of Active members in Facility Survey Members set s P = nlN x = Random number where 0<=J <1

/= Probability factor

Probability factors

For every P such that 0<=P<Λ5,f= .3 For every P such that .15<=P< 25,/= .2

For every P such that .25<= <= 27,/= .1 For every P such that 27<P,/= 0

Upon insert of a Member record, the system will generate random number x. If x is less than or equal to /for any given P, the Member will be added to Facility Member Survey set s and Active Facility Members set m , increasing both n and Nby one. If x is greater than/, the member will be added to Active Facility Members set m (increasing N by one), but will not be added to Facility Member Survey set s.

(iii) System Rules

1. When a new member is added, his or her status is Active. 2. Any member who does not receive a medication order within 90 days will be updated to Inactive status. If that member belonged to set s, n and N will reduce by one. If the member did not belong to set s, N will reduce by one.

3. Any inactive member who receives a medication order will be treated as a new member for sampling purposes (x will be generated and compared to etc.).

4. The system must accommodate facility specific probability factors. This will allow a facility to set/= 1, thus sampling 100% of its members.

(iv) Sample code for Patient Sampling

/* Create a sample in the Rx_SurveyParticipant table in the Survey DB */ declare @n decimal declare @Nd decimal declare @P decimal(18,2) declare @x decimal( 18,10)

select @n = count(Survey..Rx_SurveyParticipant.OriginalID) from Survey.. Rx_SurveyParticipant, Prospero.. Members, inserted where Survey.. Rx_SurveyParticipant.OriginaHD = Prospero.. Members.Member lD and Prospero.. Members.FAC_ID = inserted. fac_id and Survey.Rx_SurveyParticipant.ParticipantTypeID = 1

select @Nd = NullIf(count(distinct(Prosperα..Members.Member_ID)),0) from Prospero.. Members, inserted where Prospero..Members.FAC_ID = inserted.fac_id and Prospero.. Members.Survey_Status = 2

select @P = Survey.. LU_ProbabilityRate.Factor from Members, inserted, Survey.. LU_ProbabilityRate where inserted.FAC_ID = Survey..LU_ProbabilityRate.FAC_ID and (@n/@Nd) Between Rate_Start and Rate_End

select @x = rand()

IF UPDATE(Member_ID) and @x <= @P begin insert into Survey.. Rx_SurveyParticipant (OriginaUD, ParticipantTypelD, Factor) select inserted.Member_ID, 1, Survey.. LU_ProbabilityRate.Factor from Members, inserted, Survey.. LU ProbabilityRate where Members.Member_ID = inserted.Member_ID and inserted.FAC D = Survey.. LU_ProbabilityRate.FAC_ID and inserted. Survey_Status = 2 and (@n/@Nd) Between Rate_Start and Rate_End end

• TABLE 1

PIP OriεinallD ParticipantTvpelD EmailAddress LevellD Create dt Factor

14977 23769 1 NULL 1 2000-08-21 19:25:40.857 .30

15878 117544 1 NULL 1 2000-08-22 04:15:01.607 .20

15949 117639 1 NULL 1 2000-08-23 06: 15:01.607 .30

3794 256 2 NULL 2 2000-08-23 06: 15:01.607

3795 257 2 NULL 2 2000-08-23 06:15:01.607

(iv) Additional details

Other sampling schemes are within the scope of the present invention. Once a patient is selected, the query process is initiated if particular prescription activity occurs for the patient. The user of the system is free to set any desired criteria or rules for initiating the query process. Some examples are as follows: a. patient is being given a new prescription for drugs X, Y or Z. b. patient is having a prescription changed or discontinued for drugs X, Y or Z. c. any activity whatsoever involving drug X is occurring for the patient (useful for a broad analysis of drug prescribing activity)

C. PRACTITIONER SAMPLING METHODOLOGY FOR

CREATING STATISTICALLY REPRESENTATIVE PANEL

The sampling methodology described below is applied to any medical specialty using the medical information system. The methodology for a specific medical specialty (psychiatry) is described below for illustrative purposes. The sampling methodology is based on stratified sampling with proportional quotas within each stratum, and calculation of required sample sizes using a procedure called two-stage cluster sampling. The purpose of this methodology is to target the requisite number of practitioners to be able to make generalizations about the entire national population of prescribers in the specialty from a statistically representative panel of prescribers who will use the system. If this type of methodology is not used, it is not possible to make inferences about the entire national specialty population with a meaningful degree of precision.

1. All 38,686 psychiatrists are rank-ordered on their annual volume of prescriptions for psychiatric medications. Volume data are obtained from a third party vendor. For the purposes of this report, "psychiatric prescriptions" consist of any prescriptions for medications from the following medication categories. a. Antipsychotics b. Antidepressants c. Antianxiety Medications d. Mood Stabilizers e. Alzheimer's Disease Medications

For the purposes of this report, "psychiatrists" are defined to include practitioners from the following categories: a. Child and Adolescent psychiatry b. Addiction psychiatry c. Pediatric/Child psychiatry d. Psychiatry e. Forensic psychiatry f. Geriatric psychiatry g. Psychiatry/Neurology h. Psychoanalysis

2. The number of psychiatrists who account for the top 20% of the volume of prescriptions (20% of 42,712,677) are designated as "quintile 5". Additional quintile cut points are established by going down the list in successive 20% bands. Since these cuts must occur at discrete prescriber intervals (i.e. cut cannot be made in the middle of a prescriber, so to speak), the actual number of prescriptions is very close to, but not exactly at the 20% level for each successive band. Using this method, there are approximately equal numbers of prescriptions in each band. There are unequal numbers of prescribers in each band, with a small number of prescribers accounting for a large volume of prescriptions in the highest band, and the reverse being true in the lowest band.

3. A two-stage cluster sampling formula is applied to these prescriber/prescription numbers, by specifying a 95% confidence level, and solving the equation for sample size. Note that the actual required sample size varies on a report by report basis. However, since it is not feasible to recruit a new physician sample for every report, the strategy is to solve the formula using a set of conservative, assumptions. Key among these conservative assumptions was that there is moderate variability within and between prescribers in prescribing behavior. Also, it is assumed that some of our information problems involve "proportional" rather than "mean" data, the former requiring larger sample sizes. Also to solve the equation, estimates are made about such things as the number of new orders per medical practitioner per month per quintile, and the number of patients per medical practitioner. As actual data is gathered, the formula is re-run, replacing these estimated numbers with empirically-based numbers to calculate the actual confidence intervals for the measures we use.

4. Using estimates of the proportions of public versus private practitioners in the national population, we establish quotas or proportions are established within each quintile. Once the required sample sizes are calculated, the list of names is randomized within each quintile and a process of recruitment of sample representatives is begun from each quintile, maintaining the proportion of private to public practitioners that has been estimated for the national population.

5. Once the required number of practitioners is recruited, each member of the panel begins using the system, and the data are captured in an electronic database for analysis and reporting.

6. An example of the table of calculated sample sizes that is produced using this methodology is shown below in TABLE 2:

TABLE 2

Sample Size Determination for Psychiatric National Sample:

Proportional Measures Version of Two-Stage Cluster Sampling Formula

(95% Confidence Level) and Prescriber Quintiles

Quintile Prescriptions Prescribers Sample Size Required

5 8540229 1311 307

4 8544551 2218 339

3 8542350 3289 358

2 8542700 5298 372

1 8542847 26570 394

Totals 42712677 38686 1770

Once a specific panel is identified, and prescribers (or medical practitioners) are selected for the specific panel, the database schema is updated with this information. In this manner, any prescription orders written by the selected prescribers are tied back to the specific panel, thereby allowing the prescribing activity of the panel to be instantly available for report generation, review and analysis.

Other practitioner sampling methodologies are within the scope of the present invention.

D. GRAPHICAL DESCRIPTION OF PRACTITIONER

REASONING QUERY PROCESS Fig. 1 is a self-explanatory-high level schematic block diagram of an interactive querying process for medication dispensing within a medical information system in accordance with one preferred embodiment of the present invention. Figs. 2A-2O show query and response sets for each event pathway in Fig. 1. Figs.

2A-2E show query and response sets for a new order. Figs. 2F-2H show query and response sets for a change order. Figs. 21-20 show query and response sets for a discontinuation order. The system may be programmed to present any number of query and response sets. The response choices may also dictate if any additional query and response sets are presented, and, if so, which ones. Some event types and response choices may cause only a single query and response set to appear before the query process is terminated. The arrows and stop signs in Figs. 2A-2O show the flow of queries.

When the first query and response set display screen is presented, an option is provided to conduct the query process at a later point in time. For example, a radio button labeled "LATER" may be provided on the initial display screen. If this option is chosen, the medication order is placed in a work queue for invoking the query process at a time which is convenient for the medical practitioner. Otherwise, the query process is performed immediately. Figs. 3A-3F show sample reports that may be generated from the data collected by the process shown in Figs. 1 and Figs. 2A-2O.

Fig. 4 is a database schema for the medical information system that incorporates the present invention.

Fig. 5 is a survey database schema for the present invention. Figs. 6 A and 6B, taken together, is a list of tables, and a brief description thereof, in the database of the system in the present invention.

Fig. 7 is an order history table of medication prescriptions, as stored in the medical information system of the present invention.

E. SAMPLE OF SURVEY DATABASE ANSWER SET In reviewing the example below, there can be many answers for a given question and the answers can have a value (e.g., the code for "Hallucinations"), a severity (e.g., the code for "moderate"), and a code for rank (e.g., this was the most important answer to this question).

Consider a question, "In order of priority, list the symptoms that led you to prescribe this medication?" Potential answers having a value, severity and rank format may be:

Hallucinations - Moderate 1

Aggressive Behavior - Severe 2

Night Tremors - Moderate 3 Rx_SurveyParticipant

Stores all patients and providers available for a survey.

Rx SurveySubject

Stores all Drugs and Diagnoses to be surveyed.

Rx S urveyResult

Stores the Prov_ID and Member_ID for a given survey, one record per survey.

Rx_SurveyResultSubj ect

Stores the subject/medication for a given survey. SubjectID references the Rx SurveySubject table; SubjectTypelD references the Rx_SurveySubjectType table. Also tracks the Rx ID and Event_ID surveyed.

Rx SurveyResultQuestions

Stores questions asked for each survey.

Rx_SurveyResultAnswers

Stores the providers' answers to the survey questions. Keeps a history of answers.

Sample: See TABLE 3 below.

TABLE 3

AUID QUID AnswerlD Value Severity Rank Status

1337 506 1 1 1338 1050 0 100 1339 1051 3 100 1340 1052 10 0 1341 1052 11^' 25 1342 1052 12 50 1343 1052 13 75 1344 506 1 1 1345 1054 2 100 1346 1054 4 100 1347 1055 0 75

AUTD: Primary Key, unique row identifi er QUID: Question ID, Foreign Key to Rx_SurveyResultQuestions Answer ED: Foreign Key to Rx_Survey Answer (lookup table of possible answers to a f given question).

Value: For questions with a rating scale, the value of an answer. For example, if a side effect is rated on a scale of 1-100, then a value of 50, or 75, etc. is stored here.

Severity:

Rank: Order of question to which this answer applies.

Status: "D" flags an answer as a dead item, inactive.

F. LONGITUDINAL DATABASE

The creation of a longitudinal database is an important feature of the present invention. Consider the example of a particular patient X who is under the care of a medical practitioner Y who is enrolled in the system. If the patient has been selected as described above, and is taking a medication Z that is identified as a query spawning medication, then the medical practitioner Y will be queried every time that specific types of activity regarding medication Z occurs for patient X. Ln this manner, a longitudinal database of information is created for the medication. Such prescription lifecycle data, coupled with the query data, is extremely valuable and cannot be quickly or accurately obtained using any currently available longitudinal study techniques.

The longitudinal data may be used to clearly identify drug switching by analyzing dosing levels of a patient's medications over time.

Figs. 15A-15D, taken together, show a sample longitudinal data set created by the present invention. This example shows the medication usage over time for a patient. The field, event_ED, records what became of the order. The meaning of the event_ED number is provided below in TABLE 4.

TABLE 4

Event_ED Event Inactive_Date

2 Active NULL

3 Change NULL

4 Reorder NULL

5 Discontinue NULL 6 Cancel NULL 7 Active NonISC NULL 8 Discontinue NonISC NULL

9 System Titration Discontinue NULL 12 System Discontinue NULL

10 Unused Step NULL

11 Expired Step NULL

II. FLASH SURVEY

A. OVERVIEW

The present invention further provides a scheme for collecting survey data from medical practitioners who interact with a medical information system. The medical information system includes a plurality of workstations for inputting patient medical information as part of a daily workflow process. The workstations are in communication with a central management computer. The scheme operates as follows:

(1) During the daily workflow process, at least one request for survey data for response by the medical practitioner is presented via the workstation.

(2) Any inputted responses from the medical practitioner are stored in the central management computer. The inputted responses may be provided at the time of the request for the survey data. Alternatively, the request for survey data may be presented as an invitation to participate in the survey, and the inputted responses may be provided at a time later than the time of the request for the survey data and outside of the daily workflow process. A "LATER" button as described above may be provided for this purpose. A profile of each medical practitioner is preferably stored in the central management computer and used to selectively query the medical practitioners based upon their stored profiles.

The central management computer compiles the survey data and provides real time analysis thereof. The flash survey is independent of the practitioner reasoning query process. B. TECHNICAL DISCLOSURE

Fig. 8 is a sample screen display for presenting a flash survey to a medical practitioner in accordance with the present invention. Several surveys may be presented at one time. Three surveys are presented in the Fig. 8 example. The medical practitioner has the option to opt out of any given survey. A "NO THANKS" button is provided for that purpose in the Fig. 8 example. A payment may be provided to the medical practitioner as an incentive to complete a survey.

Figs. 16A-16D, taken together, show contents of a sample flash survey presented to a medical practitioner in accordance with the present invention. Virtually any data stored by the system may be used to trigger the presentation of a flash survey. Preferably, demographic and profile data of the medical practitioner are used for this purpose. Therapeutic event data of the practitioner's patients may also be used to select the medical practitioners who are to be surveyed. For example, the survey may select all medical practitioners who have prescribed more than 50 prescriptions for drug X, or all medical practitioners who have prescribed more than 50 prescriptions for drug X, but less than 5 prescriptions for a competitor's drug Y. In this example, the survey may ask prescribing-related questions that are particularly valuable to the research, sales or marketing efforts of a particular company.

An important feature of the flash survey is that it is presented as part of the daily workflow process as the medical practitioners interact with the medical information system. In this manner, the respondent (here, the medical practitioner) does not need to take any proactive steps to reach the survey, such as logging into an e-mail account and then opening an e-mail, as required by conventional e-mail survey schemes described in the background section above. The display screens and reports generated by the flash survey will depend upon the contents of the survey and the types of information that the survey is designed to provide. The survey data is stored by the system in the same manner as the survey data from the practitioner reasoning query process. Thus, the survey data is available for realtime analysis. Conventional techniques for surveying medical practitioners rely on paper and manual processes and have significant lag times between initiation and reporting of results. III. SCRIPT NOTES

A. OVERVIEW

The present invention further provides a scheme for maintaining patient medication orders in a medical information system. The scheme operates as follows: (1) A medication order database is populated with medication orders. Each medication order includes an electronic record of at least one medication that was prescribed for a patient.

(2) At least some of the records are annotated with narrative information regarding the medication order. The narrative information may include observed side effects of the medication, efficacy of the medication, or any patient reaction to the medication in the medication order.

B. TECHNICAL DISCLOSURE

Fig. 9 shows a sample screen display for entering a script note or annotated narrative information, hereafter, refeπed to as a "script note," associated with medication order that is entered into the system of the present invention. The point of entry for a script note may occur at different times and locations in the overall process prescription entry, creation and updating process. The scope of the present invention is not limited to any particular point of entry. Fig. 10 shows sample screen displays of how the entered script note is tracked and provided for retrieval and display. A notepad icon is displayed with the record for prescriptions that have previously created script notes. The full script note appears in a field of a Medications Details screen called "Comments." Script notes may be entered in free form, such as via a keyboard or voice input with speech recognition, or via dropdown menus of preselected narrative.

Fig. 11 shows a database schema for the script notes.

C. ADVANTAGES OF SCRIPT NOTES

In a conventional medical information system, most health care service notes are stored based on the session or visit. See, for example, a "Session Comments" feature shown in Fig. 7 of U.S. Patent No. 6,108,665 (Bair et al.). This works well for billing since most services are paid in terms of the session itself. Documentation to support the billing must still take the form of a session note, also frequently known as a "progress note."

To best service the patient, however, session data is inadequate. Consider the challenge of a prescriber seeing a patient who has been treated with many medications over time. To learn the reasoning behind a specific medication therapy in the past, a prescriber would need to sift through many session-based service notes containing reams of information that are not relevant to the question at hand. In practice, the prescriber will not do this. To some degree, each medication order is an experiment due to the individual variability in both medication efficacy and patient response. A practitioner bases each order on their clinical experience, knowledge of pharmacology and the patient's current and historical condition. When the practitioner has historical information about the patient's condition or response prior to the interventions, the likelihood of success is increased.

The present invention assesses practitioner reasoning and patient response to a therapeutic event thereby creating a database of historical information for a given patient. This historical data is then readily available for future review by the practitioner or for other practitioners who may treat the patient. For example, if a practitioner is considering the use of a specific medication, he or she can review the patient's history with this medication including target symptoms, side effects and compliance. This differs from traditional medical records systems which require review of individual session notes to obtain a history of medication usage.

EV. MEDICATION SAMPLE TRACKING

A. OVERVIEW

The present invention further provides a scheme for tracking samples of prescription medications provided to patients. In the scheme, a medical information system includes a medication order database that is populated with patient medication orders. Each medication order includes an electronic record of at least one medication that was prescribed for a patient. If any portion of the medication order is filled using samples of prescription medications, the electronic record is designated to indicate the dispensing of the samples.

B. TECHNICAL DISCLOSURE

Fig. 12 shows sample screen displays for entering and viewing "sample" information associated with medication orders entered into the system of the present invention. This process allows the prescriber to link the dispensing information to a specific medication order. In the example of Fig. 12, the prescriber elected to give the patient 5 pills (2Vi days worth) from a stock of samples and to fill the remainder of the prescription from the pharmacy. The prescriber may also fill a medication order from medication which they have on hand, but which is not a sample (e.g., local stock). Fig. 13 shows a database schema for the script notes feature of the present invention.

C. ADVANTAGES OF MEDICATION SAMPLE TRACKING Physicians are required by the U.S. Food and Drug Administration (FDA) and accrediting or licensing bodies to keep a log of all dispensed samples. Due to the labor intensive nature of this process, in practice, the samples are not accurately tracked, and sometimes are not tracked at all. Also, since patients can receive samples at separate times against a given order, it is impossible to accurately track dispensed samples in a conventional medical information system and to provide an efficient way to tie the samples to the patient and their specific medication order. The present invention removes the labor component of sample tracking by electronically tracking medication samples dispensed by the medical practitioner as part of the prescription transaction. In addition, the samples can be traced back to a specific patient, practitioner and a specific medication order. By tracking samples on a per order basis, the system also allows prescribers to track their usage over time and to review usage based on the patients that have received the samples.

Consider the example wherein a patient is waiting to learn if their medical insurance, or a manufacturer sponsored Patient Assistance Program, will cover a certain necessary medication. The practitioner may provide a week's worth of samples in order to start the patient on the required therapy. The patient returns a week later because the insurance has not yet replied. More samples are dispensed. This process can continue indefinitely.

The sample tracking feature of the present invention can help both the practitioner and the pharmaceutical manufacturers determine the circumstances under which samples are dispensed. Practitioners can monitor their supply of samples and predict their future requests based on accurate reporting of past usage. Pharmaceutical manufacturers can use the sample tracking data to assess whether their sample programs are effective in generating additional sales by comparing sample dispensing in the context of purchased medications. The pharmaceutical manufacturers can also use the sample tracking data to assess the efficacy of their promotional campaigns.

V. LIBRARY OF PRESCRIPTIONS

A. OVERVIEW

The present invention also provides a database system for maintaining a library of drug prescriptions. The system includes a database of prescriptions, wherein each prescription includes drug and drug dosage characteristics. The system also includes an electronically searchable prescribing profile for each of the prescriptions, wherein each prescribing profile includes a plurality of prescribing characteristics.

The drug dosage characteristics may include drug form, size, route of administration, amount and frequency. The prescribing characteristics may include a patient condition for which the drug is a recommended treatment, and/or patient characteristics for which the drug is a recommended treatment.

The library may be a third-party content library wherein the prescriptions in the database meet the criteria for a predetermined prescribing profile based upon one or more of industry standard protocols, clinical studies, and expert opinions of medical professionals. Other third-party content libraries are within the scope of the present invention.

The library may also constitute a practice library wherein at least some of the prescriptions in the database include prescriptions that were previously dispensed by a preselected group of medical practitioners or by an individual practitioner, and wherein the prescriptions in the database meet the criteria for a predetermined prescribing profile based at least upon the prescribing practices of the preselected group of medical practitioners or the individual practitioner.

The library of drug prescriptions may also be used to electronically prescribe a drug within an electronic prescription system. The system includes a workstation for receiving input data from an operator. The system is in communication with the electronic library of prescriptions. Each of the prescriptions in the library are associated with a predetermined prescribing profile. Each of the prescriptions in the library include drug and drug dosage characteristics. Each prescribing profile includes a plurality of prescribing characteristics. This scheme is implemented as follows: (1) The operator inputs into the system via the workstation one or more characteristics of a prescribing profile for a patient who needs a drug prescription.

(2) One or more prescriptions from the library of prescriptions that match the inputted characteristics of the prescribing profile are received at the workstation.

(3) The operator selects one of the prescriptions in the library. (4) The selected prescription is used to generate a prescription for the patient.

The generated prescription includes the same drug and drug dosage characteristics as the selected prescription in the library.

The number of prescriptions received at the workstation from the library of prescriptions depends upon the niunber of inputted characteristics. The larger the number of inputted characteristics, the less number of matching prescriptions are located in the library of prescriptions.

The system tracks the frequency of selection of each prescription. When the matching prescriptions are received at the workstation, the frequency data is visually communicated with the prescriptions. In one preferred embodiment of the present invention, the matching prescriptions are displayed from the most frequently selected prescription to the least frequently selected prescription, with or without the actual number of previous prescriptions displayed.

B. TECHNICAL DISCLOSURE (i) Overview Prescribing a new medication for a patient constitutes the most time consuming electronic medication order event, and therefore the medical information system of the present invention provides a process that can reduce the time required to complete such an action. From a user interface perspective, this system uses a web search metaphor to locate a medication order in one of several "libraries." In the context of the present invention, a "library" means a set of existing, pre-written, prescriptions that may be searched for and selected by a prescriber. Libraries may be populated using many criteria. For example, a My Practice library may contain all medication orders that the given prescriber wrote using the system; a State Guidelines library may contain a state's dosing recommendations for a given drug.

A user may search for a medicine SIG by choosing the library from which to search, and inputting a Drug name (or partial Drug name), a Diagnosis, or both.

Available libraries are determined by facility, and a prescriber may choose his or her default library. In cases where the search criteria produces a large number of results, the system allows the user to navigate subsets using previous/next buttons, thereby reducing the data traffic between client and server. All results are distinct and sorted by frequency, highest count first. When the user selects an order retrieved by the library search, that order appears on the Rx Pad. The Rx Pad is analogous to a prescriber' s paper notepad traditionally used for medication orders. Users can remove entries from the Rx Pad, and will receive a "remove" confirmation by doing so. After a medication has been added to the Rx Pad, the user may simply assign a diagnosis to the medication and submit it to the pharmacy to be filled.

(ii) Search Examples for My Practice Library a. Drug Name Only

If the user selects a trade name only, the system will return the user's previous prescriptions for that drug name. For example:

(No Count)ZYPREXA TABLETS (Drug Name only will always appear first)

(Count=10)ZYPREXA TABLETS 10mg(l)-BD, 10mg(2)-QHS (Count=8) ZYPREXA TABLETS 10mg(l)-QHS, 5mg(l)-PRN (Count=3) ZYPREXA TABLETS 15mg(l)-HS NOTE: Selecting the first item (Drug Name without dosing and schedule) will allow/require the user to write a custom medication; the user must specify manually the dosage and schedule.

b. Diagnosis Only If the user selects a Diagnosis only, the system will return the user's previous medications prescribed for the selected diagnosis. For example if the user chooses a diagnosis of "Schizophrenia", and the user has prescribed Aspirin, Haldol, and Zyprexa for patients with that diagnosis, the following could be returned:

(No Count)ASPERIN CAPSULES (Trade Name only will appear first) (No Count)HALDOL INJECTION (Trade Name only will appear first)

(No Count)ZYPREXA TABLETS (Trade Name only will appear first)

(Count=15)ZYPREXA TABLETS 10mg(l)-BD, 10mg(2)-QHS

(Count=12)ASPfRTN CAPSULES 200mg(3)-QHS

(Count=12)HALDOL DECANOATE lOOmg/ml, SOLN, TNJ (1.5 cc)-Q4W (Count=l 1)ZYPREXA TABLETS 10mg(l)-QHS, 5mg(l)-PRN

(Count=10)ZYPREXA TABLETS 30mg(l)-HS

NOTE: This result set may include multiple Drug Names. If the user or any other users of the selected library have not prescribed any medications for the selected diagnosis, the set returned will be empty.

c. Drug Name and Diagnosis

If the user selects a Drug Name and a Diagnosis, the system will return the logged in user's Drug/Diagnosis combinations. The results will appear as Trade Name only but will be filtered by the diagnosis selected.

(iii) Library Maintenance, General Description The My Practice, My Group, and InfoScriber Practice libraries will be maintained by a process that checks all records in the Rx table against the rules established for the selected library. If the Rx record passes a given test, it will be inserted into a dedicated libPractice, libGroup, or liblnfoScriber table. This record may then be retrieved from the given library. NOTE: When a user searches for a SIG in a library, the user searches only the dedicated library table. Libraries are updated every 20 minutes.

NOTE: My Practice, Group Practice, and Practice records of all users of the system could be obtained by running a query directly against the Rx table. However, we anticipate this table will likely contain many records (perhaps over 1 Million) if a large number of users are enrolled in the system. The library tables will be much smaller and should therefore expedite the searching and prescription writing process.

(iv) Library Maintenance, Detailed Description

The My Practice, My Group, and InfoScriber Practice Libraries are maintained by dedicated stored procedures, usp_libPractice, usp_libGroup, and usp_libInfoScriber, respectively. These procedures run automatically according to a schedule created by the database administrator. These three procedures function similarly but at different levels: usp libPractice loops through the Rx table based on Prov_ED, usp_libGroup loops based on the Facility lD, and usp_libInfoScriber loops for all non-test facilities.

(v) Detailed explanation of usp libPractice

When executed, usp_libPractice first counts all existing records in the libPractice table, and sets the local variable @kount equal to that number. If no records exist in the table (count = 0), usp libPractice inserts a placeholder record into the table (the placeholder already exists if the count is greater than zero). This placeholder is always the first record in the libPractice table; the max Rx_ED from the previous run appears in the DrugED field and the max libPracticeED from the previous run appears in the Diagnosis field (for the placeholder record only).

Step 1: Loop 1

Get distinct list of prescribers (Prov_Ids) from the Rx table that appeared after the last run of usp_libPractice, and before the current run.

Step 2: Loop 2 (nested within Loop 1)

A: Select distinct SIG/Dx combinations from the Rx and Diagnosis tables, for the current prescriber selected by Loop 1. B: Take the distinct SIG/Dx list gathered in part A, and determine which of those records already exist in the libPractice table. C: Take the repeating records selected by B, and count how many times the given SIG/Dx combination occurred within the given timeframe (between the max record of the last run and the max record of this run); increase the libPractice.kount for the given record by that number. D: Select all first time entries for the given provider. E: Insert all distinct first time entries into libPractice. F: For the newly inserted library records, get corresponding dosage information from Rx_Dosage. G: Insert the dosage information from step F into libPracticeDosage.

Step 3 : . Update placeholder record to new Max(libPracticeΙD)

Step 4: Loop 3 Get all distinct diagnosis group/libPracticeED combinations for the current run.

Step 5: Loop 4 (nested within Loop 3)

Update Group ED in libPractice. If GroupED from selection in Loop 3 is null, update GroupED field in libPractice table to null. Otherwise, update libPractice.GroupED to the GroupED retrieved by Loop 3.

Step 6: Delete any bad records from libPractice (Cleanup).

(vi) Code for usplibPractice with comments See the Appendix.

D. GRAPHICAL DESCRIPTION OF LIBRARY OF PRESCRIPTIONS Figs. 14A-14B show sample screen displays that show examples of the prescriber library feature.

Fig. 14A shows a first example wherein the prescriber' s library has been searched for all medication orders for medications beginning with "Zyp". The results are 37 specific instances that this practitioner has used before. They are sorted in order of frequency of use. In this case, an order has been selected from the results set and added to the prescription pad.

Fig. 14B shows a second example wherein a medical practitioner has searched the library of their own medication orders for all medications beginning with "Zyp" that have been specifically written for the treatment of Schizophrenia spectrum disorders. The results set displays six options in order of frequency of use. In this example, one of the selections has been added to the prescription pad.

Fig. 14C shows a third example wherein the practitioner has searched the library of their own medication orders for all medications beginning with "Zyp" that have been specifically written for the treatment of Bipolar disorders. The results set displays six options in order of frequency of use. Note that the results set differs from the schizophrenia example. In this example, one of the selections has been added to the prescription pad.

Fig. 14D shows a fourth example wherein the Schizophrenia query has been applied to a different library (My Group) resulting in a larger result set.

As discussed above, a profile is designated for at least some of the prescriptions in the library, thereby allowing the practitioner to locate prescriptions that match the needs of the patient. In the examples above, the profile includes at least the patient condition for which the prescription is recommended. The profile may include additional factors such as patient characteristics (e.g., recommended age range and/or weight range for the prescription, stage of illness, gender, allergies). The additional factors may be entered in free form, or via additional dropdown menus, such as the dropdown menu used to enter the diagnosis in Figs. 14A-14D, or stored as part of the patient's electronic records.

In sum, any known prescribing characteristic, such as a patient data point(s), may be matched against the library prescriptions as long as the prescribing characteristic appears in a prescription profile. The profile may also incorporate academic recommendations, national norms, and generally accepted "best practice" guidelines for a set of patient characteristics. In this manner, a medical practitioner will be offered prescription choices that have been sanctioned by industry experts. VI. ADDITIONAL DISCLOSURE

To comply with any privacy policies, patient identification information may be removed from any reports or survey results that are generated by the system, or from any databases that are sold or otherwise provided to third parties. In one preferred embodiment of the present invention, the operator's workstation communicates with the medical information system via an electronic network. More specifically, a browser is used at the workstation to communicate with a web site that hosts the medical information software. The scope of the invention also includes other forms of communication with the software of the medical information system, including other forms of electronic networks, and by directly accessing the software via a workstation containing a preloaded version of the software.

The present invention may be implemented with any combination of hardware and software. If implemented as a computer-implemented apparatus, the present invention is implemented using means for performing all of the steps and functions described above.

The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer useable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the mechanisms of the present invention. The article of manufacture can be included as part of a computer system or sold separately.

It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention. AFPE K

VI Code for uapli-oPracticβ with, comments

CREATE PROCEDURE usp_libPractιce

SET NOCOONT ON DECLARE odrugiD int. βprovtD int. ©diagnosis varchar(20) , ffltradeName varchar(240) , ffldosageCombiiied varchar (255) , ©repeats int , βrxID int,

^frequency varchar (50) , ©dispenaeQty real, θndcCode varchar (11) , ©ray ID int. ©oldHaxRxID int, SnewMaxRxID int . βpracITJ n , ©kouπt int, SsπyPracID int . βgroupIDCat int , ©libPracticelDCat int, ΘgrαupTextCat varchar (255) , aoldPract celDCat int, βmewPracticelDCat int, aroute varchar (SO) , ^strength varchar (252) , βuπits varchar (10)

— STEP L . Count all records m libPractice and set okount to that number SELECT βxσuπt = count ! *) FROM libPractice

STEP 2 If ount « 0, insert a single placexeep ng record

IF efcount BEGIN

SET IDENTITY_INSERT libPractice OH

INSERT INTO libPractice (libPracticelD, drugUJ, tradeName, dosageCombined, kount. diagnosis) VALUES (0. 0, 'DO MOT DELETE THIS ' COUNTS HOW FAR HE WENT THE LAST TIME' , 0 , 0) SET IDENTITY INSERT libPractice OFF

STEP 3 . set βoldHaxRxID - to placeholder from previous run (max r _ιd on previous run) set aneuMaxRxTD to current max Rx_ID in Rx table update placeholder record to new max rx id (stored in the DruglD field) •/

SELECT βoldMaxRxID = {SELECT druglD from libPractice WHERE libPracticelD = 0) —

SELECT θnewMaxRxlD = (SELECT max (RX_^ID) FROM Rx) --

UPDATE libPractice SET druglD •> ©newMaxRxlD WHERE libPracticelD = 0

/•LOOP 1. GET CURRENT PRESCRIBER

Declare pracCuraor, which gets a batch of prσv__ιds (that occur between aid max rx and new max rx) to run through the cursor loop */

DECLARE pracCursor CURSOR FOR

SELECT DISTINCT Prescnbιπg_Dσc FROM Rx WHERE Rx_ID > aoldMaxRxID AND Rx_ED l> SmewMaxRxID

OPES pracCursor

FETCH HE∑T FROM pracCursor

INTO SpracID

WHILE a®FETCH_STATUS = 0 BEGIN

/* LOOP 2A. GET DISTINCT SIG FOR CURRENT PRESCRIBER

Declare tπ Cursor, which selects distinct SIG/Dx combinations from the Rx and Diagnosis tables, for the current provider selected in the pracCursor loop above. It then the two results sets because the dummy DxKeyβ (1-3 ) will never appear in the Diagnosis table. "/

DECLARE myCursor CURSOR FOR

SELECT DISTINCT R.Drug_synonym_Id, D.DxKey, R.Tradename, R.Dosage_^Comb ned FROM Rx R. Diagnosis D WHERE R. Diagnosis ID = D .Rx ID

AND R .Rx_ID > QoldMaxRxID

AND R.Rx_ID ^■ SmewMaxRxID

AND R.Prescrιblng__Dσc * ©prac-CD

AND R.Tradename IS NOT NULL

AND R.Doεage_Corahined IS NOT NULL

AND R. tltrat αnlD IS NULL

AND R.Rx Type IS NULL

AND D.Dxicey IS NOT NULL

UNION

SELECT DISTINCT R.Drug_Syπoπγm_Id, Diagnos s_ID as DxKey, R.Tradename. R.Dosage_Combined

FROM Rx R

WHERE R.Prescrιbιng_Doc = βpraclD

AND Dιagπosιs_ID IN (1, 2 , 3)

AND R.Rx_ID > SoIdMaxRxID

AND R Rx_ID ϊ > SmewMaxRxID

AND R.Tradename IS NOT NULL

AMD R.Dαεage_Combιned IS NOT NULL

AND R.titratϊoαlD IS NULL

AND R.Rx_Type IS NULL OPEN ^•tπyCursor

FETCH NEXT FROM myCursor INTO βdrugld, ©diagnosis, βtradeNatπe, βdosageCαmbined

WHILE ββFETCH STATUS = 0

LOOP 2B. SELECT RECORDS TO INCREMENT

Set ©repeats = to count of distinct dosage combined for dummy diagnoses (1-3) , then run through a similar process to pick up repeated dαsages/Dx from the records where Dx '= 1-3 (real diagnoses) -- remember, th s is still for the provider chosen in the pracCursor loop above (first loop) •/ BEGIN

IF ^diagnosis >=» 1 and ©diagnosis <=• 3 BEGIN

SELECT ©repeats = count (Dosage_Conιbιned) FROM Rx R

WHERE Dosage_Combιned = βdoεageCoπtbined

AND Oιagnαsιs_ID IN (1 , 2, 3)

AND R.Rx_ro > QoldMaxRxID

AND R.Rx_ID '> fflnewMaxRxID

AND R Prescπhιng_Doc =» apracID

AND D agno3 s_lD = ©diagnosis

AND R.Tradename IS NOT NULL

AND R-Dαsage_Combιned IS NOT NULL

AND R.titratϊonID IS NULL

AND R.RxJType IS NULL END ELSE

BEGIN

SELECT βrcpeats = count (Dosage_Combined) FROM Rx R, Diagnosis D

WHERE R.Dιagnαsιs_ID = D.Rx_ID

AND Oosage -ombined =* ©dosageCombined

AND DxKey = ediagnosis

AND R.Rx_ID > βoldMaxRxID

AND R.Rx__ID >> anewMaxRxID

AND R.Prescnbιng_Doc = ΘpracID

AND R.Tradename IS NOT NULL

AND R.Dσsage__Cσmbιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.Rx Type IS NULL

AND D.Dxicey IS NOT NULL

INCREMENT SELECTED RECORDS

Declare my racCursor to select a given instance of drug, dosage combined and diagnosis for a given provider from the libPractice table Then, for repeated drugs for the current provider in the pracCursor loop, increase the count by ©repeats.

-/

DECLARE myPracCursor CURSOR FOR

SELECT libPracticelD FROM libPractice

WHERE dosageCombined = ©dosageCombined AND diagnosis = ©diagnosis AND provID = ®pracΣD

OPEN myPracCursor

FETCH NEXT FROM myPracCursor INTO βmyPracID IF ®βFETCH_STATUS - 0 BEGIN

UPDATE libPractice SET Jtount - kouπt + ©repeats WHERE libPracticelD 3 ΦmyPracID

IF ββFETCH STATUS 0 0

BEGIN

IF ©diagnosis >= 1 and ^diagnosis ■== 3 BEGIN

/_' SELECT NEW RECORDS WHERE 1 <= Dx «= 3

Declare myRxCursor. ∑f the loop in STEP 4C fails (it will fail on all mads prescribed for Dx 1-3, and those med.3 for which no previous dσsage__combιned exists) , run through another loop that accounts for Dx 1-3 */ myRxCursor CURSOR FOR

SELECT Rx__ID FROM Rx

WHERE Dosage_Combmed = ©dosageCombined

AND Dιagnosιs_ID IN (1 , 2, 3)

AND Prescribing_Doc = apracID

AND Dosage_Combιπed IS NOT NULL

AND titrationID IS NULL

AND Rx_ID > ©oldMaxRxID

AND Rx_ID '> ©newMaxRxID

AND Rx Type IS NULL

. SELECT NEW RECORDS WHERE D 0 1,2.3

Declare myRxCursor. Process record through this loop if STEP 2C fails, and the record is not selected in STEP 2D. This loop will run for all new (first time prescribed) records in for which the Dx is not 1-3. */ myRxCursor CURSOR FOR

I Rx_TD FROM Rx R, Diagnosis D WHERE R.Diagnosιs_ID = D.Rx_ID AND Dosage_Combιned - odosageCombinβd AND DxKey = ediagnosis AND Prescπbmg_Doc = apracID AND Dosage_Corabined IS NOT NULL AND R.tltratlOnID IS NULL AND R.Rx_ID > ©oldMaxRxID AND R.Rx_ID !> SmewMaxRxID AND R.Rx Fype IS NULL AND D-Dxkey IS NOT NULL

OPEN myRxCursor

FETCH NEXT FROM rayRxCursor INTO βrxID

CLOSE myRxCursor

DEALLOCATE myRxCursor

INSERT NEW RECORDS INTO libPractice

Insert the first-time records into the libPractice table. NOTE1 noπ- irs -time records w ll simply have their Itount incremented (updated) , no insert will occur */

INSERT INTO libPractice ( drugID, pro ID, tradeName, dosageComb ned, diagnosis, kount) VALUES (

©dragID,

©pracΣD,

©tradeName,

©tradeName +■ ©dosageCombined, θdosageCo bine ,

©diagnosis,

©repeats)

SELECT ΦmylD = ©©IDENTITY

FOR NEWLY INSERTED RECORDS, GET DOSAGE INFO

Declare rayDoseCursor. For each newly inserted record, get the corresponding Rx_IT- Since we only inserted distinct records, we w ll never get more than one Rx_lD during the loop. DECLARE myOoseCursor CURSOR FOR

SELECT Frequency,Dispensed QTY NDC_Code, route. Dosage, units FROM RX_Dosage WHERE Rx_ID =■ ΘrxID

OPEN myDoseCursor

FETCH NEXT FROM myDoseCursor INTO

©frequency,

©dispenseQty,

©ndcCode,

©route,

©strength,

©units

WHILE ©©FETCH STATUS ~ 0

INSERT DOSAGE INFO INTO lihPracticeDosage •/

BEGIN

INSERT INTO libPracticeDσsage ( libPracticelD, frequency, dispenseQty, ndcCode, route, strength, units) VALUES (

©myID,

©frequency,

©dispenseQty,

©ndcCode,

©route,

©strength,

©units)

FETCH NEXT FROM myDoseCursor INTO ©frequency,

©dispenseQty, ©ndcCode, ©route ©strength, ©units

CLOSE myDoseCursor DEALLOCATE myDoseCursor

CLOSE myPracCursor DEALLOCATE myPracCursor

FETCH NEXT FROM myCursor INTO ©drugld, ©diagnosis, ©tradeName, ©dosageComb ned

END

CLOSE myCursor

DEALLOCATE myCursor

FETCH NEXT FROM pracCursor INTO apracID

CLOSE pracCursor DEALLOCATE pracCursor

/* Part one of the libraries has finished, now more housekeeping

A Select the diagnosis entry from the placeholder record, this holds the max libPracticelD from the previous run of this stored procedure B Select the new max of libPracticelD

C Update the diagnosis value of the placeholder record to the new Max libPracticelD */

SELECT ©oldPracticelDCat - diagnosis FROM libPractice WHERE libPracticelD « 0

SELECT ©newPracticelDCat = MAX(libPracticelD) FROM libPractice

UPDATE libPractice SET diagnosis = aπewPracticelDCat WHERE libPracticelD = 0

/* LOOP 3 GET DISTINCT GROUP/libPractlcelD COMBOS gCursor ^""

This loop will grab all distinct diagnosis group (Dave Mailing ' s Dx groups) /libPracticelD combos.

DECLARE gCursor CURSOR FOR

SELECT DISTINCT c groupID, . libPracticelD

FROM lu_diagnosιsCαdes 1 , libPractice m, diagnosisCategoπes c

WHERE l .dxKey = m. diagnosis

AND C - code = l. code

AND libPracticelD > ©oldPrac ice DCat

AND libPracticelD t ©newPracticelDCat

OPEN gCursor

FETCH NEXT FROM gCursor INTO

©groupIDCat ,

©libPracticelDCat

WHILE ®βFETCH_STATUS =» 0 BEGIN

/* LOOP 3A UPDATE GroupID IN libPractice

If GroupID from selection in LOOP 3 is null, update GroupID field in libPractice table to null. Otherwise, update libPractice. GroupID to the GroupID retrieved by LOOP 3.

DECLARE gpCursor CURSOR FOR

SELECT groupID FROM libPractice

WHERE libPracticelD =» ©libPracticelDCat

OPEN gpCursor

FETCH NEXT FROM gpCursor INTO ©groupTextCat

IF ©groupTextCat IS NULL BEGIN

UPDATE libPractice

SET groupID = ' , ^■ +■ CONVERT (VARCHAR, ©groupIDCat) +^■ ' , '

WHERE libPracticelD = ©libPracticelDCat

UPDATE libPractice

SET groupID = groupID +■ ' , ' + CONVERT (VARCHAR, ©groupIDCat) WHERE libPracticelD = ©libPracticelDCat

CLOSE gpCursor DEALLOCATE gpCursor

FETCH NEXT FROM gCursor INTO ©groupIDCat , ©libPracticelDCat

CLOSE gCursor DEALLOCATE gCursor

- - Housekeeping--Delete any bad records from libPractice DELETE FROM libPractice WHERE diagnosis IS NULL

Sample code for u-Sp_libGroup

CREATE PROCEDURE uεp_lιbGrσup AS

SET NOCOUNT ON

DECLARE

©drugID mt,

©provID mt,

©diagnosis varchar(20),

©tradeName varchar(2 0) ,

©dosageCombined varchar(2S5) ,

©repeats in , θrxLD int,

©frequency varchar(50),

©dispenseQty real,

©ndcCode varchar(50),

©m ID int,

©fac D mt,

©oldMaxRxID int. θπewMaxRxID mt,

©groupID int.

©kount mt,

©groupIDCat int,

©libGroupIDCat int,

©groupTextCat varchar(255) , βoldGroupIDCat int.

©newGroupIDCat int,

©route varchar(SO) ,

©strength varctιar(255) ,

©units varchar(lθ)

SELECT ©kount - count(*) FROM libGroup

IF ©kount - 0 BEGIN

SET IDENTrTY_INSERT libGroup ON

INSERT INTO libGroup (libGroupID, druglD, tradeName, dosageCombined, facID, Jcount, diagnosis) VALUES (0,0, 'DO NOT DELETE THIS LINE' , *COUNTS HOW FAR WE WENT THE LAST TIME' , 0 , 0, 0)

SET IDENTITY_INSERT libGroup OFF END ~

SELECT ©OldMaxRxID = (SELECT druglD from libGroup WHERE libGroupID = 0)

SELECT βnewMaxRxID = (SELECT roax(Rx_ID) FROM Rx)

UPDATE libGroup SET druglD » ©newMaxRxID WHERE libGroupID - 0

SELECT ©oldGroupIDCat » diagnosis FROM libGroup WHERE libGroupID = 0

SELECT ©newGroupIDCat = ©newMaxRxID

UPDATE libGroup SET diagnosis - ©newGroupIDCat WHERE libGroupID = 0

myCursor CURSOR FOR

SELECT DISTINCT R.Drug_Synonyra_Id, D.DxKey, R.Tradename, R.Dosage__Corabιned FROM Rx R, Diagnosis D

WHERE R.Facιlιty_ID = ΦfacID

AND R.Diagnosis_ID = D.RX_ΣD

AND R.Rx_H) > ©oldMaxRxID

AND R.Rx_DD '> ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dosage_Corobιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.Rx_Type IS NULL FETCH NEXT FROM myCursor INTO edrugld, ©diagnosis, ©tradeName, ©dosageCombined

WHILE e©FETCH_STATUS - 0 BEGIN

IF ©diagnosis >= 1 and ©diagnosis <=> 3 BEGIN

SELECT ©repeats =» count (Dosage_Combιned) Rx R

WHERE R.Dosage_Coτnbιned = ©dosageCombined

AND Dιagnosιs_ID IN (1 , 2, 3)

AND R.Rx_ID > ©oldMaxRxID

AND R Rx_ΣD '> ©newMaxRxID R.Facιlιty_iD a ©facID

AND R.Dιagnαsιs_ID _* ©diagnosis

AND R Tradename IS NOT NULL

AND R.Dosage_Combιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.Rx Type IS NULL END ~

ELSE BEGIN

SELECT ©repeats = count (Doεage_Combιned) FROM Rx R, Diagnosis D

WHERE R.Dosage_Combιned » ©dosageCombined

AND R.HX_ID > ©oldMaxRxID

AND R.Rx_ID • =- ©newMaxRxID

AND D.DxKey = ©diagnosis

AND R.Facιllty_ID - βfacTD

AND D.RX_ID = R.Dιagnosιs_ID

AND R.Tradename IS NOT NOLL

AND R.Dosage_^Combined IS NOT NULL

AND R.titrationlD IS NULL

AND R.Rx_Type IS NULL

AND D-DXkey IS NOT NOLL END

DECLARE libGroupCurεor CURSOR FOR

SELECT libGroupID FROM libGroup

WHERE dosageCombined = ©dosageCombined diagnosis = ©diagnosis AND facID » ©facID

OPEN libGroupCursor

FETOI NEXT FROM libGroupCursor INTO ©GroupID

IF ©βFETCH_STATUS - 0 BEGIN

UPDATE libGroup SET kount = kount + ©repeats WHERE libGroupID = ©GroupID END

IF ®βFETCH_STATUS <> 0

BEGIN ^~~

IF ©diagnosis >=> 1 and ©diagnosis <= 3 BEGIN

DECLARE myRxCursor CURSOR FOR

SELECT Rx_ID FROM Rx

WHERE Dιagnosi3_ID IN (1 , 2, 3)

AND Dosage_Combιned =» ©dosageCombined

AND Dιagnosιs_ID =» ©diagnosis

AND Facilltγ_ID = ©facID

AND Rx_ID > ©oldMaxRxID

AND Rx_ID '> ©newMaxRxID

AND Tradename IS NOT NULL

AND Dosage_Cαmbιned IS NOT NULL

AND titrationID IS NULL

AND BxType IS NULL END ELSE BEGIN

DECLARE myRxCursor CURSOR FOR

SELECT R .Rx_ID FROM Rx R, Diagnosis D

WHERE R.Dιagnosιs_ID = D.Rx_ID

AND Dosage_Combιned = ©dosageCombined

AND DxKey = ©diagnosis

AND R Facιlιty_ID = ©facID

AND R.Rx_ID > ©OldMaxRxID

AND R Rx_ID ^■ > ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R Dosage_Combιned IS NOT NULL

AND R. titrationlD IS NULL

AND R.RxJType IS NULL AND D Dxkey IS NOT NULL END

OPEN myRxCursor

FETCH NEXT FROM myRxCursor INTO ©rxID

CLOSE myRxCursor

DEALLOCATE myRxCursor

INSERT INTO libGroup ( druglD, t adeName, dosageCombined, diagnosis, kount, facID) VALUES (

©drugID,

©tradeName,

©tradeName +■ ©dosageCombined,

©dosageCombined,

©diagnosis,

©repeats,

©facID) SELECT ©mylD = ©©IDENTITY

DECLARE myDoseCursor CURSOR FOR

SELECT Frequency, Dιspensed_QTY, NDC_Code. route. Dosage, units FROM RX_Dσsage WHERE ftx_ID =»

OPEN myDoseCursor

FETCH NEXT FROM myDoseCursor INTO

©frequency,

©dispenseQ y,

©ndcCode,

©route ,

©strength,

©units

WHILE ©βFETCH_STATTΪS = 0 BEGIN

INSERT INTO libGroupDosage ( libGroupID, frequency, dispenseQty, ndcCode, route, strength, units) VALUES (

©myID,

©frequency , βdispenseQty ,

©ndcCode ,

©route ,

©strength,

©units)

FETCH NEXT FROM myDoseCursor INTO Θfrequency, ©dispenseQty , ©ndcCode , sroute , ©strength, ©units

CLOSE myDoseCursor DEALLOCATE myDoseCursor END

CLOSE libGroupCursor DEALLOCATE libGroupCursor

FETCH NEXT FROM myCursor INTO ©drugld, ©diagnosis , ©tradeName , ©dosageComb med

END

CLOSE myCursor DEALLOCATE myCursor

FETCH NEXT FROM facCursor INTO ©facID END

CLOSE facCursor

DEALLOCATE facCursor

DECLARE gCursor CURSOR FOR

SELECT DISTINCT c groupID, m. libGroupID

FROM lu_dιagnαsι≤CQdes 1 , libGroup m. diagnoεisCategories c

WHERE 1 dxKeγ =■ m. diagnosis

AND c code - l .cσde

AND libGroupID > ©oldGrσupIDCat

AND libGroupID • > ©newGroupIDCat

OPEN gCursor

FETCH NEXT FROM gCursor INTO

©groupIDCat ,

QlibGroupIDCat

WHILE ©©FETCH STATUS = 0 BEGIN

DECLARE gpCursor CURSOR FOR

SELECT groupID FROM libGroup

WHERE libGroupID = ©libGroupIDCat

OPEN gpCursor

FETCH NEXT FROM gpCursor INTO ©groupTextCat

IF ©groupTextCat IS NULL BEGIN

UPDATE libGroup

SET groupID ^ ' , ' -t- CONVERT (VARCHAR, ©groupIDCat) ^■*- ^■ . '

WHERE libGroupID = ©libGroupIDCat END ELSE BEGIN

UPDATE libGroup

SET groupID a groupID + ' , ' * CONVERT (VARCHAR, ©groupIDCat)

WHERE libGroupID =■ ©libGroupIDCat END

CLOSE gpCursor DEALLOCATE gpCursor

FETCH NEXT FROM gCursor INTO agroup IDCat. ©1 ibGrou IDCa gCursor DEALLOCATE gCursor

DELETE FROM libGroup WHERE diagnosis IS NULL

VIII Sample Code for U3p_libInfoScriber

CREATE PROCEDURE usρ_lι InfoScriber

SET NOCOUNT ON

DECLARE

©drugID int.

©provlD int,

©diagnosis varchar(20) ,

©tradeName varcha (240) ,

©dosageCombined varcha (255) ,

©repeats int.

©rxID mt,

©frequency varchar(50) ,

©dispenseQty real,

©ndcCode varchar(11) ,

©myID int.

©OldMaxRxID int ,

©newMaxRxID int .

©

oldl ib InfoScriber IDCat int ,

©newlibln oScriber IDCat int ,

©strength varchar (50) ,

©route varchar(255) ,

©units varcha (10 )

SELECT ©kount = cαunt (*) FROM liblnfoScriber

IF ©kount - 0 BEGIN

SET tDENTITY_INSERT LiblnfoScriber ON

INSERT INTO liblnfoScriber (liblnf oScriherlD, druglD, tradeName, dosageCombined, kount , diagnosis) VALUES (0, 0. 'DO NOT DELETE THIS LINE' , 'COUNTS HOW FAR WE WENT THE LAST TIME' 0 , 0)

SET IDENTITY_INSERT liblnfoScriber OFF END

SELECT ©oldMaxRxID = (SELECT druglD from liblnfoScriber WHERE lib In oScriber ID = 0)

SELECT ©newMaxRxID = (SELECT max(Rx_ID) FROM Rx)

UPDATE liblnfoScriber SET druglD = ©newMaxRxID WHERE liblnfoScriberlD - 0

SELECT ©oldl ib InfoScriberlDCat = diagnosis FROM liblnfoScriber WHERE liblnfoScribarlD - 0

SELECT ©ne lib InfoScriberlDCat = ©newMaxRxID

UPDATE liblnfoScriber SET diagnosis = ©nβwliblnfoScnber IDCat WHERE liblnf oScriber ID = 0

DECLARE σtyCursor CURSOR FOR

SELECT DISTINCT R.Drug_Synonym_Id, D DxKey, Tradename, Dosage_Cαmbined FROM Rx R, Diagnosis D

WHERE R.Dιagnosιs_ID = D.Rx_lD

AND R.Rx_ID > ©OldMaxRxID

AND R.Rx_ID '» ©newMaxRxID

AND R Tradename IS HOT NULL

AND R.Dαsage_Combιned IS NOT NULL

AND R.titrationlD IS NULL

AND R-Rx rype IS NULL

AND D.Dxkey IS NOT NULL UNION SELECT DISTINCT .Drug_Synσπyra_Id, Dιagnosιs_ID as DxKey, R.Tradename, R.Dosage_Combιned FROM Rx R

WHERE Diagnosis_ID IN ( 1, 2, 3)

AND R.RX_ID > ©OldMaxRxID

AND R.Rx_TD 1> ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dθ3age_Combιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.Rx Type IS NULL

OPEN myCursor

FETCH NEXT FROM myCursor INTO

©drugld,

©diagnosi ,

©tradeName .

©dosageCombined

WHILE ®©FETCH_STATUS = 0 BEGIN

IF ©diagnosis = 1 and ©diagnosis <= 3 BEGIN

SELECT ©repeats - count (Dosage_Comhιned) FROM Rx R WHERE Dosage_Cαmbmed a ©dosageCombined AND Dιagnosιs_ID IN (1 , 2 , 3 ) AND Diagnosιs ID = ©diagnosis AND R-Rx ID > ©oldMaxRxID AND R.Rx_TD '> QnewMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dosage_Cθtπbιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.RX Type IS NULL END ELSE

BEGIN

SELECT ©repeats = count (Dosage__Combιπed) FROM Rx R, Diagnosis D

WHERE R.Dιagnosιs_ID = D.Rκ_ID

AND Dσεage_Combιned 3 ©dosageCombined

AND DxKey => ©diagnosis

AND R.Rx_ID > ©OldMaxRxID

AND R.Rx^ID ^■> ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dθ3age_Cαmbιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.RxJType IS NULL

AND D.Dxkey IS NOT NULL END

DECLARE mylnfoCursor CURSOR FOR

SELECT liblnfoScnberlD FROM liblnfoScriber

WHERE dosageCombined - ©dosageCombined AND diagnosis β ©diagnosis

OPEN myln oCursor

FETCH NEXT FROM mylnfoCursor INTO βinfoID

IF β©FETCH_STATUS - 0 BEGIN

UPDATE liblnfoScriber SET kount => kount +■ ©repeats WHERE liblnfoScnberlD = sinfolD END

IF ββFETCH_STATUS <> 0 BEGIN

IF ©diagnosis >= 1 and ©diagnosis « 3 BEGIN

DECLARE myRxCursor CURSOR FOR

SELECT R.Rx_ID FROM Rx R

WHERE Dαsage_Combιned = ©doαageCo bined

AND Dιagnosιs_IJ IN (1 , 2 , 3)

AND R.RX_ID .-^"©OldMaxRxID

AND R Rx_IO '> ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dosage_Combιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.RxJType IS NULL END ~

ELSE BEGIN

DECLARE myRxCursor CURSOR FOR

SELECT R,Rx_ID FROM Rx R, Diagnosis D

WHERE R.DiagnosiB_ID =» D .Rx_ID

AND Dosage_Cαmbιned = ©dosageCombined

AND DxKey «■ ©Diagnosis

AND R.RX_ID > ©oldMaxRxID

AND R.Rx_ID !> ©newMaxRxID

AND R.Tradename IS NOT NULL

AND R.Dosage_Combιned IS NOT NULL

AND R.titrationlD IS NULL

AND R.RxJType IS NULL

AND D.Dxkey IS NOT NULL

OPEN myRxCursor

FETCH NEXT FROM myRxCursor INTO ©rxID

CLOSE myRxCursor

DEALLOCATE myRxCursor

IF ©druglD is not null BEGIN

INSERT INTO liblnfoScriber ( drug ID, tradeName, dosageCombined , diagnosis , kount) VALUES (

©drug ID, ©tradeName,

©tradeName +^■ ©dosageCombined, ©dosageCombined ,

©diagnosis , ©repeats)

SELECT © ylD = ©©IDENTITY

DECLARE myDoseCursor CURSOR FOR

SELECT Frequency,DιapenBed_QTY, NDC_Code, route. Dosage, units FROM RX Dosage

OPEN myDoseCursor

FETCH NEXT FROM myDoseCursor INTO

©frequency,

©dispenseQty.

©ndcCode,

©route,

©strength,

©units

WHILE ©8FETCR_STATUS = 0 BEGIN

INSERT INTO liblnfoScriberDosage ( libln oScriberlD, frequency, dispenseQty, ndcCode, route, strength, units) VALUES (

©myID,

©frequency,

©dispenseQty ,

©ndcCode,

©route,

©strength,

©units)

FETCH NEXT FROM myDoseCursor INTO ©frequency, ©dispenseQty, ©ndcCode, ©route, ©strength, ©units

CLOSE myDoseCursor DEALLOCATE myDoseCursor

CLOSE mylnfoCursor DEALLOCATE mylnfoCursor

FETCH NEXT FROM myCursor INTO ©drug Id, ©diagnosis , ©tradeName , ©dosageCombined

END

CLOSE myCursor

DEALLOCATE myCursor gCursor CURSOR FOR

SELECT DISTINCT c groupID, m. liblnf oScriberlD

FROM lu_dιagnosιsCαdes 1, liblnfoScriber m, diagnosiεCategories <

WHERE 1 dxKey = m. diagnosis

AND c code = 1 code

AND liblnfoScnberlD > ©oldliblnfoScriberlDCat

AND liblnfoScriber ID ' > ©newliblnf oScriberlDCat

OPEN gCursor

FETCH NEXT FROM gCursor INTO

©groupIDCat,

© 1 ib Inf oScriber IDCat

WHILE S©FETCH_STATUS = 0 BEGIN

DECLARE gpCursor CURSOR FOR

SELECT groupID FROM liblnfoScriber WHERE liblnfoScnberlD = fflliblnfoScnberlDCat

OPEN gpCursor

FETCH NEXT FROM gpCursor INTO ©groupTextCat

IF ©groupTextCat IS NULL

BEGIN

UPDATE liblnfoScriber

SET groupID = ^■,' + CONVERT(VARCHAR-©groupIUCat) + WHERE libInfoScriberID - θliblnfoScriberlDCat

END

ELSE

BEGIN

UPDATE liblnfoScriber

SET groupID _* groupID + • , ' + CONVERT(VARCHAR.©groupIDCat) WHERE liblnfoScriberID = ΘliblnfoScriberlDCat

CLOSE gpCursor DEALLOCATE gpCursor

FETCH NEXT FROM gCursor INTO ©groupIDCat, ©liblnfoScriberlDcat

CLOSE gCursor DEALLOCATE gCursor

DELETE FROM liblnfoScriber WHERE diagnosis IS NULL

Claims

What is claimed is:CLAIMS

1. A computer-implemented method of interactively querying an operator of a medical information system to learn the reasons that a medical practitioner initiates a therapeutic event for a patient, the system including a workstation for receiving input information from the operator, the practitioner's reasons being expressed in one or more operator responses to context specific queries generated by the medical information system that explains why the medical practitioner has initiated the therapeutic event for the patient, the method comprising:

(a) initiating the recording of a therapeutic event via the workstation;

(b) providing at least one query to the workstation regarding the therapeutic event;

(c) the operator inputting one or more responses to each query via the workstation; and

(d) storing any inputted responses in association with the corresponding therapeutic event.

2. The method of claim 1 wherein the therapeutic event is the ordering of a drug prescription for the patient.

3. The method of claim 2 wherein the therapeutic event is the ordering of a new drug prescription for the patient.

4. The method of claim 3 wherein at least one of the queries requests an explanation of any safety considerations that influenced the choice of the drug prescription.

5. The method of claim 1 further comprising:

(e) forming a panel of medical practitioners that provides a statistically representative panel for a particular data collection purpose, wherein step (d) further includes tagging any panel member responses so that additional analysis can be performed on the panel member responses.

6. The method of claim 5 wherein the particular data collection purpose is to obtain query responses that are representative of the entire population of medical practitioners.

7. The method of claim 1 wherein the therapeutic event is the alteration or discontinuance of an existing drug prescription of the patient.

8. The method of claim 7 wherein at least one of the queries solicits information regarding patient side effects encountered from the existing drug prescription.

9. The method of claim 1 wherein the operator is the medical practitioner.

10. The method of claim 1 wherein at least one of the queries solicits information regarding patient symptoms.

11. The method of claim 1 further comprising:

(e) randomly selecting a panel of medical practitioners from among the medical practitioners who use the medical information system;

(f) selecting a group of patients for each of the medical practitioners in the panel;

(g) performing steps (b)-(d) every time that a medical practitioner in the panel initiates a therapeutic event for any one of the selected group of patients; and

(h) creating a longitudinal database for the selected group of patients from the inputted responses that are stored in step (d).

12. The method of claim 1 wherein step (b) occurs upon the initiation of a therapeutic event, and step (c) is performed at the same time as presentation of the query.

13. A method of creating an electronic database of medical practitioner reasoning associated with therapeutic events, the practitioner reasoning being information explaining why the operator has initiated the therapeutic event for a patient, the method comprising: (a) providing at least one query to a workstation upon initiation of a therapeutic event, the query requesting an input of information regarding practitioner reasoning for the therapeutic event; and

(b) storing in the electronic database any inputted responses in association with the corresponding therapeutic event.

14. The method of claim 13 wherein the therapeutic event is the ordering of a drug prescription for the patient.

15. The method of claim 14 wherein the therapeutic event is the ordering of a new drug prescription for the patient.

16. The method of claim 15 wherein at least one of the queries requests an explanation of any safety considerations that influenced the choice of the drug prescription.

17. The method of claim 13 wherein the therapeutic event is the alteration or discontinuance of an existing drug prescription of the patient.

18. The method of claim 17 wherein at least one of the queries solicits information regarding patient side effects encountered from the existing drug prescription.

19. The method of claim 13 further comprising:

(c) forming a panel of medical practitioners that provides a statistically representative panel for a particular data collection purpose, wherein step (b) further includes tagging any panel member responses so that additional analysis can be performed on the panel member responses.

20. The method of claim 19 wherein the particular data collection purpose is to obtain query responses that are representative of the entire population of medical practitioners.

21. The method of claim 13 wherein at least one of the queries solicits information regarding patient symptoms.

22. The method of claim 13 further comprising:

(c) randomly selecting a panel of medical practitioners from among the medical practitioners who use the medical information system;

(d) selecting a group of patients for each of the medical practitioners in the panel;

(e) performing steps (a) and (b) every time that a medical practitioner in the panel initiates a therapeutic event for any one of the selected group of patients; and

(f) creating a longitudinal database for the selected group of patients from the inputted responses that are stored in step (b).

23. The method of claim 13 wherein step (b) occurs upon the initiation of a therapeutic event, and step (c) is performed at the same time as presentation of the query.

24. A computer-implemented database system for querying a medical practitioner, the database system comprising:

(a) a database of queries related to therapeutic events, the queries relating to why the medical practitioner initiates a particular therapeutic event for a patient; and

(b) a query engine that presents one or more queries for response by the medical practitioner upon the initiation of a therapeutic event.

25. The system of claim 24 wherein the therapeutic event is the ordering of a drug prescription for the patient.

26. The method of claim 25 wherein the therapeutic event is the ordering of a new drug prescription for the patient.

27. The system of claim 24 wherein the therapeutic event is the alteration or discontinuance of an existing drug prescription of the patient.

28. The system of claim 27 wherein at least one of the queries solicits information regarding patient side effects encountered from the existing drug prescription.

29. The system according to claim 24 further comprising: (c) a database of query responses which stores the query responses of the medical practitioner in association with the corresponding therapeutic event.

30. A method of creating an electronic database of medical practitioner reasoning associated with therapeutic events, the practitioner reasoning being information explaining why the operator has initiated the therapeutic event for a patient, the method comprising:

(a) providing at least one query to a workstation upon initiation of a therapeutic event, the query requesting an input of information regarding practitioner reasoning for the therapeutic event; and

(b) storing in the electronic database any inputted responses in association with the corresponding therapeutic event;

(c) selecting a group of patients for whom data has been entered into the electronic database;

(d) performing steps (a) and (b) every time that a medical practitioner initiates a therapeutic event for any one of the selected group of patients; and

(e) creating a longitudinal database for the selected group of patients from the inputted responses that are stored in step (b).

31. The method of claim 30 wherein the therapeutic event is the ordering of a drug prescription for the patient.

32. A computer-implemented method of electronically prescribing a drug using an electronic prescription system, the system including a workstation for receiving input data from an operator, the system being in communication with an electronic library of prescriptions, each of the prescriptions in the library being associated with a predetermined prescribing profile, each of the prescriptions in the library including drug and drug dosage characteristics, each prescribing profile including a plurality of prescribing characteristics, the method comprising:

(a) the operator inputting into the system via the workstation one or more characteristics of a prescribing profile for a patient who needs a drug prescription; (b) receiving at the workstation one or more prescriptions from the library of prescriptions that match the inputted characteristics of the prescribing profile;

(c) the operator selecting one of the prescriptions in the library; and

(d) using the selected prescription to generate a prescription for the patient, the generated prescription including the same drug and drug dosage characteristics as the selected prescription in the library.

33. The method of claim 32 wherein the library of prescriptions is a third-party managed library of prescriptions.

34. The method of claim 33 wherein the third-party managed library of prescriptions is a database of prescriptions that meet dosing guidelines for a predetermined prescribing profile based upon one or more of (i) industry standard protocols, (ii) clinical studies, and (iii) expert opinions of medical professionals.

35. The method of claim 32 wherein the system tracks the frequency of selection of each prescription, and step (b) further includes visually communicating the frequency data with the prescriptions.

36. The method of claim 35 wherein the frequency data is visually communicated by ordering the display of prescriptions from the most frequently selected prescription to the least frequently selected prescription.

37. The method of claim 32 wherein the drug dosage characteristics include at least one of drug form, size, route of administration, amount and frequency.

38. The method of claim 32 wherein the prescribing characteristics include the patient condition.

39. The method of claim 32 wherein the prescribing characteristics include patient characteristics.

40. The method of claim 32 wherein the library of prescriptions include prescriptions that were previously dispensed by a preselected group of medical practitioners.

41. The method of claim 32 wherein in step (c), the number of prescriptions received at the workstation from the library of prescriptions depends upon the number of inputted characteristics, wherein the larger the number of inputted characteristics, the less number of matching prescriptions are located in the library of prescriptions.

42. A computer- implemented database system for maintaining a library of drug prescriptions, the system including:

(a) a database of prescriptions, each prescription including drug and drug dosage characteristics; and

(b) an electronically searchable prescribing profile for each of the prescriptions, each prescribing profile including a plurality of prescribing characteristics.

43. The system of claim 42 wherein the drug dosage characteristics include at least one of drug form, size, route of administration, amount and frequency.

44. The system of claim 42 wherein the prescribing characteristics include a patient condition for which the drug is a recommended treatment.

45. The system of claim 42 wherein the prescribing characteristics include patient characteristics for which the drug is a recommended treatment.

46. The system of claim 42 wherein the prescriptions in the database meet the criteria for a predetermined prescribing profile based upon one or more of (i) industry standard protocols, (ii) clinical studies, and (iii) expert opinions of medical professionals.

47. The system of claim 42 wherein the library of drug prescriptions includes prescriptions that were previously dispensed by a preselected group of medical practitioners, and wherein the prescriptions in the database meet the criteria for a predetermined prescribing profile based at least upon the prescribing practices of the preselected group of medical practitioners.

48. A method of collecting survey data from medical practitioners who interact with a medical information system, the medical information system including a plurality of workstations for inputting patient medical information as part of a daily workflow process, the workstations being in communication with a central management computer, the method comprising:

(a) during the daily workflow process, presenting via the workstation at least one request for survey data for response by the medical practitioner; and

(b) storing any inputted responses from the medical practitioner in the central management computer.

49. The method of claim 48 wherein the inputted responses are provided at the time of the request for the survey data.

50. The method of claim 48 wherein the request for survey data is an invitation to participate in the survey, and the inputted responses are provided at a time later than the time of the request for the survey data and outside of the daily workflow process.

51. The method of claim 48 wherein a profile of each medical practitioner is stored in the central management computer, and step (a) further comprises selectively querying the medical practitioners based upon their stored profiles.

52. The method of claim 48 further comprising:

(c) the management computer compiling the survey data and providing real time analysis thereof.

53. A computer-implemented method of maintaining patient medication orders in a medical information system, the method comprising:

(a) populating a medication order database with medication orders, each medication order including an electronic record of at least one medication that was prescribed for a patient; and

(b) annotating at least some of the records with narrative information regarding the medication order.

54. The method of claim 53 wherein the narrative information includes at least one of (i) observed side effects of the medication, (ii) efficacy of the medication, and (iii) patient reaction to the medication in the medication order.

55. A computer-implemented method of maintaining patient medication orders in a medical information system, the method comprising:

(a) populating a medication order database with medication orders, each medication order including an electronic record of at least one medication that was prescribed for a patient; and

(b) if any portion of the medication order is filled using samples of prescription medications, designating in the electronic record the dispensing of the samples.