EXECUTIVE  MANAGEMENT      •      MARKET STRATEGY      •       VENTURE CAPITAL      •       CORPORATE DEVELOPMENT

 

Prescription management system

 

A wirelessly deployable, electronic prescription creation system for physician use captures into a prescription a patient condition-objective of the prescribed treatment and provides for patient record assembly from source elements, with privacy controls for patient and doctor, adverse indication review and online access to comprehensive drug information including scientific literature. Extensions to novel multi-drug packages and dispensing devices, and an "intelligent network" remote data retrieval architecture as well as onscreen physician-to-pharmacy and physician-to-physician e-mail are also provided.

Primary Examiner: McElheny, Jr.; Donald E.
Attorney, Agent or Firm: Handal & Morofsky
 

This application is a Continuation of application Ser. No. 08/330,745, filed Oct. 28,1994, now abandoned.

I claim:

1. A computer-implemented prescription creation system having a program stored on a computer-readable medium, the system being for use by a prescriber to create an electronic prescription prescribing a drug to treat a condition exhibited by a patient at a point-of-care, said electronic prescription comprising a patient identifier, at least one prescribed drug and at least one drug quantifier for the prescribed drug and being usable by a pharmacist to dispense the prescribed drug or drugs, said prescription creation system comprising:

a) a prescription creation screen having prescriber-operable data capture devices including:

i) a patient identifier data capture device for capturing patient-identifying data;

ii) a prescribed drug data capture device for capturing prescribed drug identification data;

iii) at least one drug quantifier capture device for capturing drug quantification data;

iv) a patient condition data capture device to capture patient condition data regarding said patient condition exhibited by said patient whereby said electronic prescription further comprises said patient condition data; and

b) a library of prescribable drug data accessible by one or more of said data capture devices from said prescription management screen to display multiple prescribable drugs;

c) a prescription output screen device to output a completed prescription; and

d) a printer to print the completed prescription;

wherein the completed prescription includes the patient condition and identification and quantification data regarding a drug prescribed by the prescriber user for treatment of the patient condition, the patient condition and drug data being captured into the prescription by the data capture devices.

2. A prescription creation system according to claim 1 having at least one preferred usage data display including a personal-preference drug-selection list for each system user wherein the system tracks preferred data usage by each system user and updates said preferred usage data displays automatically.

3. A prescription creation system according to claim 2 wherein at least one said preferred usage data display comprises a personal-preference condition-selection list for each system user accessible from the prescription creation system during prescription creation.

4. A prescription creation system according to claim 1 further comprising a patient history record for display, said patient history record listing electronically available prior prescription data including a prescribed drug and a condition treatment objective for each prescribed drug.

5. A prescription creation system according to claim 4 comprising a patient condition list for selection of a patient condition for posting to said prescription, said patient condition list comprising patient conditions listed in said patient history record.

6. A prescription creation system according to claim 1 comprising a source-oriented data-retrieval subsystem, said data retrieval subsystem being connectable to access at least one data-retrieval network to retrieve source prescribing information and patient-related data to the point-of-care from at least one remote source database.

7. A prescription creation system according to claim 6 wherein said patient-related data comprises allergy or drug interaction information regarding the patient or comprises patient drug formulary changes.

8. A prescription creation system according to claim 4 wherein said patient history record is a contemporaneous record dynamically assembled from multiple source record elements retrieved from multiple heterogenous remote databases.

9. A prescription creation system according to claim 8 implemented on a user interface device configured for networked digital communication with a host computer facility, wherein said patient history record is retrieved in the form of complementary record elements from multiple remote databases by said host computer facility.

10. A prescription creation system according to claim 1 wherein said drugs in said drug list are classified into groups according to patient conditions for which said drugs have efficacy and said prescription creation system further comprises a patient-condition specification procedure for selecting said condition from groups of possible conditions and an onscreen drug selection procedure for selecting said prescribed drug from said library.

11. A prescription creation system according to claim 1 wherein said patient has a drugs benefit provider, said drugs benefit provider issuing a prescription benefit plan including a drug formulary for said patient listing at least one drug preferred by said drugs benefit provider for treatment of said condition, and wherein the system further comprises:

a drug formulary display device identifying at least one of said displayed multiple drugs as a patient's drug formulary preference for treatment of said condition, to enable selection by said prescriber of a benefit plan recommended drug;

whereby the patient's drug formulary preference for treatment of said condition is system-presented to the prescriber prior to completion of the prescription and wherein said patient drug formulary data comprises a condition-driven formulary drug list, and a condition-driven nonformulary drug list, said drug lists being changeable according to the patient selected to identify drugs in the selected patient's drug formulary.

12. A prescription creation system according to claim 1 including means to access remote source databases containing said drug formulary information and provided by the selected patient's prescription benefits management company whereby relevant patient formulary drugs are indicated to said user on screen.

13. A prescription creation system according to claim 1 including information regarding prescribability of a drug pursuant to formulary guidelines, said information being formulary-qualified according to said patient condition.

14. A prescription creation system according to claim 13 comprising a user data access auditor to log information as to the time, date and identity of third party access to said user history data, to provide a user data access audit trail.

15. A prescription creation system according to claim 1 comprising a prescription expiration routine including dosing, amount and expiration drug quantifiers and comprising system calculation of a relationship between said drug quantifiers.

16. A prescription creation system according to claim 1 comprising organization-generated source data retrievable for display in said prescription-creation system from at least one remote database, an organization-directed data-access control subsystem including data-access control specification means enabling an organization to authorize selective third party access to said organization-generated source data and comprising data access control means whereby only an authorized third party can access said organization-generated source data.

17. A prescription creation system according to claim 1 wherein said condition list comprises at least five conditions, and said drug list comprises at least five drugs.

18. A prescription creation system according to claim 1 wherein said drug information comprises associated condition information and dosage information for at least about fifty percent of all prescribable FDA-approved drugs.

19. A prescription creation system according to claim 1 comprising output means to output a newly created electronic prescription additionally to local storage to remote storage or to remote file transfer as an electronic prescription, the system providing all said output options.

20. A prescription creation system according to claim 1 comprising means for transmitting said electronic prescription across a network for fulfillment by a specified pharmacy.

21. A prescription creation system according to claim 19 comprising a printed dosage schedule output for said patient.

22. A prescription creation system according to claim 1 wherein said patient has a drugs benefit provider, said drugs benefit provider issuing a prescription benefit plan including a drug formulary for said patient listing at least one drug preferred by said drugs benefit provider for treatment of said condition, and wherein the system further comprises:

d) a drug formulary display device identifying at least one of said displayed multiple drugs as a patient's drug formulary preference for treatment of said condition, to enable selection by said prescriber of a benefit plan recommended drug;

whereby the patient's drug formulary preference for treatment of said condition is system-presented to the prescriber prior to completion of the prescription.

23. A method of treating a patient condition wherein a prescriber creates an electronic prescription prescribing a drug to treat a condition exhibited by a patient at a point-of-care, said patient having a drugs benefit provider, said drugs benefit provider issuing a prescription benefit plan including a drug formulary for said patient listing at least one drug preferred by said drugs benefit provider for treatment of said condition, said electronic prescription comprising a patient identifier, at least one prescribed drug and at least one drug quantifier for the prescribed drug and being usable by a pharmacist to dispense the prescribed drug or drugs, wherein the method is implemented by a computer system and comprises operating prescription creation software encoded in a computer-readable medium to perform the steps of:

a) capturing into the prescription, in a prescription creation screen, under prescriber control:

i) patient identifier data;

ii) prescribed drug data;

iii) at least one drug quantifier; and

iv) patient condition data regarding said patient condition exhibited by said patient whereby said electronic prescription further comprises said patient condition data;

b) before completion of the prescription, automatically displaying multiple prescribable drugs from a library of prescribable drug data accessible by one or more of said data capture devices from said prescription management screen, at least one of said displayed multiple drugs being identified as a patient's drug formulary preference for treatment of said condition, to facilitate selection by said prescriber of a benefit plan recommended drug, whereby the patient's drug formulary preference for treatment of said condition is system-presented to the prescriber prior to completion of the prescription;

