|
| United States Patent |
5,737,539 |
| Edelson , et al. |
April 7, 1998 |
Prescription creation system
Abstract
An electronic prescription creation system for use by professional
prescribers at the point of care has a prescription division subsystem
permitting creation of a single prescription to be automatically divided into
two components for fulfilment of one portion quickly and locally at higher cost
and of another portion by remote mail order taking more time but providing a
cost saving for a major part of the prescription. The prescription creation
system has an ability to access remote source databases for system presentation
to the prescriber of relevant, authorized and current drug, drug formulary and
patient history information, with dynamic creation of a transient virtual
patient record, the information being presented to the prescriber before
completion of the prescription, permitting enhancement of the quality of
prescribing decisions.
| Inventors: |
Edelson; Jonathan (Scarsdale, NY);
Mayaud; Christian (New Canaan, CT) |
| Assignee: |
Advanced Health Med-E-Systems Corp.
(Tarrytown, NY) |
| Appl. No.: |
330939 |
| Filed: |
October 28, 1994 |
| Current U.S. Class: |
705/3; 705/2 |
| Intern'l Class: |
G06F 159/00; G06F 017/60 |
| Field of Search: |
364/401 M,401 R,406,408
395/203,202,228,229 |
References Cited
[Referenced By]
U.S. Patent Documents
|
4674652 |
Jun., 1987 |
Aten et al. |
221/3. |
|
4695954 |
Sep., 1987 |
Rose et al. |
364/413. |
|
4766542 |
Aug., 1988 |
Pilarczyk. |
|
|
4847764 |
Jul., 1989 |
Halvorson |
364/413. |
|
4860899 |
Aug., 1989 |
McKee |
206/534. |
|
4991877 |
Feb., 1991 |
Lieberman |
283/36. |
|
5065315 |
Nov., 1991 |
Garcia. |
|
|
5072383 |
Dec., 1991 |
Brimm et al. |
|
|
5084828 |
Jan., 1992 |
Kaufman et al. |
|
|
5208762 |
May., 1993 |
Charhut et al. |
364/478. |
|
5292029 |
Mar., 1994 |
Pearson |
221/2. |
|
5347453 |
Sep., 1994 |
Maestre |
364/413. |
|
5347477 |
Sep., 1994 |
Lee. |
|
|
5390238 |
Feb., 1995 |
Kirk et al. |
379/93. |
|
5502944 |
Apr., 1996 |
Kraft et al. |
53/55. |
|
5528021 |
Jun., 1996 |
Lassus et al. |
235/380. |
Other References
Anonymous, "Data Hard to Get, Has Many Applications," Employee Benefits Plan
Review, vol. 45, No. 5, pp. 62-65, Nov. 1992.
"Newton Software Titles" Brochure, Part No. L00587B, (1994, Apple Computer,
Inc.).
"Newton Getting through the day is a business in itself" Brochure, Part No.
L00683A, (1994, Apple Computer, Inc.).
"Newton-based units to proliferate in fall", p. 8, PC Week, Aug. 15, 1994
(Ziff-Davies, New York).
"The future of medicine" pp. 1, 4-9, 12-18; The Economist, Mar. 19, 1994.
Abstracts (A-N) and papers (AA-SS) in 1994 Spring Congress Final Program and
Abstract Book (American Medical Informatics Association, Bethsda, MD, Spring
Congress May 4-7, 1994, San Francisco); as follows:.
"Mobile Computing in the 1990's" by Larry G. Tesler, p. 29.
"Wireless Clinical Computing: Uses and Spinoffs" by Larry Frisch, M.D.
"Health Data: Disclosure, Protection, and Privacy" by Molla S. Donaldson,
M.S. et al., p. 39.
"Electronic Signatures: A Dissuasion Strategy to Protect Medical Records
Based on Medical Liabilility" by F.A. Allaert and L. Dusserre, p. 40.
"The Trade Off Between Accessibility of Information, The Truthfulness of
Medical Records, Etc." by Dr. Ian Purves, et al., p. 41.
"Demands of Academic Physician on Future Medical Information Systems" by
William M. Detmer et al., p. 55.
"User Requirements for the Computerized Patient Record: Physician Opinions"
by Wally R. Smith, M.D. et al., p. 56.
"Patient Use of H.I.S. E-Mail System" by Steve Edison, MSc et al., p. 57.
"Enhancing HMO Prescription-Writing Via Pen Computing" by Paula Mikrut, p.
74.
"The Right System for the Write Reason" Marc A. Gelman, MD, p. 83.
"Ob/Gyn Physician Assistant: Goals for Medical Persnal Mobile Computing" by
Robert LaLouche, MD et al., p. 84.
"Identifying Medical Concepts in Text: Use of a Very Long Barrier Word List"
by Stuart J. Nelson et al., p. 87.
"Integration of Statewide Patient Data from Heterogeneous Data Sources" by
Lori L. Reed-Fourquest et al., p. 92.
"PEN-Ivory: The Design of a Pen-Based System for Progress Note Creation" by
Alex D. Poon et al., p. 99.
"A Simple Approach to Physician Entry of Patient Problem List" by Harm J.
Scherpbier, M.D. et al., pp. 206-210.
"The Universal Patient Identifier: A discussion and Proposal" by Paul C.
Carpenter, M.D. et al., pp. 49-53.
"Patient-Centered Computing: Can It Curb Malpractice Risk?" by Edward E.
Bartlett, PhD, pp. 69-73.
"Acceptance of Direct Physician Access to a Computer-Based Patient Record In
a Managed Care Setting" by John B. Dewey, M.D. et al., pp. 79-83.
"Integrating Hospital Information Systems. The Challenge and Advantages of
(Re-) Starting Now" by Umberto Tachinardi, M.D. et al., pp. 84-87.
"Real and Imagined Bariers to an Electronic Medical Record" by David M.
Rind, M.D. et al., pp. 74-78.
"The Problem-Oriented Medical Synopsis: A Patient-Centered Clinical
Information System" by Frank W. Stitt, M.D., pp. 88-92.
"Physician-Directed Software Design: The Role of Utilizatin Statistics and
User Input in Enhancing HELP Results Review Capabilities" by Patricia A.
Michael, PhD, pp. 107-111.
"Client-Server, Distributed Database Strategies in a Healtcare Record Ssytem
for a Homeless Population" by Henry C. Chueh, M.D. pp. 119-124.
"Development of a Portable Information System: Connecting Palmtop Computers
with medical Records Systems and Clinical Reference Resources" by Raghu Ram,
m.D. et al., pp. 125-128.
"Does an Integrated Medical Workstation Really Help Clinicians?-A Formal
User Evaluation" by E.M. van Mulligen et al., pp. 219-223.
"Automated Identification of Relevant Patient Information in a Physician's
Workstation" by Henri J. Suermondt, PhD, et al., pp. 229-232.
"Developing A General Practice Medical Workstation: The Integration Aspect"
by R. Frassine M.D., et al., pp. 238-242.
"Implementation and Evaluation of Practice Guidelines" by Siew Hong Lam,
M.D., pp. 253-262.
"Physician Use of Computers: Is Age or Value the Predominant Factor?" by
Paul D. Clayton et al., pp. 301-305.
"An Information Sources Map for Occupational and Enviromental Medicine:
Guidence to Network-Based Information Through Domain-Specific Indexing" by
Scot M. Siverstein, M.D., et al., pp. 616-620.
"Unifying Heterogeneous Distributed Clinical Data in a Relational Database"
by Keith A. Marrs, et al., pp. 644-648.
"Protection of Patient Data in Multi-institutional medical Computer
Networks": Regualtory Efectiveness Analysis.
"The Development of a Data Security Model for the Collaborative Social and
Medical Services System" by Ross Dargahi et al., pp. 349-353.
"S-O-A-P Drug Interaction Program 3", Dialog File 256, Acc. No. 01304468;
released Nov. 1987, item (304468) in Directory.
"Ez-Rx System"; Dialog File 256, Acc. No. 01017836, by Signature Software
Systems, Inc., released Apr. 1982 item (017836).
"Ez-Rx System"; Dialog File 751, Acc. No. 00268373, by Signature Software
Systems, Inc., released Feb. 1982 ›DATAPRO!. |
Primary Examiner: Hayes; Gail O.
Assistant Examiner: Thomas; Joseph
Attorney, Agent or Firm: Handal & Morofsky
Claims
We claim:
1. A computer-implemented prescription creation system for use by a prescriber
in creating a prescription at a point of patient care, said prescription being
usable by a pharmacist to dispense drugs, said prescription creation system
comprising:
a) electronic posting means to select and capture in said prescription:
i) a patient identifier;
ii) a prescribed drug intended to treat a patient condition;
iii) a dosage for said prescribed drug; and
b) a prescription division subsystem to create a bridge prescription divided
into a local prescription component intended for fulfillment at a pharmacy
convenient to said patient and a separate, remote prescription component
intended for fulfillment at a remote, lower cost, mail order pharmacy
said prescription creation system automatically creating and outputting said
prescription components.
2. A prescription creation system according to claim 1 wherein said local
prescription component is adequate for short term needs and said remote
prescription component provides a longer term supply.
3. A prescription creation system according to claim 1 wherein said electronic
posting means further selects and captures in said prescription:
iv) the patient condition intended by said prescriber to be treated by said
prescribed drug;
whereby a created prescription includes said patient condition and said
prescription creation system further comprises:
b) a displayable library of prescribable drugs; and
c) displayable patient drug formulary information to indicate to said prescriber
user selected ones of said prescriber drugs included within a drug formulary
plan associated with said patient and approved by said plan for treatment of
said patient condition, to facilitate compliance with drug formulary plan
guidelines at the point-of-care;
said patient condition, drug library and drug formulary plan information being
system-presented to the prescriber before completion of the prescription.
4. A prescription creation system according to claim 3 comprising a screen
device to initiate dynamic assembly of a patient history record from elements
retrieved from remote source databases, said patient history record being
system-presented to the prescriber prior to completion of the prescription.
5. A prescription creation system according to claim 3 wherein relevant drug and
patient information is retrievable from remote source databases and can be
system-presented to the prescriber prior to completion of the prescription.
Description
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; and
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.
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 at 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 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 "pocket-book" 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 the
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-modified with use to reflect the
prescribing frequency of particular drugs or the frequency of occurrence of
particular conditions. 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 drug
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 patient
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, 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 82.
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.
New Pt button 36 activates a new patient entry bar, while 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, or a, 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, 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
externally across a data network to other interested and authorized parties for
prescription fulfillment, patient record updating and the like.
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 48
and may be automatically system updated, if desired by adding newly reported
drug reactions and allergies. 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
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.
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 be squeezed out of
tight overhead budgets. Accordingly, significant cost to the physician user, or
user's medical facility will be a major deterrent to system adoption. Preferably
the system is provided to prescribing users on a low-cost or no-cost basis with
funding from outside sources.
Implementation of the invention is expected dramatically to reduce the overall
cost of prescriptions and this saving has been estimated to be from 20 to 40
percent of total prescription costs. Savings will accrue initially to the drug
benefit management companies who reimburse the direct costs of most
prescriptions, but can be expected eventually to be passed to corporations and
consumers by way of lower drug benefit rates. Such savings realized on a
national scale would amount to many billions of dollars and provide an avenue of
reimbursement for system proprietors. In the early 1990's, the cost of
prescription drug benefits is one of the fastest rising components of all health
care costs.
Outcome studies produced by the system may have substantial value to various
parties, and their sale can support system costs, as may formulary compliance
savings. For example, drug efficacy data is of value to pharmaceutical
companies, as is early warning data from reliable specialists regarding adverse
reactions. Subject to confidentiality and other relevant controls, such data can
be automatically compiled and readily supplied by system management, requiring
only approval, not active participation by involved physician prescribers.
Equally, the system may facilitate clinical trials by identifying health care
providers or prescribers who would be likely participants in trials, based upon
their having frequently diagnosed relevant conditions, or specified relevant
drugs, as shown by their historical prescribing profiles, or relevant patient
histories. Suitable patient pools can be identified similarly.
Organizations participating in outcome studies, for example health maintenance
organizations, insurance companies, hospitals, physician alliances and the like,
and may pool their data but may not wish to reveal certain proprietary data. By
employing data access control methods for accessing such organizational data,
such as the methods described in detail herein for controlling access to
patient's rights, the system of this invention can enable organizations to
control what data they release.
To implement such clinical trials, additional information required for
collection can be obtained by flagging selected prescribers' profiles to trigger
additional on-screen routines so that whenever a trial-related drug or condition
is selected by the prescriber, they will be asked to supply necessary additional
information. For example, whenever a prescriber participates in a trial relating
to treatments for gastritis, the system can request information as to whether
certain tests were performed, and what were the results of those tests. Thus,
the test drug might be appropriate for, or be in trials relating to, gastritis
testing positive to H. pylori, whereas a different drug would be indicated for
H. pylori-negative gastritis.
The system can also provide, preferably from source databases, complete
prescription drug disclosure requirements as set forth by the FDA, including
full cautionary information, for example as is now set forth in the Physicians'
Desk Reference (Medical Economics) and Physician's GenRx (Denniston Publishing)
knowledge of which by the prescriber may be necessary to avoid malpractice
liability, and dissemination of which may limit a drug manufacturer's liability.
Efficient promulgation of drug disclosure information to system users is
tantamount to publication, yet can be more current than any printed document,
and may be accepted as an alternative to hard copy publication or supersede it.
In addition, the system provides a valuable means for government agencies and
others to communicate important messages, such as drug warnings and alerts,
quickly and directly to physician users. Electronic mail accessed via Mail
button 16 can be used for this purpose, and may include priority flags
triggering screen alerts, but a much more powerful route for communicating
warnings relating to particular drugs is to associate the alert with system
information on the drug so that when a user calls up the drug in question, they
receive the warning or alert, or other special message.
In the extreme case of withdrawal of a drug from the market, that fact can
immediately be communicated to system users. Thus a drug can be withdrawn from
the market the same day by making a system entry preventing completion of a
prescription for the withdrawn drug. Alternatively, a warning can be posted
directly to the prescription. Current users of the medication can be identified
from prescription history records, referencing not only drugs prescribed, but
also prescription expiration dates. Both the patient and their doctor can be
notified immediately. In this case, electronic mail is a preferred route for
notifying the physician.
Relative cost-to-benefit data can also readily be prepared in outcome studies
when individual drug costs are factored into the data, and such cost:benefit
data can, in some circumstances have very substantial dollar value to drug
benefits management companies whose objectives are to maximize the quality of
care while minimizing the cost of that care.
Pharmaceutical and managed care companies can gain marketing benefits from use
of the system to introduce new drugs or new uses of old drugs to physicians, in
a relevant manner, at a moment of peak interest.
Other benefits can be derived from outcome studies using the novel
drug-prescribed and condition-treated data records provided by the prescription
management system of the invention. For example, the appearance of a new patient
problem may be insignificant when associated with prior prescription of a
particular drug for one patient, but may gain significance when repeated for a
number of patients.
Optional system enhancements may enable post-introduction market surveillance of
new drugs to be conducted for adverse outcomes to the treatment of a specified
condition or conditions. For example the system may monitor patients reporting
new problems after having been prescribed the new drug in question, refer such
new problems to the physician user to qualify them for medical relevance and
then statistically compare a collection of similar reports with data on a pool
of similarly treated patients for significance.
Continuous post-market-introduction monitoring of a drug in relation to the
treatment of conditions is possible, and an end-to-end solution to the problem
of managing unanticipated problems arising with new drugs can be provided: the
system provides a vehicle data collecting relevant data; parameters and a means
for analysis of that data; and a means for disseminating alerts and advisories
regarding newly discovered problems. The same vehicle is used for all three
steps.
With such a system enhancement, one specialist pioneering a new drug for a
particular condition may provide an early warning of adverse reactions not
identified in clinical trials in a manner not heretofore obtainable, because of
the difficulty of coordinating prescription and diagnostic data.
Quickly and conveniently presented at the point of care, as an integral part of
the prescribing process, in the manner achieved by the system of the invention,
this information can be of immense value to a physician when treating a patient,
widening the physicians' choices beyond their own field of knowledge (by
suggesting new drug information) and helping the physicians optimize the
prescribing process.
Another advantage of the invention is that each physician user inherently and
easily supplies critical enabling data for outcome studies as part of the
prescribing process. No extra effort is required by the physician to make the
data available for studies. One potential difficulty in making such studies is
the existence of legal barriers to aggregating patient data into studies without
specific patient permission. While this might be obtained on a piecemeal basis
or by the prescribing physician, a much better solution is provided by centrally
maintaining patient directed patient-record-access specifications, as described
above. The system can then include only those records of patients agreeable to
becoming study participants in such outcome studies.
The historical drug-prescribed and condition-treated records obtainable by using
the invention can provide a basis for condition-based treatment guidelines
developed by drug formularies. This novel data provides a new vehicle for
outcome research for managed care, leading to new approaches to cost-effective
prescription treatments.
Compilation of an extensive or national database of (patient-anonymous) records
providing a statistical historical listing of drugs prescribed versus associated
conditions for which they were prescribed would be in the public interest and of
considerable value, so long as patient-confidentiality were maintained.
Widespread adoption of the present invention can help achieve this desirable
goal. It is relevant to note that FDA regulations only permit a drug to be
promoted for approved, specific therapeutic purposes but physicians are
professionally free to prescribe an approved drug for any condition for which
they believe the drug to be effective or useful so that, failing specific
point-of-care diagnostic information, no assumptions can be made as to the
treatment objectives of any particular prescription. Accordingly, prior to the
present invention, statistical prescribing data have generally lacked knowledge
of why a physician prescribed a particular drug, and such data is, in most
cases, not useful for outcome studies and cannot be related back to other
patient-specific variables present in the patient's medical record.
Prescription history record
Referring to the prescription history zone 43 of the FIG. 3 screen, under the
condition field 64 is listed a condition reported as active when the drug was
prescribed. Drug field 66 may be a generic name or a brand name. The Size field
68 is the dosage size. Dosing field 70 shows the dosing frequency. The "G" flag
72 is for generic and is a simple yes/no indicator. An Expires field 74 displays
an expiration date system calculated from the prescription quantity (not shown),
the size and the dosing rate and indicates the day on which the prescription
will run out.
The last column, Mine field 76, is a yes/no toggle flag indicating whether the
prescribing physician was the current system-designated physician user ("Y"=my
prescription) or some other physician ("N"). Another prescribing physician's
details and other data relevant to a previous prescription can be obtained by
pressing Rx Info button 60, or double-pressing or -clicking on the appropriate
prescription history line, to draw down a prescription information screen, for
example, as shown in FIG. 12. Additional available options, if any, can be
accessed through the Rx Options button 56.
Update button 58 can be a simple blinking indicator alerting the user that their
device is communicating with the host computer facility and actively processing
a local update. To indicate additional time taken accessing remote databases,
the message can change to "Remote Retrieval", if desired. Additionally, Update
button 58 can activate various update options, selectable from a menu, if
desired. For example, Update button 58 may offer a selection of different
sources from which to update the patient's prescription history. While a
preferred objective of the invention is that the prescription management system
obtain a comprehensive, nationwide update of any previous prescribing activity
regarding this selected patient, considerations of system speed, system
development or marketing considerations may make it desirable to offer patient
prescription histories drawn from all prescribing activity in a more limited
geographical region, for example, local or regional updates local network
updates or capability to update from the physician's institutional or office
practice information systems.
New prescriptions
Activating the New Rx button 78 highlights the first available blank line in the
lower portion of the prescription management screen for creation of a new
prescription by a physician-user. During the prescription creation process, the
user receives intelligent decision support from the system of the invention.
Preferably, the system proffers the prescribing physician comprehensive relevant
prescribing data to enable creation of a new prescription intelligently, in an
informed, manner with routine look-up functions being fully automated so that
professional time spent on routine chores is minimized or eliminated. To this
end, data entries available via both Condition button 86 and Drug button 88 are
selectable from extensive lists, as will be described hereinafter.
As described above, the system provides the user through their interface device
and a linked host computer facility, transparently connectivity to multiple
remote proprietary databases for retrieving necessary data such as drug and
condition lists.
Pressing (or clicking on) highlighted fields beneath the headers in prescribing
header bar 84, in most cases, activates pull-down menus, or data entry scrolls.
Generic field 90 is merely a toggled flag while Expires field 104 is a
system-calculated field. Although provision can be made for a physician to make
original entries, the preferred embodiment provides a comprehensive selection of
system-generated drug prescribing data from which the user may make selections.
If the user knows the drug they wish to prescribe, the drug name may be keyed in
or, preferably selected by highlighting and clicking from one or more
intelligently maintained lists presented in drop-down menus to post it to the
respective highlighted field under Drug header 88. Alternatively, the user can
select a condition from a condition list and make a drug selection appropriate
to that condition from a drug selection screen such as those shown in FIGS. 4
through 11 as will shortly be described in more detail.
Generic flag 90 is a simple yes/no indicator which is linked to each drug
selection to approve generic drug substitution for brand name drugs by the
pharmacist, if such substitution is permitted by state regulation.
Prescription quantification
The Form, Size, Route and Amounts headers 92-98 are linked to the drug selected
and bring system resources to bear to enable a prescriber rapidly to quantify
the prescription with appropriate dosages that can be filled at a pharmacy,
without undue difficulty. Activating any one of the fields under headers 92-98
drops down a menu, which menus together offer a selection of all known
formulations of the drug selected, as provided by the manufacturer, using
comprehensive drug inventory data accessed via the host computer facility or its
supporting data-retrieval networks.
The entry for Form field 92 may be selected from choices such as capsule,
caplet, tablet, and liquid. That for Size field 94 might be a selection of 50
mg, 100 mg, and 200 mg and the Route field 96 selections might be "PO" for per
oral, by mouth, "PR" per rectum, "IV" for intravenous, and so on. The displays
are related and intelligently selected to display relevant options. Thus, for
example, if "PO" is selected as the route of administration, only PO dosage
forms are displayed. On the other hand, if PO oral forms are selected, "PO"
appears as the route of administration.
The Amt field 98 is the amount or quantity of drug to be dispensed in the
prescription, for example 30, 50 or 100 capsules or 50, 55, or 100 ml of liquid.
Refill field 100 shows the number of times refilling is permitted and Dosing
field 102 has two columns, one being a numeric designation of a number of
tablets, caplets or liquid dosages to be taken at any one time and the other
being an alpha indication of the dosing frequency such as QD for daily.
|