c) fulfilling the prescription at a pharmacy; and

d) administering the prescribed drug to the patient.

24. A method according to claim 23 comprising accessing drug formulary information from multiple drug formulary providers, selecting said drug formulary list from said multiple available drug formularies according to said patient identification and presenting said drug formulary list information dynamically to said prescriber-user in the form of at least one selection of patient-specific formularies.

25. A prescription creation method according to claim 24 comprising updating and maintaining said multiple available formularies from remote source databases of formulary information via network data communication means.

26. A method according to claim 23, comprising categorizing and displaying said patient conditions in multiple lists, said lists being selected from the group consisting of a personal condition list of conditions encountered by the prescriber, a historical condition list of conditions exhibited by the patient, one or more prescriber-customized condition lists, a body system condition list and condition lists organized according to disease pathology, therapy or personal prescribing knowledge.

27. A prescription creation method according to claim 26 wherein drug selection is condition driven and said prescriber selects a patient condition to be treated via at least one of said condition lists.

28. A method according to claim 27 wherein a prescriber-user can intelligently access a large body of drug data selections via multiple condition-driven routes to provide multiple mapping to one or more appropriate drugs for treating the patient's exhibited condition, via different pathways, according to the user's preferred work methods.

29. A method according to claim 23 comprising selecting and capturing dosage and route of administration information, length-of-treatment and generic substitution authorization information, for a selected drug, said information being system-available for all system-listed drugs, and making said selected and captured information available to the user in the prescription creation screen.

30. A prescription creation method according to claim 29 comprising updating and maintaining said dosage information from a remote source database via network data communication, and dynamically supplying said dosage information from said remote source database when called by the system.

31. A method according to claim 23 comprising evaluating a newly prescribed drug against a patient's history record of currently active prior prescriptions for system-known patient allergies or drug-to-drug interactions, or drug-to-multiple drug interactions and for absolute contraindications with currently prescribed drugs, as known to the system.

32. A prescription creation method according to claim 23 comprising communicating with other users of said system via onscreen electronic mail enabling a prescriber-user to append an electronic record to a prescription or prescription-related record.

33. A method according to claim 23 comprising retrieving drug-related information across a network from a remote source database and displaying retrieved drug information to said user in real time.

34. A prescription creation system according to claim 23 operated by each of multiple non-cooperating prescribers accessed by a patient each prescriber having common online access to the patient's prescription history record whereby that record provides a current record of new prescriptions.

TECHNICAL FIELD

This invention relates to professional data management systems useful in the production of product specification documents such as prescriptions, service or parts orders, insurance contracts and the like that require detailed product and history information from multiple extensive information sources, especially remote heterogenous sources. More particularly, the invention relates to systems that assist professionals perform their everyday work in specifying customized technical products. A particularly preferred embodiment relates to a computer-implemented prescription management system to assist physicians in prescribing and reviewing drugs.

BACKGROUND

An important professional activity undertaken by most physicians during the course of their day is the prescribing of drugs. Many physicians prescribe a great number of drugs every day. Studies show that over two thirds of all doctor-patient encounters were completed with the writing of a prescription. In 1993 typical prescribers were prescribing in excess of two hundred thousand dollars-worth of drugs annually. While most physicians exercise the utmost of professional skill and caution in prescribing, there are inherent difficulties and uncertainties in the process. Most physicians will probably agree that they do not have access to adequate, reliable drug information and relevant patient information at the time and point of prescription. In particular, information regarding relevant new drugs, comparative efficacy, and importantly, relative costs, may not be readily and conveniently available to a physician creating a new prescription, as well as relevant patient information such as current conditions being treated, current treatments, and preferred medications for conditions, pursuant to requirements of the patient's drug formulary.

Nevertheless, while accessing it is impractical for the typical practitioner, such information is available to any physician willing to take the time and make the effort to obtain it.

In contrast, integrated patient-specific information which is directly relevant to treatment management for the subject patient is frequently both unavailable to, and unobtainable by, a prescribing physician unless that physician's institution or organization has been exhaustively responsible for the subject patient's prior care and maintains sophisticated computerized records. Information as to allergies, current prescriptions and currently active conditions is clearly desirable or essential for intelligent prescribing. In 1994, few prescribing sessions are conducted with the benefits of integrated patient-specific information and fewer still have the benefit of specific drug formulary recommendations on the subject patient.

As used herein, the term "drug formulary" refers to a list of preferred drugs contained in a drug benefits plan issued by a drugs benefit provider to a given patient. Drug formularies are specific to groups of patients and vary in content as between one drug benefit provider and another and one patient group and another. Drug formulary information is usually determinative of the cost-effectiveness of a prescription. Unwitting failure by a prescriber to follow formulary guidelines can impose unnecessary or unexpected cost burdens on the patient, or their benefits provider, and lead to poor patient compliance and aggravating and time-consuming disputes. The cost in dollars of non-compliance with drug formulary guidelines to benefit-providing corporations, insurers, health maintenance organizations and government providers, for example MEDICAID and MEDICARE, can be enormous. The cost of poor patient compliance may ultimately increase the total cost of care by generating a more serious, expensive adverse health outcome (emergency room visit, or hospital admission or death).

A difficulty in making integrated patient-specific information readily available to prescribing professionals is that the needed information components are not centralized but are widely distributed geographically and even when their geographic or electronic locations are known, are hard to access because of proprietary and liability and patient-confidentiality concerns and because of system, file or protocol incompatibilities.

Even in the computer-abundant United States, in the mid-90's, prescription writing is generally a manual process. After consulting with a patient to determine their problems and diagnosing, or attempting to diagnose their condition or disease, a physician selects a drug and a dosage and an amount to prescribe based upon their own personal knowledge and experience, if necessary using available reference materials which may or may not include promotional materials from drug manufacturers. A prescription is then written up under the physician's signature and bears a patient identification, a drug name, dosage amount and timing, refillability information and the physician's signature, the date, possibly an advisory regarding contraindications, and little other information. While a prescription may be typed, keyed or otherwise "generated" on a computer most prescriptions are still manually written.

Prescribing activity should be a good field for computerization, but one difficulty is the lack of apparent benefits to many physicians. Paper prescription pads are small and easily carried around by a physician. Manually writing a prescription will often be quicker and easier than using a computer, however good the system. The benefits of automated information systems often come not from greater data entry efficiency, but from the increased efficiency of the entire process, from the value of the transaction records generated and also from the control of the transaction entry process which may ensue. Physicians who are not computer-literate or who are even "computer-phobic" will require a most compelling reason to adopt a computerized prescription management system.

To be fully effective, a prescription management system must be readily usable by a wide range of physicians, preferably for all their prescribing activity must provide compelling value to patient care and increase overall treatment management efficiency. Providing an attractive computer-based system to physicians is fraught with unexpected difficulties.

Physicians and other health care professionals, especially those with prescribing authority, are representative of certain groups of professionals whose unique characteristics raise obstacles to the computerization of their day-to-day professional activities. Desirably, a computerized professional management system should be capable of flexible integration into their personalized and varied work flows.

Contrary to many perceptions and assumptions in conventional data-management systems intended for use by physicians, clinical physicians are not deskbound workers and do not usually have continuous access to a personal desktop computer during the course of their normal daily routine. To the contrary most physicians are ambulatory or even highly mobile, moving from room to room, from office to office, from hospital to hospital and to and from their car and home. While some physicians may spend the majority of their health care patient encounter activities at or near a desktop in their own office, such physicians are probably the exception. In clinics and hospitals physicians are often continually on the move between examination rooms, reception areas, administrative centers, hospital wards, specialist facilities such as radiology rooms and so on and so forth. In addition many physicians have more than one practice or more than one professional activity which takes them between an office or clinic and a hospital or other facility on a regular basis. Accordingly, it is a significant technical challenge to provide such mobile physicians with access to a computer-implemented management system that is readily available at the point of care.

Portable computers are a possible solution to the access problem now that powerful and compact notebook computers are widely available. Although currently available portable computers offer some advantages particularly to physicians moving between one work place and another, they also suffer certain drawbacks. One drawback is that external communication is difficult being commonly effected by moving diskettes, a valuable but limited method, or by modem connection to a telephone line which inconveniently requires plugging into a wall jack. Though possibly adequate for a physician having multiple offices, neither the communication means nor the portability of such systems is satisfactory for a ward physician moving from patient bed to patient bed. The weights and form factors of traditional portable computers are severe impediments to their assimilation into many clinical physicians' daily lives as dependable assistants to their professional work.

More recently, small handheld or palm computers known as personal digital assistants or personal information communicators have become available. An example is the Apple NEWTON (trademark). As of summer 1994, these are rather rudimentary devices as compared with desktop or full-powered portable systems, having modest permanent and RAM storage capacities and limited processing and communications abilities. Attractive to busy mobile professionals for their small size, such handheld computers can also embody highly desirable radio wave or infrared wireless communications abilities enabling them to exchange data with host systems without the cost or inconvenience of hard wiring. Such portable hand held radio communicating computing devices are attractive for computerizing mobile professionals such as physicians, but their processing and storage limitations represent a real problem in providing a sophisticated, capable and attractive system for physicians.

A broad objective of this invention is to provide a prescription management system that can be used by physicians on such mobile computing devices.

Simply delivering a system on a convenient portable computer will not be enough to assure its regular use by a majority of physicians. Though highly educated and technically skilled, many physicians are not computer literate and are averse to confronting a computer screen. Some may even be intimidated by computers. Nor do their busy schedules permit time to learn complex or difficult systems. Even for an experienced user adoption of computer use into their daily routines requires time change and adaptation. With tremendous competition for their time, physicians will only be willing to take these steps if they are enticed by powerful system features that provides them with compelling value to patient care and overall practice management efficiency.

Nevertheless, the greatest of system features will be worthless if the system hinders the professional in executing routine functions. Even at sophisticated computer products companies with access to, and experience with, state-of-the-art systems, telephone sales staff often take down orders with pen and pad rather than using an on-line sales order systems.

An experienced professional practicing their specialty for example a pediatrician treating infants knows from experience exactly what to prescribe, in many instances. They will have neither the time nor the patience to work their way through conventional software selection and data entry procedures. Accordingly, a further object of this invention is to provide a prescription management system which personalizes itself to the prescribing patterns of experienced users.

SUMMARY OF THE INVENTION

This invention solves a problem. It solves the problem of providing a computerized, prescription management system that an average prescribing physician can use and will want to use and which makes possible significant improvements in the quality of prescriptions written. In preferred embodiments, the invention also solves the problem of significantly reducing prescription costs to patients and to their drugs benefit management company or government agency. The invention solves these problems for physicians by providing a prescription management system for electronic prescription creation by a prescriber at a point of patient care, said prescription being usable by a pharmacist to dispense drugs, said prescription management system comprising:

a) electronic posting means to select and capture in said prescription:

i) a patient identifier;

ii) a prescribed drug;

iii) a dosage for said prescribed drug; and

b) a patient-condition treatment specification procedure;

whereby in creating said prescription said prescriber specifies a patient condition for treatment by said prescribed drug.

More generally, the invention provides a computer-based professional product specification system for use by other professionals, in addition to physicians, and which can deliver substantial benefits to mobile users.

By associating a patient condition or problem with each drug prescribed, a treatment objective is both expressed and recorded, and the physician's intent is captured. The invention provides a user-friendly prescription management system, which requires minimal data entry enabling many prescriptions to be created with an overall efficiency unobtainable by known automated systems, and which can helpfully supplement the skills of the best of practitioners.

Pursuant to one preferred embodiment of the invention, the drugs in the drug list are classified according to a patient condition for which the drugs are effective and the onscreen drug selection procedure lists multiple drugs for treating each patient problem. In an alternative embodiment, the user makes a drug selection by generic or brand name or some other drug identifier, and the system supplies, suggests or requires, entry of an appropriate treatment condition so that the patient record is completed with the condition or conditions for which the selected drug is prescribed.

The invention also provides a user-adaptive prescription management system for electronic prescription creation by a prescriber at a point of patient care, said prescription being usable by a pharmacist to dispense drugs, said prescription management system comprising:

a) electronic posting means to select and capture in said prescription:

i) a patient identifier;

ii) a prescribed drug;

iii) a dosage for said prescribed drug;

b) a patient-condition treatment specification procedure whereby in creating said prescription said prescriber specifies a patient condition for treatment by said prescribed drug;

c) an onscreen drug selection procedure having a patient condition list specifying multiple possible patient conditions, having a drug list specifying multiple possible prescribable drugs and having drug specification means to select and post a desired drug to said prescription; and

d) tracking means to track preferred data usage by a user and to adapt data displays to favor such preferred usage, whereby the system learns and adapts to a user's habits;

wherein drugs in said drug list are classified according to a patient condition for which said drugs have efficacy and said onscreen drug selection procedure lists multiple drugs for treating each said patient problem.

Drug lists or individual drug selections or suggestions may be presented to prescriber-users in any of a variety of ways for example by frequency of prescription for a selected condition, based upon either the user's historical prescription activity or a wider base of historical prescribing activity, which could be nationally or regionally defined or derived from a drugs benefit house, health maintenance organization, hospital or other appropriate institution.

System suggestions for condition-related drug selection may be further refined into categories such as relative cost, generic or brand name and so on. Where many drugs are available for treating a patient's active condition, one particularly useful presentation is by multiple lines of therapeutic preference according to drug formulary guidelines. Thus, within the patient's particular formulary there may be suggested first, second and third lines of therapy. Different suggestions may be made for different patients according to the preferences of the patient's particular drugs benefit management company.

Preferably the system includes a comprehensive database of approved drugs classified by conditions for which they are known to have therapeutic effect and this database need not be maintained in the users station but should be accessible in real time to the user. Many valuable professional benefits are obtained by delivering a selective listing of drugs by condition to a physician. For example in treating a particular chronic condition such as gastro-intestinal disease, a physician may find that common medicaments such as antacids are ineffective, that a particular brand name drug such as TAGAMET (trademark) has, with prolonged use, undesired side effects so that the physician may at this point be interested in gaining information about alternative drugs with which they are less familiar. If the physician does not have the information at their finger tips, this could be a time consuming process in their office reviewing files and other archival information systems they have. Alternatively on-line electronic services may be used but this can also be a time consuming process. By offering a comprehensive selection of drugs known to be effective for a particular condition, this problem is easily solved for the physician. The preferred embodiments include back-up prescribing information on each drug, along with details of literature references supporting its manufacturer's therapeutic claims or with means enabling the physician promptly to obtain such references.

The invention is not limited to providing a prescription management system. It can provide, in the medical field alone, systems for clinical laboratory management, for medical record management for radiology management and the like. In addition the invention can provide novel professional data management systems that can create new products and yield comparable benefits in other professional spheres where professionals are responsible for specifying more or less complex technical products to solve client or customer problems.

In this wider aspect the invention provides a professional product specification system for electronically creating a technical specification usable by a professional to specify technical products said product specification system comprising:

a) electronic posting means to select and capture in said technical specification:

i) a customer identifier;

ii) a specified product; and

b) an onscreen product selection procedure having a product benefit list specifying multiple possible customer benefits having a product list specifying multiple possible specifiable products and having product specification means to select and post a desired product to said specification;

wherein products in said product list are classified according to a customer benefit which said products can provide and said onscreen product selection procedure lists multiple products for providing each said customer benefit.

BRIEF DESCRIPTION OF THE DRAWINGS

By way of example, some preferred embodiments of the invention are described in detail below with reference to the accompanying drawings in which:

FIG. 1 shows a system entry screen of a prescription management system embodiment of the invention which system incorporates the screens of FIGS. 2-11;

FIG. 2 is a patient selection screen;

FIG. 3 shows a prescription creation screen;

FIG. 4 is a condition list selection screen;

FIG. 5 is a condition selection screen;

FIG. 6 is a drug selection screen, condition specified;

FIG. 7 is a nonformulary drug selection screen;

FIG. 8 is an alternative condition-specification and drug selection screen;

FIG. 9 is an alternative direct drug specification screen;

FIG. 10 is a condition selection screen, drug specified;

FIG. 11 is a drug selection evaluation screen;

FIG. 12 is a single prescription history screen.

FIG. 13 is a patient problem history information screen; and

FIG. 14 is a manually updatable problem list maintenance screen;

FIG. 15 illustrates a scheduled dosage drug package;

FIG. 16 is a schematic diagram of one way of connecting users of the prescription management system of FIGS. 1-14 with remote source databases across network to provide data and processing resources needed during operation of the prescription management system and useful inter alia for creation of a virtual patient record;

FIG. 17 is a schematic block flow diagram showing a sequence of operating steps of the prescription creation system shown in FIGS. 1-11;

FIG. 18 is a diagram similar to the diagram of FIG. 17, showing a condition driven drug selection procedure;

FIG. 19 is a diagram similar to the diagram of FIG. 17, showing a drug selection evaluation procedure;

FIG. 20 is a diagram similar to the diagram of FIG. 17, showing a direct drug selection procedure; and

FIG. 21 is a diagram similar to the diagram of FIG. 17, showing a drug and condition list updating procedure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Overview

The prescription management system illustrated in FIGS. 1-14 can be provided in software for single-user operation on a stand-alone personal computer for use, for example, by a sole practitioner or for multi-user operation on a local area network for use, for example, by physicians and other prescribers within a single facility, hospital, group practice, or the like prescribing organization, and the invention can bring substantial benefits to such users and their patients.

However, more significant benefits can accrue to patients, physicians, drug benefit providers and the public at large by implementation of the described prescription management system on a regional or nation-wide basis. To this end, a preferred embodiment of prescription management system comprises a host computer facility supporting wired or wireless network delivery of user-relevant components of said prescription management system to multiple remote user interface devices.

The host computer facility provides data, or access to data, data processing and communications resources for users to draw upon via the user interface devices. The host computer facility can be a server or cluster of servers with associated data storage volumes, and a t least one intelligent client providing access to the server or servers. As will be explained in more detail hereinafter, especially with reference to FIG. 16, the host computer facility can call upon a variety of external resources and functions as a marshalling and processing center for organizing resources into useful and manageable pieces for utilization by limited capacity user-interface devices. In a preferred embodiment it is a co-ordination point on a network for a number of user-device clients. Preferably the network accesses or includes a number of remote database sources providing useful information elements to the system.

Referring to FIGS. 1 to 14 of the drawings, the screens shown employ user-friendly data selection and data entry devices for capturing data such as are familiar to many computer users in Apple Corporation's Macintosh.RTM. (trademark) and Microsoft Corporation's Windows operating systems, for example activatable buttons, pointers, scroll bars, icons, arrow key, drop-down menus, windows and other screen symbols designed for actuation by a pointing device, for example, a mouse or trackball. More preferably, for compact "pocketbook" computer applications, the pointing device is a pen or stylus.

The prescription management system shown in this embodiment of the invention has been designed for implementation on physically compact, portable, user-interface devices such as small portable personal computers, especially hand held devices known as personal digital assistants. Those skilled in the art will understand that the system can readily be used on or adapted to other hardware platforms, for example, a physician's desktop computer and can be expressed in different software interfaces from that shown, especially ones that use different input devices such as keyboards, touch pads or touch screens and the like.

Pursuant to certain user-adaptive aspects of this invention, the screens automatically personalize themselves, with use, to adopt the patterns and habits of a regular user of a particular device platform for the system, offering the user their most frequently used information, drugs, conditions, patients or patient groups, and so on as first line choices. This adaptive characteristic is a valuable benefit endearing the system to experienced users who may become impatient with hierarchically accessed data.

Ease of use and suitability of the system to keyless or minimally keyed platforms, especially PDA's is promoted by minimizing the need for actual text or data entry by the user and by emphasizing instead data selection from extensive, preferably comprehensive, data lists. Preferred embodiments of the invention allow quick pen selection of data items through columnar pick lists.

The data lists, categories, groups, addresses or routes, can be organized in multiple hierarchies for rapid and flexible access to multiple large, remote databases, via multiple access routes to retrieve multiple related data elements and assemble them into a single data file, for example, a patient history file compiled from the data resources of a patient's historical health providers.

A desirable goal is to provide the physician-user with intelligent data lists that are, where possible, exhaustive and list, for example, all prescribable drugs, all conditions, all formularies or all patients and present the physician with helpful first-line choices or defaults selected intelligently on the basis of historical data known to the system. Preferably, the selection means is fully system embodied, or automatic, operating transparently to the user and requiring a minimum of configurational or setup operations by the user.

Virtual Patient Record

An ability to compile what may be termed a "virtual" patient record from multiple remote databases of primary source information is a valuable novel feature of preferred aspects of this invention. Such a virtual patient record can be created in a chronologically current version by online interrogation of all possible primary sources of electronically recorded patient history elements, by retrieving those elements and assembling them into a complete record. Yet the record need neither be drawn from, nor committed to, permanent storage, obviating storage requirements for accumulations of patient records.

The record can be assembled dynamically, on an as-needed basis, consulted by an authorized system user, and then dissolved, without ever having been saved, giving the record a virtual character.

Record element retrieval and record assembly are conducted under the auspices of the host computer facility employing a novel patient data directory service providing routing information to each patient's record elements. For each patient, the patient data directory service lists all institutions, including independent physicians, hospitals, HMO's, insurance companies, and so on, known to have source historical records on that patient, against a unique patient identifier, such as described hereinbelow. Also listed are routing or address data enabling the host facility to access institutional databases to retrieve record elements. Access protocols detailing, for example, what data can be accessed, when it may be accessed, by whom or by what organization or department it may be accessed, can be kept in a patient-specified directory, or elsewhere.

Patients not listed in the directory service can be searched at the remote source databases and, optionally, at other, host computer facilities supporting the inventive system for other groups of users.

The complete, assembled patient history, or record, need never be stored, unless the patient requests or consents to such storage, and it serves some useful administrative or care-related function. Storage or archiving of a record that is potentially updatable from multiple uncoordinated locations has the drawback of dating it. To become current, the record must be refreshed from any database containing a new data element for that patient.

By using a dynamically assembled virtual record, and never storing it, potential problems of maintaining patient confidentiality and preventing unauthorized access to highly sensitive personal information can be mitigated or avoided. This aspect of the invention avoids proliferation of a patient's confidential history and permits primary source data proprietors to act as exclusive wardens of their individual confidential data elements.

Bio-pattern recognition

Bio-pattern recognition of personal user characteristics including, for example, handwriting, signatures, voice patterns and fingerprints is an attractive medium for accepting user inputs, but in the present state of development of the technology, suffers drawbacks which disfavor use of bio-pattern recognition in preferred embodiments of the invention. Future developments such as greater processing capabilities in small user-interface devices, and more accurate and efficient bio-pattern recognition techniques may change this picture and favor adoption of one or more forms of bio-pattern recognition.

Thus, handwriting recognition, is eschewed in preferred embodiments of the invention, at the present time, because writing is more tiresome to the user than pointing, pressing or clicking and adds complexity and processing overhead to the system. Additionally, handwriting recognition, although presently available in pioneer systems, adds uncertainties, may require significant user effort or adaptation and may threaten data accuracy or promote user error.

Signature recognition may be desirable, if permitted by regulatory agencies, for remote electronic authorization of fulfillment at the pharmacy especially for mail order prescription fulfillment and the pharmacy-prescriber link can, if desired, add additional levels of security by transmitting or exchanging supplemental electronic identifiers.

However, better security, in terms of ensuring that the filled prescription is released to the intended patient, or their agent, may by provided, by treating an electronic prescription transmission to a pharmacy as an advisory against which fulfillment may be initiated, while the prescription is released only in exchange for a manually signed hard (paper) copy. Signature recognition or transmission as an individual graphic element, insofar as it may be useful or required in the prescribing process, can accordingly be incorporated in systems according to the invention. Processing demands on the user's device can be minimized by confining the device's capabilities to recognition of the signatures of only those users authorized to use that particular device.

Adding higher performance hardware to support the processing needs of handwriting recognition may be impossible with available technology if a preferred lightweight, compact form factor is to be retained for the user's device. An aim of the invention is to provide a qualified prescribing professional with a valuable tool that imposes no significant burdens of weight or volume on the user, that demands little of their time and yet can respond rapidly, delivering valuable drug and patient information to the user from remotely located, disparate sources. In other words, an aim of the invention is to provide an intelligent, knowledgeable computerized prescription pad.

This aim could be compromised by adoption of handwriting recognition technology at the date of this application. Similar problems apply to voice recognition as a significant data input medium. Either or both handwriting and voice recognition may be valuable enhancements of future embodiments of the inventive systems especially if future technology makes these capabilities available on smaller user devices. In particular, limited voice recognition may be valuable as a user identifier for password access or as an authorizing signature.

Security

Security may be provided by password protection operating hierarchically on one or more levels, to provide varying degrees of access according to the user's level of authorization, as desired. Additional password or numeric code control may protect sensitive system-accessed information, for example, patient records, or parts thereof, or physician-user data, including personal lists and prescribing profiles.

Patient record access codes can, in selected instances, be patient provided, or granted by intelligent security control cards, having been furnished to the patient by a system administrator, or agent, prior to the physician encounter. Physician or other user access to a patient's record, or to sensitive details thereof, can thereby be restricted to a need-to-know basis. Access by third parties to physician-related data can be similarly protected.

Provision for override of such security features should be available, for example for an emergency room doctor, and is allowed on a special case exception basis, is auditable, and traceable to the overriding user.

Password-controlled access to many computer networks is often workstation dependent with each workstation using a unique password to access the network. Although user passwords may also be employed, these are often workstation-dependent, for example, being incorporated in the workstation's login scripts. In contrast thereto the present invention prefers that user access to the host computer facility be device-independent so that a given user can access the system via any of numerous devices, provided they have the right password or passwords. By this means, users are not dependent upon a single device that may be lost or misplaced.

A still more preferred feature is to have user passwords which link each user with an individual profile or style sheet on the host computer facility representing the user's pattern of preferences so that the user-customization features of the system, which will be described more fully hereinafter, are readily available to the user independently of the particular interface device that happens to be employed for accessing the system.

These and other device-independent features can permit the prescription management system to be fully operative without committing useful data to storage on the user device. This is a valuable security feature. In the event of theft or attempts at unauthorized use, even by skilled third parties, a user device will be worthless as a means to access sensitive data on the system or to use the system illegally.

Optionally, lost or stolen devices can be deactivated by the application or by system software, after user notification, by erasing or otherwise rendering device-resident application procedures inoperable, without loss of device-resident data. Use of a virtual patient record, as described herein, which need not be stored locally, is a valuable safeguard against unauthorized access of confidential data on lost, stolen or "borrowed" user devices.

Host Computer Facility

Currently contemplated preferred embodiments further control the processing and storage demands placed on the user's device by intelligently delegating data-processing and storage activities to a linked remote, host computer facility, as referenced above, to the extent warranted by the capabilities of the user device. Thus, for example, a comprehensive drug database may be stored and maintained on such a host computer facility with selected data, for a particular drug list or an individual drug's formulation characteristics, being forwarded to the user's device on an as-needed basis, then being eliminated from the user device when no longer required. Other activities may advantageously be performed locally on the device, such as dynamic assembly of records from elements retrieved across the network from remote storage, and storage of the user's personal or most frequently referenced data and data lists, where the device's capabilities permit.

Where the user device is more powerful than present-day PDA's, for example a present-day desktop computer or perhaps the PDA's of the future, more processing and data storage functions can be retained at the user device rather than delegated to the network. Although permanent (disk, diskette or flash memory) storage may have uses, security concerns can be better managed on the network than on the user device, so that it is preferred that minimal data be permanently stored on the user device. Accordingly physical storage resources of limited user devices are preferably allocated to RAM rather than permanent storage.

Advantageously, a user profile can also be stored on the host computer facility so that if the user device is lost, broken or stolen, a new device can be automatically reconfigured across the network linking the user to the host facility, so that the application behaves the same.

Preferably such a host computer facility also provides customized services to each user device, performing "user-adaptive" functions for that device, as described herein, to adapt it to its authorized user or user's prescribing behavior and improve the level of assistance provided to the user. Employing such off-loading techniques, permanent storage capabilities of the device can be minimized in favor of faster RAM storage capabilities.

The screens are designed to be non-intimidating to computer-inexperienced professionals and to present familiar information and terminology to them while avoiding specialist computer jargon. Individually, they are easy-to-use for novices yet rapid enough for experienced users. Collectively, they provide an appealing system interface which can flexibly integrate into a physician's personal work flow.

In addition, the screens are laid out in the manner of appealing logical forms that echo familiar data formats encountered by a physician in their day-to-day work. An important objective is to make the screens self explanatory within the professional's normal terms of reference so as to avoid any need for access to help, although of course, HELP buttons can be provided if desired and extensive help documentation can also be provided. System utilities such as indexing, setup and purging are either concealed from the user or removed for execution on a remote host computer facility. Data integrity and availability responsibilities are also delegated to the host computer facility, or its remote data suppliers. Thus data saving, archival, backup and data-replication functions are host facility responsibilities, not concerns of the user.

The system is designed to require a minimum of actual text or data entry. So far as possible, item entry is effected by selection from lists of items, for example by highlighting an item, then clicking a mouse, or more preferably penning, to activate an item.

The prescription management system is made as user-friendly to physicians as possible, for example, by using familiar professional terminology and abbreviations. Thus terms such as "Patient" or "Pt", "Drug" or "Rx", "Condition" or "Dx" and "Treatment" or "TX" are used rather than confusing generalities such as "subject" and "item" that often appear in generic software. The Prescription Management System shown in this embodiment of the invention has been designed for use with small portable personal computers, especially hand held devices known as personal digital assistants. Those skilled in the art will understand that the system can readily be used on or adapted to other hardware platforms, for example, a physician's desk top computer and can be expressed in different software interfaces from that shown.

Referring now to FIG. 1 the system entry screen illustrated has a user-customizable button bar 10 which has been set with a conventional Quit button 12 and a Help button 14, along with a Mail button 16 for accessing an electronic mail ("E-Mail") system, a Prescribing button 18 for accessing t he prescription management system embodiment of the invention, an Encounter button 20 for accessing a patient encounter management system (not further described herein). Ans Svc button 22 accesses an answering service screen (not shown), which as a convenience function can be dynamically linked via the host computer facility to log incoming calls for the user. The answering service is preferably intelligent and prioritizes, by flagging or displaying, patient- or treatment-related calls, for example those from a pharmacy, while screening out or de-prioritizes less relevant calls.

History-Cognitive Drug and Condition Listing

A Doctor's Lists button 24 accesses a more or less complex library of patient condition and therapeutic drug lists. Preferably, the drug and condition lists are linked together to associate a drug with one or more conditions for which it might be prescribed and, in most cases to provide the physician user with a conveniently displayed, concise selection of drugs for treating any particular condition. In a preferred feature of this invention, the system has a user-adaptive character and adapts itself to the user's habits and prescribing patterns so as to service the user more efficiently. To this end, the drug lists or the condition lists, or both, are system-generated and system-modified with use, block 123 (FIG. 21) to reflect the prescribing frequency of particular drugs, block 87 or the frequency of occurrence of particular conditions, block 89. Thus, more frequently prescribed drugs or more frequently encountered conditions can be presented to the user physician in a more prominent manner or more immediate manner than ones found by the system to be historically less common in the particular user prescribing environment. In this way the system becomes more valuable with use as the drug and condition lists develop into personalized lists featuring the user's preferences.

With such cognitive features the inventive system is effectively cognizant of ongoing prescribing activity. It comes to know its user's environment and preferences, can adapt itself to any number of specialist situations, and can, if suitably equipped, subtly prompt the user, online with original, relevant, but elusive information derived from the user's computer-memorialized practice experience. For example the system may prompt the user that the last time Drug X was prescribed for Condition Y, Patient Q reported adverse reaction Z. Where the host computer facility documents a catalog of known adverse reactions to system-listed drugs, a system enhancement can report new adverse reactions to the user or centrally, to the host computer facility, by tracking logged patient conditions and relating them, where appropriate, to a previous prescription. In similar manner the system may log drug--drug interactions, which interactions can also be associated with a target condition or conditions. Many other valuable retrospective statistical studies and analyses are made possible by deployment of the invention, as will be apparent to those skilled in the art. While such studies are potentially of immense public value if widely implemented, careful controls will be required to avoid reporting unrelated conditions as adverse drug reactions.

With time, as it adopts appropriate specialist prescribing patterns, the user-adaptive prescription management system of the invention can be just as relevant and useful to, for example, a specialist in tropical medicine as it is to a pediatrician. This desirable result can be achieved without encumbering either specialist with the needs of the other.

Those skilled in the art will appreciate that the invention's cognitive, user-adaptive features employ significant programming routines and procedures and are quite different from common, user-responsive software defaults which merely offer defaults pre-set by the user or simply show the last used item, file or the like as a default.

If desired, the user's prescription management system can have built-in, online, statistical reporting functions enabling a physician user to review their, or others, historical experience with a particular drug or condition and providing online historical review of any other activities or data entrusted to the system.

Of scientific note is that the system is privy to and operates at the confluence of three powerful emergent data streams: encyclopedic data on therapeutic agents intended to moderate particular conditions or patient problems; data on individual prescriber activity using skill and judgment to diagnose conditions or problems and make prescribing decisions selecting and applying therapeutic agents to diminish diagnosed conditions; and patient history data recording not only prescribing decisions but also the results of those decisions (see the description of FIG. 12, below). Thus, the system captures not only prescribing activity but also the prescriber's intent, the problem or condition targeted by the prescriber in specifying a particular drug, and can track the success of that intent. The linkage of treatment with condition treated captures the reason why the doctor took the prescribing action that was taken. This intent may, and can legally, be different from approved FDA therapeutic indications for a drug.

Of commercial note is that the foregoing data may be aggregated for multiple users, for example by the host computing facility, for market research purposes. Also, an individual user's prescribing patterns may be reviewed by the user or by others. For example, drug benefits companies, can review the user's prescribing patterns for formulary compliance and respond by encouraging better compliance, where appropriate. Release of such data to third parties can be controlled to safeguard the privacy of the prescriber, or other health care provider, by prescriber-determined data access protocols specifying who, or what organization, department or group, may access what data, when they may access it and what they can do with it. For example, one physician may permit academic use for research studies and prohibit commercial use while another may permit either.

As will be described in more detail subsequently, a range of optional features, for example the answering service and e-mail features mentioned above, or other communications features, can be made available from button bar 10 providing the user with user-configurable means to customize the system to their personal needs and tastes.

Intelligent Drug-Selection Procedure

Skeptical prescribers are encouraged to adopt the prescription management system of the invention, by its ability to bring to the point-of-care, in readily utilizable form, a battery of relevant drug-specification information and important patient-related information, much of which is not readily accessible at the point-of-care by conventional means.

Preferred embodiments of the invention achieve this desirable result by providing an intelligent drug-selection procedure which is supported by transparent connectivity to multiple remote proprietary information systems at the point of care, enabling a physician to draw upon the following categories of data:

i) physician-user prescribing-frequency data;

ii) patient drug formulary information as to a drug's status with a patient's drug benefits provider;

iii) drug dosage characteristics, for example, form, size, route of administration, amount, frequency and the like;

iv) drug-specific treatment information as to condition-related efficacy, and preferably as to contraindications and adverse reactions;

v) relevant patient history information as to current and previous prescriptions, and preferably also, pursuant to the teaching of the present invention, problem-history information; and

vi) laboratory and other diagnostic test information related to the patient's indications, to dosing, to therapeutic choices or to specific drug selections.

Preferably, this data is brought to the point-of-care by relying upon retrieval from remote source databases at remote facilities responsible for capturing original update data, and not by relying upon redundant non-source data requiring constant synchronization with source data to remain current.

Diagnostic Tests

Items i)-v) above, will be described in considerable detail hereinafter. With regard to diagnostic tests and procedures, for example radiology, the invention contemplates electronically bringing relevant information to the point of care to assist health care providers make informed decisions. Such diagnostic information may comprise recommendations for clarifying a tentative diagnosis, or choice of diagnoses, or may comprise diagnostic results that can be used to make more informed therapy decisions and, in particular, to make better therapeutic drug selections. Body system function tests, for example renal or liver function tests are clearly valuable to a drug selection process, since renal and liver condition are important in determining dosages of some medications. Other therapy-relevant diagnostic determinations can usefully be presented at the point of care, by means of the present invention, for example, drug-level determinations can enhance dosing decisions.

Patient Encounter Program

A useful, prescription management system-compatible patient encounter program can begin with a patient selection screen such as that of FIG. 2. The patient selection screen of FIG. 2 can be activated by any one of multiple programs which may, for example, be initiated via the system entry screen of FIG. 1, but could be independent, free-standing programs or any other program for which the ability to create, update and modify a patient-specific record or a patient history is valuable.

Preferred embodiments of software procedures (or programs) associated with the novel patient record selection procedure illustrated in FIG. 2 can access multiple remote databases to retrieve patient records, for example, by using the host computer facility, and can also post new patient records, and updates, created locally by the physician-user, to the multiple remote databases in real time, or in batch mode.

Patient Record Source Data

Source data for a typical patient record may be distributed across multiple, geographically dispersed, electronically incompatible, remote databases maintained for example by drug benefit companies, insurers, laboratories, medical facilities, diagnostic testing facilities and health maintenance organizations, including government agencies (MEDICAID, MEDICARE, etc.) and health care providers themselves, that have serviced the patient in the past. Known automated patient record systems either ignore such remote data and work only with data created at the maintaining facility or vertically integrated health care organization, or create and maintain duplicates of the remote data.

Still more preferred embodiments of the invention provide substantial savings of resources, time and effort by using only source data for patient records, minimizing creation of multiple redundant local databases that require constant synchronization with remote sources if they are to remain accurate and up to date.

The invention also provides novel data-retrieval network systems to retrieve relevant patient data elements from multiple remote heterogenous primary source databases. Preferably, every time a host computer facility receives a call from a user device for a patient history or patient record, relevant data elements, for that record, or a record component (e.g. the most recent six-month or twelve-month portion), are retrieved from remote source databases, dynamically assembled, or integrated, into a virtual patient record, as described above, and delivered to the user device as an integral system data set. Alternatively, record assembly, which does not require undue hardware resources, can be performed on board the user device.

The record is viewed and may be printed out by the user, with patient authorization, but does not need to be permanently stored.

The host computer facility responsible for dynamic assembly of the virtual record logs the time, date and calling user to provide an audit trail of access to the patient's record, but does not commit the record to permanent storage. After use, the virtual patient record disappears, although it can be reconstructed archivally.

If the record is required again, it is assembled anew, thereby incorporating any updates that may have occurred in the interim , for example changes in d rug benefit status, insurance coverage or the like, newly generated laboratory, radiology or other diagnostic results, or other, e.g. emergency, prescriptions dispensed. The act of assembling a record externally of its sources immediately dates the record: it is cut off from any updates, and therefore liable to become incomplete, obsolete or dated. Virtual patient record assembly, as described herein, avoids this problem making local storage of patient records unnecessary.

Transactions are archived by the host system to provide a complete transaction history, so that past activity can be reconstructed. Such a data-reconstruction capability to provide clear hind vision of the patient's record at any given time is an important medicolegal capability. That historical version is preferably reconstructed from a transaction log and assembly of timed and dated record elements, or segments, in a manner not unlike that used by version control software.

Creating a virtual patient record permits optimal data currency and accuracy and, by avoiding unnecessary redundant copies of patient data minimizes liability for misuse or unauthorized access. Patient confidentiality can be maximized and is verifiable by the system-generated audit trail.

Preferably for individual record elements to be admitted to the system, they are required to be at least dated and preferably also to be timed at source, such timing and dating relating to whatever event created the record. In addition to its value as an integral record characteristic, chronological data is useful for retrospective archival reconstruction of a record as it existed (in its elements) at any given point in time. This can be achieved by retrieving record elements, as described above, using a suitable date filter and if appropriate, a time filter, to include only those (or selected ones of those) record elements that existed at the desired given point in time.

Such an archival retrospective record reconstruction capability is a highly desirable adjunct to the virtual patient record described herein permitting full creation and examination of any desired historical records, such as may be required for review or legal purposes.

Using the above-described method of dynamic retrieval from remote databases across a data-retrieval, record-integrating network, source database proprietors can remain wardens of the only copy of that data and obtain patient authorization to be the sole repository of that data. Laboratories can keep laboratory records; insurance companies can keep insurance records; hospitals can keep hospital records; and health maintenance organizations can keep their own records; without ever having to release copies of these records into external electronic storage by third parties, with the security hazards attendant upon such releases. Any electronic release made externally using the data access control features described herein can be assured of always being authorized by whatever entity, be they patient, physician or organization, that has proprietary rights in the data.

FIG. 2: Patient Selection Screen

Upon selecting Prescribing button 18 by clicking or pen contact, a Select Patient screen 46 selection screen, for example as shown in FIG. 2, is displayed as a preliminary to prescription management functions. Referring to the patient selection screen of FIG. 2, and the flow diagram of FIG. 17 the name, age, gender, and social security numbers of patients who have authorized the user physician to treat them, or to access the system on their behalf, are listed under respective column header buttons, namely, Name button 26, Age button 28, Gender button 30 and Social Security # button 32.

Lists can be scanned, or text entries made in a blank search box 34 at the top of the screen, using string or full name searches to locate the desired patient or to review the patient list. Column headers 26-32 can be clicked or touched to sort the patient list on any of those fields and activate search box 34. Search box 34 is linked to the sort fields so that, for example, if the listing is sorted by social security number then alphabetical entry attempts are rejected from search box 34 and numeric entries are used as social security number locators. The characters can be keyed or system provided from pop-up screens, or voice or handwriting recognition may be employed.

In Select Patient screen 46 New Pt button 36 activates a new patient entry bar to enter a new patient name, block 37 (FIG. 17), while a patient who has authorized the user physician to treat him, can be highlighted from a list of patients 47. The Ok button 39 accepts a highlighted patient selection and advances to the prescription management screen of FIG. 3. Cancel button 38 returns to the system entry screen of FIG. 1.

If desired, preliminary selection of groups of patients can be made by providing various patient lists, for example "Today's Patients", "In-Patients", "Out-Patients", "Private Patients" and the like. Such patient lists are preferably system-maintained, on an ongoing basis, using the latest data available to the system and preferably enable the user to select a convenient group of patients that has a high probability of including the next patient or patients to be encountered, thereby speeding access and retrieval of a desired patient record. Where the user typically encounters patients in groups, for example one group in an out-patient clinic and another group in an in-patient clinic, such grouping of patient records into lists also facilitates organization by a host computer facility of display data into small batches that can more rapidly be communicated via limited capacity copper wires and modems and are of a size that can conveniently be held in RAM on a small, portable user device.

Patient Data Security

Critical to public confidence in the prescription management system of the invention are issues of security, since the system requires access to personal records. Many people will fear unauthorized access to or use of their personal information. Preferably, the invention provides careful controls to alleviate such fears and to prevent unauthorized access to a patient's data or to their physician's prescribing profiles.

Preferably also, the system, or an associated support network, provides data access controls such that the only accesses that can occur are those that have been authorized or preauthorized, at a point of care or elsewhere, in accordance with security profiles on the network established on behalf of data-proprietor entities such as patients, physicians or organizations. It is further preferred that the entity's security profile, or filter, details what data can be accessed, when it may be accessed, where it may be accessed and by whom it may be accessed.

Various suitable data access control measures will be known to those skilled in the art and considerable security can be obtained by using more or less complex identifiers for patients or for physician-users of the system or for both.

Patient records should use a standard identifier to be clearly and distinctly identified with a confidence level appropriate to the expected patient population in the lifetime of the system so that the records of patients with similar or identical names are not confused. If desired, a coded alphanumeric patient identifier (not shown) may be used. Alternatively, or in addition, other unique patient identifiers such as social security numbers may be used alone or as secondary references in conjunction with patient names and the like.

More relevant to security is proper identification of a user to whom patient data is released or from whom new data is received by the host computer facility. While numeric or alphanumeric user identification codes provide some level of security, higher levels are provided by using graphic, photographic or fingerprint recognition to identify a system user.

More preferred embodiments of the invention can ensure a still higher level of confidentiality by automatically maintaining a complete audit trail of access to patient data. Preferably the audit trail details, for every access, who or what organization accessed the record, what part of the record was accessed, when it was accessed (both date and time) and what was the purpose of viewing the record. Thus, associated with every patient record is a timed and dated log of every physician user, organization or health care professional accessing that record. If desired, the log can be reported, or made available to a patient, on request, for example through online access (with careful security controls), via print or fax, and so on.

Patient-directed control of the flow of their own data, a novel concept in medical or health care information systems, can be achieved by centrally inputting at the host computer facility patient-generated record-access specifications to determine which users, or user organizations or departments (for example clinics), can access what data during what period and what uses can be made of the data. Clearly, such specifications must not deleteriously restrict physicians in the execution of their professional missions. Such record-access specifications or profiles could be maintained at a remote database rather than the host computer facility. Thus, access to their records is controlled by patients and individuals and organizations can be given patient-defined, selective access or access based on a need to know, or a patient may block access to all data flow, if they wish. In emergencies, physicians may be able to override a patient security block, but such events are recorded so that any abuse can be monitored and action can be taken to discourage abusers.

MD-Related Data Security

Many similar data security considerations apply to prescriber-related data. Used comprehensively, as it is intended to be, the system is privy to full particulars of a physician user's professional prescribing behavior, day in, day out, potentially throughout their career. System resources may be used to compile any desired historical record of a user's prescribing activities. Patient-confidentiality aspects of this data have been addressed above and can be satisfactorily managed by controlling access to patient-related data in accordance with a patient's previously, or currently expressed wishes, as described herein. In addressing physician-oriented prescribing issues, the historical record may be rendered patient-anonymous by stripping the data of recognizable patient identifiers, or aggregating the data. The resultant historical prescribing data can communicate significant information about the prescriber, is personal and proprietary to the prescriber.

Pursuant to this invention, the prescriber's rights in their historical prescribing data are protectable in a manner similar to the protection affordable to patients, by providing prescriber-determined access control specifications detailing permissible levels of third-party access to prescriber data. Such prescriber data access control specifications can be stored in individual files on the network and can comprise as to who or what organization, or type of organization may access what data, for what purpose and for what period of time such access right may be effective. Clearly, multiple levels of access control may be described to any desired degree of complexity. User preferences may include user authorization for data access by various third parties for example health maintenance organizations (HMO's), hospitals, government agencies, managed care organizations and so on.

A particular group to whom a prescriber may wish to yield access rights comprises collective bargaining associations, for example independent practitioner associations, preferred provider organizations and physician hospital organizations. Preferably, all accesses to a prescriber's data are system stamped with a date, time and accessor ID, to create an audit trail of such accesses, similar to the audit trail left by accesses to patient data.

System-determined access control can be invoked, whenever a prescriber data access request is received, by referencing the prescriber's access control file and permitting or denying access in accordance with the file's specifications.

Prescription Creation Screen 39

Referring to FIG. 3, prescription creation screen 39 has a full array of user-activatable buttons enabling a physician to draw on powerful resources within the prescription management system as well as supporting resources in the host computer facility and associated data-retrieval network, as will shortly be described. Near the top of screen 39 is a patient features bar 40 below which a prescription features bar 42 coordinates all features necessary to review current therapy and order changes in treatment, or order new treatment, for the selected patient. A prescription history zone 43 extends across the middle of the screen, the lower screen portion contains a prescribing zone 44, and a screen title 45 appears at the top of the screen.

Patient features bar 40 comprises a Select Patient button 46, a selected patient indicator 48, in this case Mary Harrington, a patient Problems button 50 and a patient Allergies button 52. Beneath Problems button 50 are displayed Mary Harrington's currently active problems 51 or conditions, shown here as pharyngitis and bronchitis. Beneath Allergies button 52 are displayed Mary Harrington's known allergies. Pressing or otherwise activating Problems button 50 or Allergies button 52 access the remote database for the patient's history and, opens a window or screen listing problems or allergies from which a physician, or other professional user, can select new problems or allergies to add to Mary Harrington's record, or delete ones that are no longer active. Optionally, system-provided problem or allergy libraries may be organized into multiple lists with button 50 or 52, respectively, opening a list selection box as a preliminary to displaying a selected problem or allergy list.

Problems or conditions 51 and allergies 53 are here displayed as a helpful notation for the prescriber and do not become prescription elements as a result of being selected for display in this part of the screen. However, selections made here are functional in that selected problems 51 (conditions) will become defaults or preferred choices in a subsequent condition specification procedure and the system will review any drugs prescribed for relevance to allergies 53.

Prescription features bar 42 comprises an Rx History button 54, an Rx Options button 56, an Updating indicator 58, an Rx Info button 60 and a Renew Rx button 62.

Prescription history zone 43 displays those historical prescription details that may be relevant to a current prescription and has a Condition field 64, a Drug field 66, a Size field 68 a Dosing field 70, a generic flag 72, an Expires field 74 and a Mine field 76, in which the various characteristics of patient Mary Harrington's previous prescriptions are listed.

Prescribing zone 44 comprises three active buttons, New Rx button 78, Send Rx button 80 and Close button 82, below which extends a prescribing header bar 84 which contains field identifiers for data entry of a full complement of prescription details. Available prescription detail fields comprise a Condition field 86, a Drug field 88, a Generic field 90, a Form field 92, a Size field 94, a Route field 96, an Amt (Amount) field 98, a Refill field 100, a Dosing field 102 and an Expires field 104.

Multiple lines of the selected patient's prescription history are listed in patient history zone 43 in the middle of the screen for convenient review by the physician-user, and possible renewal, with scrolling or paging of extensive histories. Depending upon the patient's previous whereabouts and service providers, individual lines may come from multiple remote sources. Such histories are preferably compiled by the host computer facility in response to a call from the user device (see the description of FIG. 16).

Prescribing zone 44, lower down prescription creation screen 39, allows a physician user to select and prescribe drugs and dosages, for the selected patient, in this case Mary Harrington, and to transmit the created prescription by activating the Send Rx button 80, externally across a data network to other interested and authorized parties for prescription fulfillment block 55, patient record updating arrow 57 and the like. Send Rx button 80 can also output the prescription to print, block 59, or storage.

Select Patient button 46 returns to the patient selection screen of FIG. 2 for selecting a different patient from one or more lists. Preferably, Select Patient button 46 draws up a "Today's Patients" list or whichever patient list the user last selected from, or a default, user-selected patient list, and provides the options of selecting a new patient from alternative patient lists.

Problems button 50 brings up a patient problem history information screen such as that shown in FIG. 12 (to be described) in which a historical record of the patient's individual symptoms and diagnoses is listed and to which new problem reports can be posted. To maintain data integrity, and as a legal safeguard, historical information is not editable but may be supplemented, for example by reporting the subsequent status of a problem as (still) active or inactive. Preferably, any such additions to the record are stamped with the identity of the reporting physician, providing valuable elements of a treatment decision-making audit trail.

The patient's drug-related allergies, or drug reactions, are brought up in possibly editable form (screen not shown) by activating an Allergies button 52 and may be automatically system updated, if desired by adding newly reported drug reactions and allergies, arrow 51. Desired personal or drug records relevant to possible allergies of this patient may be summoned from the host computer facility, which may in turn call on the remote database data-retrieval network block 41 (FIG. 17) for records or record elements.

Rx History button 54, scrolls, drops down, or otherwise accesses any additional patient history lines beyond what will fit in prescription history zone 43 and may introduce vertical or horizontal scroll bars, or both, into zone 43, enabling the user to display any desired section of a patient's prescription history in zone 43 with the top line of the history highlighted. Any desired prior prescription line displayed in zone 43, can be highlighted by clicking or pressing on it.

A highlighted prior prescription can be automatically renewed by clicking or pushing an Renew Rx button 62. Typically, prescription creation screen 39 opens with the most recent prescription highlighted for possible renewal. Activating Renew Rx button 62 posts a highlighted prior prescription into prescribing zone 44 for automatic renewal, after editing, if desired. Renewal of any prior prescription can thus be effected in as few, as two user steps by pressing Renew Rx 62 to post a highlighted previous prescription to prescribing zone 44 and completing a prescription in a single step from there. If desired option buttons such as Renew and Send Last Prescription or Renew All Active Prescriptions can be added. Pressing header buttons Condition 64, Drug 66, or Expires 74 causes the drug history display to be sorted by the selected header enabling the prescription history to be evaluated according to a particular parameter. This feature is of particular value for patients with long and complex treatment histories.

An important novel feature of the inventive prescription management system is the ability to associate a specific patient condition with each drug prescribed. By capturing detailed information on every prescription the system automatically builds a novel patient medical record having new uses in evaluating individual patient treatment and in enabling powerful new, multi-center outcome studies for evaluating therapies in various populations of patients.

By deploying the inventive system regionally, nationally or in some other population area, and employing the preferred methods for retrieving patient data from remote sources, as described herein, a complete patient record of all activity within a region can be built. Preferably this is a virtual patient record dynamically assembled only from original source data, which, as described above, is maintained in component form at multiple distributed source databases, is retrieved therefrom across a data-retrieval network from which the source databases can be accessed, and is compiled or assembled into a single virtual or transient record that appears to the user as an integral system data resource.

FIG. 18 shows in flowchart form the sequence of Condition field 64 may be accessed. The field may be accessed from the System Scripts window 18 to enter a patient's specific condition. After the Condition field 64 is accessed, the condition may be entered by the user through the keyboard. Alternatively a condition could be chosen from the remote database 210. The remote database 210 would also assist the user by accessing a patient history to give insight into the possible diagnosis. Once the diagnosis in entered, the information is stored in the remote database 210 for future reference.

Outcome Studies, Prescription Cost Savings and Drug Alerts

Patient histories generated by the inventive system can show not only the drugs prescribed, but also the conditions for which they were prescribed, allergies, demographics, insurance coverage, treating health care providers, and so on. Known medical management systems do not provide listings associating each prescribed drug with a patient condition or problem, as reported to, or diagnosed by their physician.

Careful review of a patient's record for relationships between amelioration of problems and prescription of particular drugs can provide important information about the efficacy of a drug for a particular problem in a given patient. Review of a physician's prescribing record, detailing the various drugs selected to treat the different conditions exhibited by the patients encountered in the physician's daily practice, can reveal valuable information about the physician's prescribing practices and the degree to which they follow formulary guidelines.

This information is clearly of value to the individual physician and can, if desired, be enhanced by including in the problem record a condition severity rating, enabling declines (or increases) in severity to be reported. The resultant patient prescription history, replete with dated information as to patient problems, what drugs were prescribed to treat those problems, what forms, routes of administration and dosages were used and, by implication from the timing and nature of subsequent problems, what the outcome of that prescription was, provides a very attractive treatment evaluation tool to a physician, and a powerful inducement to any professionally conscientious physician to use the prescription management system of the invention.

Implementing the invention on a wider scale, valuable new outcome studies and clinical trials are easily, or even automatically, performed. One of many problems in successfully implementing the herein described prescription management system on a large scale is one of funding the system. Medical cost structures, with their reimbursement systems leave little scope for expenditure on aids to overall practice improvements which may have to