QuickQuack:
An Efficiency Aid
for Physicians
Outline of the Challenge
One of the frustrating mental tasks of the physician is to cull from a sometimes bulky medical record the essential facts needed to properly manage a patient's chronic and acute medical problems. This is often daunting, as medical records are not primarily organized for the purpose of aiding this search. Problem lists are poorly maintained, lists of medications are often out of date or incomplete, lab and xray reports tend to be organized chaotically, and correspondence and reports are seldom indexed or organized.
This document describes a fantasy computing system, called QuickQuack, aimed at making essential clinical information easily accessible. It does this by "knowing" what data is pertinent to each patient's chronic conditions and continual medications, and by presenting this data in organized flow-chart form. The concepts can readily be adapted to the needs of any specialty.
The "core" of this system is intelligent integration and display of the information normally available in the medical record, integration that speeds up the clinician's job of assembling and reviewing each patient's status, and helps prevent oversight of important information. Review of such information is crucial to the management of chronic conditions and to health maintenance, and is important in the care of acute problems, which often is affected by concurrent conditions. The "problem list," originated by Weed, is one expression of this need for organization. It can be viewed as an index to the patient's difficulties, and can be used as a basis for organizing access to the medical record.
This is obviously applicable to complex internal medicine or pediatric patients, but is also important in the longitudinal care of healthy children an adults. It will be of greatest help to the primary care physician or the to specialist following complex chronic or subacute illness.
The "core" does two important things: it serves as an index to the medical record, and maintains a set of "smart" flowsheets for each patient. Each flowsheet brings together important lab and historical data that must be monitored to best manage a patient's condition, considering the patient's diagnoses and medications.
The data of the medical record can be usefully divided into its traditional sections, and QQ could be developed one section at a time. It is easy to add a data base to the core information-organizer; the challenge is to do this in a way that makes organized information more accessible to the physician while seeing a patient. For example:
No new technology is needed for this system. Notepad personal computers,
the last piece of technology necessary to assemble the ideal office system
for physicians, were introduced in 1991; software tools have been only
improved since then.. The other key components--fast, efficient, large
mass storage; indexing algorithms and schemes; spreadsheet code; menuing
and windowing software; character recognition; drug databases; disease
databases--are all well developed.
In fact, one might view QQ mainly as a sophisticated "shell" that supervises other (existing) programs and organizes and analyzes their output. This has become known as middleware.
This document is a general, comprehensive overview. Pragmatically, design of a comprehensive program best begins with a single, important feature, demonstrates its scope and usefulness, and is extended and enhanced. Any useful feature of QQ could be used as a beginning; prescription management is a natural one.
QQ is not aimed at getting a computer terminal into every exam room, or to make computer experts out of physicians. The main goal is to provide a powerful tool that efficiently collects and organizes the information that a physician most needs during the patient visit, information which the physician must otherwise cull from the chart on each visit. This can be done with a paper record or with a computer terminal.
The "paperless office" is an impossibility. First, electronic media are too evanescent; second, paper documentation is required for many purposes, and a well-organized paper record is much more efficient than an electronic one for many purposes. Computers are powerful and efficient organizers of huge amounts of data, but they do have functional limitations, only one of which is the fact that the computer screen is a tiny window. Third, it would be foolish to try to reduce to electronic form every bit of the voluminous paper reports received in a medical office, much of which is clinically trivial.
The "core" of the QQ concept is therefore dynamic organization of the record: QQ must first and foremost provide an index to the information in the medical record: current and past medications, xrays, consultations, past hospitalizations, surgical procedures, immunizations, significant illnesses, laboratory data, and so on. Its strength is that, as an automated program, it can refresh itself with every patient visit. For example, it could provide an updated index to each patient's chart with each appointment, and could do so with only seconds' advance notice.
For internists, a prescription-writing database would be a helpful central function, for our chronically ill or elderly patients often have complex disorders, take many medications and have a long history of medication changes. Other specialties would have other features as the most important function: family physicians and pediatricians would probably be better served by centering on a problem list; obstetricians would want to focus on flow-charting; surgeons on outcomes and followup; etc.
The QuickQuack concept includes a panoply of useful functions: problem list management, prescription management, laboratory data flowcharting, an index to xrays done, and so on. Most important, it offers to integrate the chart data intelligently, combining knowledge of diagnoses, therapy, and medical monitoring to put before the clinician in organized form those items which are the most important.
Various specialties have somewhat differing areas of medical records "pain," and other features than a prescription database would be attractive. To discover what features would be most important to a given specialty, one need only ask what repetitive, time-consuming, onerous medical records tasks are troubling doctors in that specialty. The main challenge of design will not be merely to identify and eradicate those aspects of managing clinical data which destroy doctors' efficiency, but to create a user interface that makes doctors feel more efficient.
Computers' ability to organize information can be put to use by making QQ a clinical database (electronic medical record). The data in any given specialty which is so central that paper lists and flow-charts already have been created, can be more pleasantly and efficiently manipulated with the aid of a computer system specifically designed to locate, organize, and retrieve clinical data from the patient record.
Nevertheless, while QQ can grow into a comprehensive electronic medical
record, its greatest benefit is as a powerful, intelligent index
to the medical record.
This system is based on a touch screen--a notepad computer--that
provides both input and display. A standard computer with keyboard
would be also useful, and should be provided for in the design of the system,
but there are several advantages to a notepad computer. Some of these
advantages are:
When the day begins, the day's patients are listed in a corner of each screen. When the assistant enters the room with a patient, the screen display--blanked to preserve confidentiality and to prevent unauthorized access--is activated with a simple code. (Such a code, used with a blank screen, might be to touch two corners of the screen in a particular order.) The doctor's patient list for the day appears, and the assistant touches the name of this patient. As the day rolls along, the names of patients already seen do not appear, having been scrolled up; those more than an hour down the schedule are not shown unless the list window is expanded.
At the same time, large windows (or screen areas) open for data entry, each labeled: BP, weight, temperature. Prompts for other information would appear if the clinic has configured the system to routinely ask for it [length, height, heart rate, comment, etc. Probably three data entry windows might be enough. They should be visible from 2 or 3 feet (an arm's length plus) and the assistant must be allowed to write large. As each item is written, QQ displays its interpretation of the handwriting, permitting instant correction.
When this is as complete as it's going to be, the bottom corner of the screen is touched, the data entry areas close and the data is displayed at the top left of a comment area, which opens for the assistant to record the chief complaints -- five to thirty words briefly describing what's wrong, when it happened or started, what the patient's goal is, etc. This also is interpreted and displayed "on the fly." When done, the assistant again touches the bottom right corner of the screen.
At this point the assistant "opens" the medication list, and asks the patient, "Now let's review your medications. I want to make sure our records agree with what you are really doing." On a comment line after each medication, the assistant records whether the information in the list is correct. If not, the medication has been discontinued by the patient (then the reason is noted) or the patient's schedule is different from what was intended, either on the patient's own initiative or at a visit with another doctor. A comment about side effects or efficacy is sometimes important. Additional medications may have been started by other doctors. Dermatologic preparations, over-the-counter medications, injectables, and ophthalmic preparations are often not mentioned spontaneously by patients, either because they are not "pills" or because they may not have come from Dr. Quack.
Now the assistant has completed the essential tasks, and touches the bottom left of the screen. It blanks, and requires the doctor's or assistant's code to become active again.
While the patient is waiting for the doctor to float in, QQ updates the medication interactions list and the pertinent lab data for each medication. It searches the problem list for keywords that match words in the assistant's notes.
The doctor can review this data on a screen in her office prior to entering the exam room. With paper chart in hand, she will usually want to briefly look at the assistant's notes, review the problem list to refresh her memory, and may want to review pertinent lab data before seeing the patient, as these intellectual tasks detract from giving the patient personal attention when they are together.
The doctor then enters the exam room. She activates the screen, and QQ has opened a large "notepad" window on the right (or left, if the doctor is a southpaw) side of the screen. The screen itself is on a cord, so the doctor can hold it on her lap and make brief notes while taking the history.
The obvious alternative is the battery-operated mode. This has the obvious advantage of lower cost--one to a doctor rather than one to an exam room--and the obvious disadvantage that it wouldn't be available to the assistant for preliminary data entry and patient selection, or for automatic updates from the central database. On the other hand, the assistant's data could be recorded on a worksheet and typed in later.
For that matter, in another type of use of this system, both the assistant and the physician record all patient observations on a written worksheet, and the "official" progress note dictated. The computer would then be used mainly as a computerized chart search and retrieval tool. This has the advantage of requiring only one computer per doctor rather than one per exam room.
More computers allow more work to be done via automation, but costs more initially. It's obviously a tradeoff: additional devices will be worthwhile only to the extent that they make the doctor and the assistant more efficient and effective.
On screen are small menu items or small windows to the patient's problem list, past history list, medication list, and lab flowsheet, which expand for review when touched. Lab data is best presented in a flow sheet form.
At the completion of the history, the doctor examines the patient, afterwards recording brief notes on screen from which to make a dictated note later.
In our sophisticated office, there is a link to the lab. Opening an "orders" list, the doctor touches prompts for the lab work she wants done, and this is transmitted to the lab, where it is typed out on a printer in a queue for lab personnel to review (or the patient's name is added to a list of waiting patients on the lab technicians' screen).
At the conclusion of the visit, the doctor opens the prescription list,
marks for renewal some medications, writes the names of new ones or chooses
them from a list, and makes written instructions on the screen. The prescriptions
are transmitted to the pharmacy via secure modem (where they are printed
out on a queue and downloaded to a temporary file on the pharmacist's computer
for addition to his own database after verification.), or are printed out
in the exam room, in the doctor's office, or at the nursing station. The
doctor's written instructions are also printed out, and are together handed
to the patient as he leaves. All the "standardized" patient instructions
that I've ever seen are hopelessly wordy, needlessly overgeneralized, and
lack the interest and punch that get people to read. The best instructions
are very brief lists made especially for individual patients. Thus QQ must
have a simple, fast editor for customization of instructions.
The goal of QQ is to make the computer into a tool that permits
the physician to be more efficient and more effective.
The tension between people and computers stems from computers' demand for time, energy, and attention. Often computers are claimed to be more efficient, but these claims often ignore the time required for maintenance of data, difficulties in entering data, and agonies from system crashes or other machine or software related tragedies.
Computers can be used to summarize or analyze data in powerful, complex ways, presenting useful analyses that are beyond the capacity of humans. This power is often confused with efficiency.
It is only efficiency that will persuade doctors to bring a computer into the examination room. A gain in efficiency is sensed when the total time or effort necessary to complete a set of tasks is reduced.
Most people think of efficiency as completing a task or a set of tasks in less time. It is important to understand that to reduce the stress of a task or the energy required to finish it, without significantly increasing the its duration, is also a gain in efficiency.
In addition, the computer can make work more tolerable even without clear gains in efficiency: To delegate a hated task to a subordinate or to a machine is always desirable. Tedious or arduous duties are ideal for machines. Tedium is money. For the doctor, paperwork is an arena needing personal pain relief.
The most effective ways in which software can ease the doctor's burden are:
Strengthening the Doctor's Hand
The crucial question for the physician is this: are there any tasks performed during the care of patients in clinic which can be performed as well or better by a machine or with the aid of a machine, in such a way that the total effort, frustration, or time is so significantly reduced that the physician will want to spend two to five thousand dollars per physician for this equipment, and several hours of time learning how to use it?
What tasks of patient care can be aided by or delegated to a machine? In pondering this question, it will be useful to summarize the main props used and players involved in a patient visit.
Hardware. This is listed first just to remind ourselves that the choice of hardware can be a hindrance or a boost to efficiency, and can determine whether productivity software is used at all, or enjoyed.
Ultimately computers may be brought into the examination room via touch-sensitive flat displays that include handwriting analysis algorithms in ROM. These are still expensive, but could overcome the cumbersome need to use a keyboard, important for those physicians who type less well. They would prompt for information and record it, as well as display data.
The chart. This is the physician's paper memory. It contains progress notes, hospital summaries, laboratory data, xray reports, special procedures reports, and correspondence.
This represents a huge mass of data. If the patient is new to the physician he is seeing, the physician faces the daunting task of quickly identifying which elements are pertinent to today's problem and finding them in the record. A computer can't usually do this faster than a human. (The explanation of why this is true is long and involves a comprehensive discussion of pattern-recognition and natural heurisitcs and search algorithms too long to print here.)
The patient. This is almost always a person who can communicate readily or who has a surrogate that can communicate.
The physician's assistant. The tasks delegated to this person, usually a nurse, vary considerably. The common thread is that the patient must be prepared for the doctor's attention, in order to make the use of his time more efficient.
The physician. This person is typically under intense time pressure, and is expected to complete one or more very sophisticated problem-solving tasks within ten to twenty minutes, then create a cogent precis of that visit for the edification of future readers of the medical record.The process of one patient's visit typically contains the following tasks, in roughly this order:
Following is an example of the modules that will usefully fall within
QQ's structure.
QQ Structure
Core:
Lab Link
Pharmacy Link
- security
- file format differences
Scheduler Link
Key Hardware
Customization of formats, screens
To be able to provide customization that accomodates different work styles is important to providing the best possible ergonomics to individuals, as practice situations vary considerably.
Organized Information
The following types of information in a chart are amenable to easy organization. Computers are good at organizing (sorting & displaying) data.
Problem List. A list of diagnoses or chronic conditions, which may include medication allergies, past surgery, and crucial family history.
1. Diabetes Mellitus I
Medication list. If the list is short--one or two medications--automation won't gain the physician much.A. Retinopathy2. Ischemic Heart disease
B. Nephropathy
C. Peripheral neuropathyA. Angina3. Family history of breast cancer
B. Paroxysmal atrial fibrillation
C. Congestive heart failure
4. Penicillin allergy (anaphylaxis, 6/64)
(Dates in lists should typically reference the date of an explanatory progress note, not the date of the event itself. This is because our main use of lists will be to locate progress notes and other explanatory textual material.)
Note the elements that may be useful in the medication list:
Flow charts. Pregnancy progress sheets, diabetic management
charts, chemotherapy treatment and monitoring, antihypertensive or hypolipidemic
treatment and monitoring could conveniently be begun or maintained with
a computer.
Laboratory data. Most laboratory data is numeric. That which is not numeric is usually categorical and therefore easily coded or summarized. Laboratory data tends to be scattered in clinic charts, because it is reported from any of several sources. It is often necessary to create a "flowchart" of lab data, on paper or in the doctor's head, in order to best interpret it. A flowchart is just another name for a spreadsheet display.
Xray studies. It would not be useful to include the actual xray report. Just having the xray procedure and its date would permit the creation of a table of contents to this part of the chart as well as a flow chart of the procedures that had been performed. At most, one could add a summary diagnosis to the list.
| Date | Exam | Result |
| 6-75 | Barium Enema | diverticulosis |
| 8-79 | CXR | nl |
| 11-84 | UGI | DU |
| 8-88 | BE | tics, polyp |
| 9-90 | MRI lumbar spine | HNP Rt L5 |
Ancillary diagnostic studies. Same comments as for xray studies. Ancillary studies commonly performed include colonoscopy, pulmonary function testing, exercise ecg's, skin and other biopsies, & pap smears.
Hospital encounters. Again, simply listing the dates of admission would provide a useful index to the summaries contained within the chart. Including the major diagnoses or procedures would increase the list's usefulness. More would be inefficient.
Referrals. A list of specialists to whom a patient had been referred, with dates,foot{In this case, the dates will most usefully be the dates of the initial progress note describing the purpose of the referral and the dates of written communication to or from the consultant, copies of which will be in the correspondence section of the chart.} will be sufficient to create an index to this portion of the chart. end(Description)
Tedious Tasks
There are three enormously tedious tasks which diminish the time we have to interview, examine, and instruct our patients:
Medication maintenance. I often write every prescription three times: once on the prescription pad; once in the chart so I have a record, and once (in lay terms) on a scrap of paper so the patient has a written schedule of how to take the medications. It would be so wonderful to only have to do this once (or less).
Patient instructions. Written instructions are not always necessary; not all patients can read; many who can read don't; the standardized written patient instructions provided in the software I've seen are so verbose and hedge so avidly that they are unreadable. Some standardized instructions may be useful, but these are usually provided by pharmacists.
What I'd like is a simple text editor for quickly typing brief, customized patient instructions: I can type fast, printer output is legible, and the patient has something simple in hand to refer to when the fine points have been forgotten.
A useful enhancement would be to keep the AMA drug information for patients on-line, and print them only when a medication is prescribed for the first time for any patient.
Data Entry
Manual.
By the physician's assistant:
It's fair to say that any recording of data that is readily accessible will be delegated the physician's assistant. In my office this includes quizzing the patient to determine what medications are really being taken (as opposed to the intentions written in the chart after the last visit). It also includes checking weight and blood pressure and temperature when appropriate. It also could include verifying and entering important past medical history, for new patients (those new to the system), and updating the past history based on recent important events since the last visit.
This historical information would include all surgical procedures, menstrual and obstetrical history, landmarks of growth and development for pediatricians, immunization history, important medical diagnoses, current or past addictions (e.g., smoking status), and the results of recent hospitalizations or diagnostic consultation.
By the physician:
It will be useful to assume that many physicians will have to be wooed into using the system at all. The busy on-call family doctor seeing 40 patients a day will salute the good ideas in the system while racing by, and the medical secretary and the medical assistant will be responsible for all entry of data. The extremely busy physician will use a keyboard only when certain that this will save time. It will save time only when learning how to use the system is not itself a barrier.
From other machine sources (see also Interfaces).
It will always be tantalizing to be able to accept data from machines where it is stored or generated rather than keying in data by hand that machines have generated. To be able to do this will decrease the burden of maintaining QQ, making its use more attractive.
Data Display
As all medical data is time-dependent (the human body is pre-eminently a dynamic system), the flow sheet format will be useful for most purposes. I'm sure all the basic spreadsheet features will be useful, and I'll bet somebody's spreadsheet code could be purchased (there are a lot of good spreadsheet programs that died in the marketplace in the mid-80's) and an experienced programmer could be hired to customize it, perhaps its creator.
The flow sheet format that will work best is one which does not display empty columns, and that "collapses" into a single column those values obtained on approximately equivalent dates. In this regard the older the lab value, the less important for clinical decisions is its exact date.
I'd suggest using actual dates for the past month, monthly dates for
four months, quarterly for a year, and then annual data telescoped in single
columns. The "collapsed" or "telescoped" columns might contain several
values, in which the range (Or the mean; range is more informative but
takes up more room.) and number of observations could be reported, e.g.,
|alk ptase | 32-75 (4) | .
If exact numbers are wanted, the user should be able to reference the
cell or column with the cursor or keystrokes and "expand" perhaps by clicking
on it. e.g.,
YR -> QTR -> MON -> DAY .
The rightmost (oldest) column could simply be labelled "older," and
should either contain simply a tag noting that values exist (this would
be easier to implement and faster to calculate and display), or the range
of all older values. (Of course, some users will want the most recent values
on the left, others on the right.)
It would be useful to summarize lengthy reports such as a urinalysis or complete blood count by simply noting than they have been done--with a minus if no abnormal values are reported or a plus if there are abnormal values (the plus could be over-ridden by a doctor if the abnormalities were judged to be trivial, so the display would not be misleading in the future.) An"expand" feature would open to the complete report, or to a flow sheet devoted to a set of complete reports for the period of time encompassed in the column.
For example,
Joe Markiewicz
Wednesday 3-20-91
Clinic # 377-95-2287
DOB 12-17-64
Dr. Gruenhagen
| Dates: | 3-20-91 | 3-14-91 | Jan 91 | 4 Q 90 | 1989 | Older |
| Test | ||||||
| potas. | 4.2 | 3.8 | 3.3-4.0 (2) | 3.5-4.3 (3) | 3.2-5.0 (12) | |
| Creat. | 2.7 | 2.4 | 1.8 | 1.6 (2) | 1.2 | |
| HgbA1c | 8.3 | 7.8 | 10.2 (3) | |||
| Fast. gluc | 186 | 204 | 193 (2) | 92-420 (15) | ||
| UA | + | - | - (7) + (2) | |||
| hemogram | - | + |
Graphs
The ability to create graphs is problematic. They impress reviewers, and make sales pitches easy, but slow the system down incredibly and really don't provide useful clinical information except in unusual instances. If graphs are to be included at all, I'd suggest limiting them to very specific material: height and weight (for pediatricians; and if we want to be really fancy, plot them against a standard growth curve), blood sugar (I can envision entering a diabetic's home blood sugar readings and producing a graph for the patient's edification), and a few other things. Allowing each user to customize the interface by selecting particular data for graphing will keep programming time down and avoid slowing the system unnecessarily.
Possible Interfaces
To drug interaction databases.
The Medical Letter, Medical Economics Company, makers of the PDR, and several other firms sell drug databases that check medication lists for drug interactions. The Medical Letter's system is available in real time over the internet to subscribers. QQ should submit new prescriptions automatically to an interaction program, and should also check new prescriptions against the patient's drug-intolerance list. Almost all pharmacists have such software and use it. However, this would be attractive to physicians: We don't like to have these things caught at the pharmacy; it makes us look less competent.
A very useful extension of this concept is linking medications with laboratory monitoring. Many medications alter metabolic parameters--diuretics lower potassium levels, for example--that must be periodically assessed. A program that examines the medication list and offers a flow sheet of pertinent laboratory work performed over the last few months would be a real time-saver and would also prevent many oversights.
Import from pre-existing prescription or clinical history databases.
Many physicians already use such databases, and some import capability would aid them in conversion.
To accounts receivable software.
A possible use of interfacing with standard accounts receivable software is that AR software has a list of diagnoses, each associated with a prior patient visit. This file can be used to build a putative problem list that the doctor or his assistant can edit.
It would also be useful to simply list the diagnosis found in the accounts receivable software, as a check for accuracy.
Ordering system.
A link to AR software would be useful in an integrated system. The physician would record the diagnosis, the services rendered, and possibly also the ancillary services ordered (lab, xray, etc) at the keyboard instead of on a paper routing ticket (billing form). (Or the services would be ordered on paper and entered into the system when performed.) Laboratory and Xray billings must be linked to an appropriate diagnosis, so such a link is an important efficiency for the enterprise.
Some systems now have progress notes or word processing on line; many highlight medications, medication allergies, and diagnoses. Such highlighted data may also be used to build a file or an index to the contents of the chart.
I do think that on-line progress notes are not efficient. In the exam room it is much faster to scan paper progress notes manually than to use keyword searches on line. I am very good at finding arcane bits of data hidden even in thick charts; I am not so good at holding several items of data from disparate parts of the chart in my head or at assembling them into a mental flow chart. I am skeptical that even a powerful search engine with natural-language processing will be fast enough to be clinically useful.
To laboratory instruments.
Almost all laboratory instruments manufactured in the last six or eight years have included a serial port. Little software exists to take advantage of this, and I know of none that is designed to port lab values into a clinical record with display based on lists of diagnoses, medication lists, etc.
If QQ were part of an integrated system within a clinic, this would be a laborious but useful enhancement.
More useful is middleware that would mine a pre-existing laboratory database and present requested values in flowsheet format.
To scanners and character recognition software.
Manual data entry is tedious. It is not less tedious if done by a lower paid underling rather than a physician, just less costly. Scanners and character recognition software are improving and as more and more clinical history is kept on line, these will become of growing importance.
To diagnosis software.
Software to aid clinical diagnosis is available, and is fairly primitive. Its main limitations are a lack of basic clinical research on which to build the software and the difficulty of quantifying physical findings (or of recognizing the variable value of "soft" findings).
Providing a "window" to such software would sometimes be useful to the physician with a puzzling diagnostic dilemma, who might access it during "off" hours.
However, studies of the usefulness of such software has shown that it functions mainly expand the list of diagnoses considered by the physician, and seldom saves significant time.
To pharmacies.
Almost all pharmacists have computers. I would guess they would welcome software that could download prescriptions to their systems, and might be willing, in recognition of the efficiency and marketing edge this would provide, to fund this enhancement.' end(Enumerate)
Database structure.
The database structure is important in that the program should be from the beginning designed to accommodate all the envisioned enhancements without a database conversion.
Distributed processing.
There will be a lot of idle time for this system, as most of a physician's time will be spent in patient interaction and his assistant's time should be occupied mostly with communication.
Tasks such as sorting, checking for medication interactions, downloading files from a server or updating files on the server should be accomplished during this idle time.
User Interface: Ergonomics
Prompts.
It doesn't matter much whether menus, windows, etc., are used. It is important that the program's functions be "in the open" for the user. Layers of menus must be used very cautiously. Prompts need to be intuitive, and since different clinics will have different intuition, modification of the menu and prompt structure will be useful.
Key assignments.
For some tasks a keyboard will be much more efficient than a touch screen. Function keys will not be used; instead, a single key will open the menu system. Items are selected from menus with letters, so that the typist need not take his or her hands off the home row.
Displays.
Speed is more important than graphics capability. However, large screen fonts will be useful during data entry, and small fonts will be necessary to view lab result flow sheets.
There is no need for color displays except to impress the masses--which from time to time helps marketing.
Operating System.
The operating environment of QQ is not particularly important; connectivity to the lab and accounts receivable databases is important. QQ is not tied to any particular operating system, and hiding the system from the user through a well-designed user interface will make it easy for computer non-sophisticates to learn and use it.
Customization
Physicians have many common needs. But they are a breed of compulsives who each believes he has the one best way of functioning in the office environment. There are many routes to efficiency, and the more QQ does to permit doctors to bend it to their unique patterns, the better it will be accepted (and the better it will promote real efficiency rather than theoretical efficiency).
Forms and special prescriptions
The number of forms used by hospitals and nursing homes is almost countless, and they are proliferating in the doctor's office also. They mostly require reiteration of information that is already in the chart: the patient's identifying information, pertinent diagnoses, and often physical findings or lab results. The only thing that is not usually already in the database somewhere is the justification of whatever the form is for. This typically is a one-sentence explanation that a physician can quickly write out. The time-consuming part of forms is all the other stuff. Insurance companies and the feds feel it's important to completely fill an 8 1/2 x 11 inch page with blanks.
Durable medical equipment prescriptions.
The feds are now requiring that doctors fill out in their entirety the prescription forms for durable medical equipment. The goal is to prevent fraud by vendors; the result is another several minutes of paperwork. The forms need not be graphically stored; fortunately, the government specifies the information which must be provided, not the exact format.
Physical therapy prescriptions.
Physical therapy presents many possible choices for the physician, and written prescriptions are required for any third-party reimbursement.
Home health care referrals.
Home health nurses are required to receive written instructions after each physician visit. Mostly this could be accomplished by sending them a copy of the most recent clinic note with medication changes.
Nursing home admissions. (PPOC)
Patients admitted to nursing homes are required to have from the doctor a Patient Plan of Care (PPOC), a completed history and physical, and sometimes other information. To be able to generate these forms from a database would be a great help. However, most people are admitted to nursing homes only from the hospital (primarily because insurance and medicare only pay if they are admitted through this route). Thus, this is not frequently needed.
Return to work forms for industrial injuries.
Most clinics have a standard form for this. The information needed typically appears in the physician's progress note and could be extracted from it, or the note could be built on the information provided in filling our the form.
Standardized evaluations.
Physicals and standard evaluations of many types are highly repetitive. Sports physicals, gynecologic exams, cardiac evaluation, etc.--the list is almost endless.
These tasks can be partly or complete done with the aid of computers. It might even be useful, given a suitable input device, to use a computer in the exam room during an exam. For example, for a healthy patient with a cold only a few basic questions need to be asked, and only a few physical findings are appropriate. A "checklist" could be used to create an automated progress note. It would be necessary to permit "escape" to paper or a dictated record in case of the unexpected or unusual, such as the rare person who comes in with a cold and turns out to have Wegener's granulomatosis, or the sore throat with leukemia.
Items that would be especially amenable to automation, either in the exam room or for the transcriptionist include: begin
Physicians are not going to be writing their own progress notes.
Also, it is not very useful to review progress notes on screen, so there's
little reason to keep all progress notes "in" QQ for instant access. A
stack of paper progress notes can be scanned more quickly and efficiently
than a large text file. Two progress note features would be useful, however.
First, a "notepad," on which the physician can jot brief notes or reminders during the encounter, would be helpful. These help keep things "on track" during the visit and serve as an outline in dictating the final progress note.
Second, some ability to review progress notes would be useful in clinical research or in scanning a large volume of notes for a particular occurrence. For example, to discover whether a cardiac murmur was ever described, or whether depression was ever discussed.
Use in the hospital
Calculations, calculators and the intensive care unit.
Specialized care units often encompass physiologic monitoring. For the intensivist, a portable computer with a databank that helps him follow each patient during a complicated hospital stay would be useful. I'd judge that few private practitioners would avail themselves of such a system.
Updating clinical information and history by the physician at the hospital.
Some meticulous physicians would like to put their QQ database in a notebook computer. They can then review important historical information when their ill patient is admitted to the hospital. The memories of physician, patient, and family members are often sketchy on medications, recent lab results, and items of past history.
When a patient is discharged from the hospital, typically significant changes have been made in medications, diagnoses have been added to the patient's problem list, important lab values have been obtained, many special procedures performed, and particular followup arranged. It is of great help to be able to update QQ's database right there, whether this is done by the physician or the assistant.
Equipment
The key to feasibility of this system is equipment. Physicians in general are not eager to add the complexity of computer use to an already complex life. Examination rooms rarely have spare counter or desk space for a terminal, let alone a PC, keyboard and printer. I solved this problem with an expensive TFT screen and by putting the keyboard, with integrated touchpad, in a chart rack on the wall. But I type well; many physicians do not.
The one thing everybody can do is write. Handwriting analysis is improving. Japanese companies long ago designed touch-sensitive screens with Kanji character recognition in ROM; in 1991 Grid produced a computer that recognized of hand-printed characters. Several notepad and palm-size computers are now available quite cheaply that are very useful.
Character recognition algorithms will be improved further; moreover, the use of a stylus and screen for real-time handwriting recognition will allow easier recognition because pressure and acceleration vectors can be employed in the algorithm.
These screens also display characters. Thus, for example, the initial screen for any patient may prompt the medical assistant for blood pressure, weight, temperature, chief complaint, and review of medications.
The medical assistant writes each of these on the screen with a stylus; as this is done, the system analyzes the handwriting and displays its interpretation for verification.
Most of the physician's decisions may be accomplished by simply touching the stylus to menu items.
It would be desirable to permit the use of a keyboard (in a keyboard drawer) for entry of medications as an alternative to menus, and for the entry of free text, for use in writing instructions and for general input for those physicians and assistants who find this more convenient.
CPU, terminals
QQ may be useful in several possible configurations:
The Data Kernel
The common denominator of medical data is that it is time-linked. Few data items are regular or routine; sporadic collection is typical. But every datum is associated with a date on which it was collected or noted. Sometimes, but not always, this is the date on which an event occurred.Foot{It is more important to record the date it was noted in the record than the date it occurred, for to know the date it was recorded is to have an index to the documentation; to have the date an event occurred is merely to have a chronology (which is itself sometimes important, especially in filling out insurance or disability forms).}
Medical information itself, except for reports, always almost consists of lists. These may be lists of medications, diagnoses, medical problems, lab tests, or procedures.
This information always is concerning one person. While it will sometimes be useful for QQ to be able to analyze groups of patients for common information (medications, diagnoses, lab abnormalities, procedures performed, etc.), clinical care invariably concerns a single individual. (Social links are sometimes important, especially in family practice, so to be able to associate the medical data of relatives may occasionally be of great use.) Analysis of groups of patients is a typical concern of medical research, and is not traditionally part of the private practice of medicine (Data query and analysis would be, however, a valuable feature of QQ, as some sophisticated physicians--those most likely to be attracted to QQ--would wish to use such a feature.)
When time is of special interest and the data numeric or categorical, a flow chart is often created by the physician. Such charts may note change in lab values, physical parameters, or physical findings. For example, pediatricians might find useful an ability to automatically scan all the visit records for a patient and display the height and weight data in a table or graph.
The core task of data management for the physician can be viewed as creating files of time-linked data for individuals. Access to much of this data by query will be useful for research and review.
Dated Data
Therefore QQ will need to "automatically" link a date with every item as it is entered. For concurrent dates, the system clock can be read. For past information, the date must be requested. Clinical decisions do not require remote past events to be dated precisely, in fact, accurate dates may be unavailable; a challenge for the designer is to be able to allow entry of approximate dates which "blend" with more precise dates during listing, query, or analysis. QQ must thus accommodate uncertain, imprecise, and unknown dates, and the retrieval function must be able to display data in "approximate" order. "Collapsing" dates of remote past events may be useful; exact dating would then be optional.
Data Acquisition Model
Overall, data handling can be diagrammed approximately as
Data Entry
Manual
<->
Imported
Database
Manipulation
<->
Display
Links
Printing
<->
Archive
In linking to a mainframe system, it may be useful, especially, in the initial phases of QQ's implementation, to allow cut and paste operations to save certain types of data for reading, storage, or processing for key words or values.
Structure
Because all medical data is time-linked, the date or approximate date on when an event is notedfoot{Or, on which it occurred.} or when a result is generated always exists. and is usually significant.
All medical data is also regarding a particular individual, the patient.
The data was also generated or ordered by a particular person, the physician, and values and results are generated by ancillary personnel.
In most instances, the data related to one patient, one physician, and one date is a large block. Many elements of this block need no other association than to be within the block. A few elements need to be tagged with an identifier for analysis or recall by executive programs.
Numeric data
Laboratory values consists of four parts:
Laboratory values may be
Text
E.g., urinalysis reports contain fields for qualitative results. For example, protein is negative or positive. If positive, qualitative results are reported as 1+, 2+, etc., (or if measured, integer values in mg/dl from about 10 to about 1000). Occult blood is reported as negative, small, or large.
Numbers
Most lab results are integers. A few are decimals, such as urine specific gravity (range 1.001-1.030), potassium levels, many drug levels, etc.
There are two special challenges with laboratory results. First, changes in procedures are frequent, which will usually change both the units and the normal range. Sometimes the normal range alone is changed. This means that if one wishes to save space in files by not writing duplicate characters in every entry, some code must reveal which dimensions and normal range apply to any given result. This can be done with a brief code or by knowing that all results within a certain range of dates have particular dimensions and normal range.
Second, the intellectual powers in medicine are trying to force us to switch to System Internationale (SI), which uses molar concentrations (a belated attempt to bring medical clinical chemistry in line with the rest of the scientific world). Some physicians (all in the Eastern US, mostly in academic medicine) may wish a conversion routine.
Responsive Performance
QQ will be useful to physicians mainly if it speeds up retrieval and organization of data. Thus it is important to make speed the highest priority and to use whatever tricks necessary in order to perform "slow" tasks during idle time.
For example, a physician's schedule is known at the end of the preceding day; the patients on this schedule should be entered or downloaded into QQ and all pertinent data retrieved and prepared for display then, or early the next day.
Walk-in patients and emergency patients are actually not seen for many minutes--plenty of time for QQ to be given their identity and organize presentation of the data.
Some analysis or re-organization of data may be necessary during the course of a patient visit, and QQ should use "inactive" time to retrieve, sort, and prepare for display information that will be needed later in the visit. When new information is entered, the database should be temporarily updated and potential screen displays recalculated for rapid paging into video ram.
In the office, the keyboard will be quiet most of the time, so keyboard polling can be relaxed. Polling the keyboard only every 1/2 second should be adequate if, on detecting a keystroke, polling speeds up. A substantial keyboard buffer may be helpful. Can the CPU be functionally left undisturbed until an operation is requested?
The end result needs to be nearly-instantaneous response to requests for displays. The medication list, the problem list, the procedures index, and the laboratory results flow sheet can all be prepared in advance of a visit and even stored intact if desired.
To check medication interactions or to examine a small set of lab results pertinent to a new medication will require real-time analysis. It's in this area where data retrieval and display needs to be fastest. This analysis will be speeded in part by prior definition of a set of lab results that is pertinent for each medication, perhaps dependent on diagnosis (one can make pre-defined sets as complete as one has time and money for).
An Outline of the Medical Record
Physicians organize their accumulated paper for each patient in a particular way, which varies somewhat from clinic to clinic, but has many common features. As with all filing systems, the paper is divided into categories; in the patient's chart, within category, it is sorted by date. A simple scheme is: begin(Level) Progress notes. Sometimes divided by specialty, especially in larger clinics, where specialists don't understand each others' abbreviations.
Laboratory results. Rarely subdivided. Usually chaos reigns, with several types of reports from various sources external to as well as within the clinic.
Hospital summaries. Discharge summaries and other reports from physicians and surgeons.
Emergency room reports.
X-ray reports. Often other procedure reports are kept with them, such as ekg tracings, pulmonary function results, etc.
Correspondence. Including copies of records from elsewhere (other clinics' records can't be re-copied and released).
Comprehensive outline.
I. Progress notes.
A. "Vital signs." (BP, temp,
wt., etc.)
B. Narrative or structured
text.
II. Laboratory results.
A. Hematology
B. Serology
C. Chemistry
D. Bacteriology. (partially
qualitative; quantitative results often boolean)
E. Endocrinology
F. Urinalysis
G. Histology and Cytology.
1. Papanicolau smears
2. Other cytology
3. Biopsy reports
II. Text reports.
A. Radiology
B. electrocardiology
C. Pulmonary function
D. Other ancillary diagnostic
tests~ end(level)
III. Ancillary treatment begin(Level, Spread = 0, group)
A. Radiation therapy
B. Counseling
C. Physical therapy
D. Speech therapy
E. Occupational therapy
F. Other rehab~ end(Level)
IV. Temporary flow charting begin(Level, Spread = 0, group)
A. Obstetrical flow sheet
B. Chemotherapy flow sheet
C. Patient education documents
D. Cardiac rehab
E. In-hospital flow sheets,
e.g on ICU patients, would be useful in the portable version of QQ.
V. Immunizations begin
(Documentation is required in the chart of the manufacturer and lot
number of all vaccines.)
A. Childhood immunization
B. Adult immunization.
VI. Medications (Drugs) {We may exclude, I think, caffeine, tobacco,
alcohol, and illegal addicting substances.}
A. Acute, temporary oral
medications
B. Chronic or repeated intermittent
oral medications
1. Prescribed by a clinic doctor
2. Prescribed by a non-clinic doctor
3. OTC medications
4. Herbals
VII. Injected medications
A. Single-use, non-repeated
injections (There is no need to keep these in the prescription list;
they would appear in routine progress notes.)
B. Continuing injectables
1. Insulin
2. Chemotherapy (This is one medication type for which flow-charting is
very important,
and cross-referencing with laboratory results is essential.
Display of information by weeks, months, or "cycles" will be useful.
3. Allergy desensitization
4. Vitamin B-[12] injections
5. Home parenteral injections.
VIII. Past history
This information is collected from all areas of the chart, and is kept
in summary form by some clinics in a separate area, often a brief report
at the front.
A. Past medical history
1. chronic disease
2. past serious acute disease
3. allergies or adverse reactions to medications
B. Surgical
1. surgical procedures (date, indication, outcome)
2. serious injuries
3. fractures
C. Menstrual
1. Age of menarche
2. Pregnancies--number, complications and outcome
3. Age at menopause
IX. Family medical history
X. Occupational history (Especially including exposure to medically
important dusts and toxins.)
XIII. Social history
The disadvantage of trying to incorporate complete word processing
capabilities within QQ is that this would be re-inventing the wheel. Excellent
word processing software exists in abundance. The advantage is integrating
text with the clinical database.
As most clinics already use word processing software to transcribe dictation, a logical first capability is to translate or import these word processing files. This requires a translation program.
Similarly there are excellent hypertext programs available. "Embedding" such a program within QQ might be more effective than devising an entirely new one.
The main decisions for a word processing link are how many features to include, and what capabilities need to belong to QQ. A simple text editor would be enough for physician use, to revise progress notes. A medical dictionary would be a good feature (Steadman's word list was available in 1990 for $10,000).
The decision to include the actual text contents of the chart on line is a decision to purchase huge mass storage and is a commitment to organize that storage so that the data can be efficiently retrieved.
Another tack is to keep progress notes on-line until they are electronically "signed" and then to produce a permanent paper copy. (The chart!) QQ would provide an index to this permanent paper chart without duplicating it.
Some physicians want picklist creation of clinical notes. While this may seem attractive, there are several reasons that this would not be an acceptable general solution:
Several specific functions will be useful:
A terminal can be used for prompted questionnaires. The patient can be asked for many items of past medical history and personal information very easily, without staff or physician time. Some aspects of the chief complaint can be gathered, especially with an OCR touch screen. Much of the system review could also be easily completed at a terminal or on a touch screen. The Mayo Clinic has an optically-scanned patient personal history form.
A prompted questionnaire will speed data entry for the doctor and help ensure completeness. It can be used to "input" historical and physical findings, and to speed up entry of abnormalities, common abbreviations can be accepted and translated into the standard terminology.
The work of the transcriptionist and physician will be speeded by the use of boilerplate copy for repetitive descriptions, evaluations and recommendations, especially in letters to referring physicians, or in letters to patients.
For example, patients often want teaching about common laboratory abnormalities,
and standard paragraphs could be inserted about lipid abnormalities, mammogram
results, pap results, etc.
A convenient link to the accounts receivable software can be provided
within QQ by replacing the paper "charge ticket" (also called the routing
ticket or billing form) with a QQ menu. It's as easy for the doctor to
check off desired tests on screen as on a sheet of paper. The ordered tests
would then be printed in the lab or xray (for example), and technicians
could begin preparing to perform the tests even before the patient is brought
to the area.
The physician could code the service level as easily on screen as on paper, and the system should include parameters that check for major coding mistakes (e.g., failing to charge for an office visit, suture pack, or in-office emergency with laceration repair) and prompt for likely associated services (e.g., dip-tet immunization).
The physician could also use QQ to indicate when the patient should be recalled for the next visit, and whether any lab work should be done in the interim.
In addition, the physician could select the diagnoses for the visit from a ICD-9 master list. This should be done by refining a search on the diagnosis list as keystrokes are entered or characters recognized, and when the system offers the diagnosis, this is accepted with a stroke of the "enter" key or a confirmatory indication with the stylus on a touch screen.
By reading the accounts receivable record, QQ can list the patient's
previous diagnoses in a window, for the physician to select if pertinent
to the current visit.
Most good accounts receivable software has a scheduling module.
A link between such a module and QQ will permit the data of each doctor's
patients to be precompiled if necessary and downloaded to his terminals
or to a special file for immediate access during the day. Walk-ins could
then also be added to this file during the day.
Simple terminal emulation would permit the physician's assistant to
use the scheduler to arrange followup appointments and within-clinic referrals
without an intermediate step, a convenience to the patient.
Several medical databases are now available on CD-ROM, such as the
PDR, MedLine, and Scientific American Medicine.
It would not be difficult to provide a window to software accessing such medical information databases and permit the physician to save or print information as desired from them. Such searches could even be linked to keywords in the progress note or to keywords in the worksheet that the physician has created while using the touch screen.
It would also be easy (although in the long run more expensive) to simply permit the user to shell out to a communications program to dial up BRS, CompuServe, the National Library of Medicine, etc.
For the busy physician, access to clinical databases would be the sort of activity that would be relegated to lunch time and after hours.
Another very useful kind of database that QQ can provide is to permit building a clinic-specific or physician-specific database. For example, the surgeon may wish to keep track of all patients having specific procedures for recall personal QA, or for clinical research. The internist may wish to be able to find all patients having used a particular medication or having a particular allergy.
In addition, the ability to construct special clinical databases from
the medical record will be a powerful tool for clinic-based research in
primary care.
The essential requirement for an adequate medical record is well-organized
laboratory data. This requires that all lab results, from any source, be
entered into a comprehensive laboratory data base and a unified report
be placed in the chart.
Once this has been accomplished, then QQ can either copy the data for a particular patient to an electronic "chart" or can create an index to the lab database for access.
The optimal use of QQ, in its goal of presenting to the physician data that the physician would otherwise have to search the chart for, it is necessary to provide a link between laboratory data and medication use. That link will be most useful if it is disease-sensitive. This will require, at least, a series of lookup tables. Some of these tables are readily available: PDR and others make a medication interaction databases. Medical textbooks provide a ready source of lists of pertinent lab data for disease states, which can by converted to lookup tables by typists.
The main programming challenge, it would seem, would be to allow user modification of these tables, addition of new tables keyed to diseases, and addition of new medications and lab tests--all without reprogramming!
Acquiring Lab Data
The simplest way is to prompt the user to enter important information from the written record. All lab data need not be in QQ, but physicians could be reminded about important monitoring, with manual entry of values permitted for later recall or analysis. This could be entered by the physician or medical assistant during or after a visit.
However, as laboratory values normally form the most chaotic part of the office chart, assembling these values into organized data would itself aid the physician's information-gathering tasks.
There are two sources of lab data in a clinic: "outside" labs (those tests sent out) and the "inside" lab. In the "inside" lab, some tests are done manually or the results recorded manually; other tests are done by machines with serial ports.
The most efficient means of handling lab data is to create a master data base. "Outside lab" results are often transmitted via modem to a printer; this data stream can be just as readily printed to a file, then read into the master data base, with confirmation by an operator for accuracy. (The step of confirmation is tantamount to filing the lab slip in the paper chart.) Other lab results are received on paper ("hard copy"). These results must be typed into the data base at a console. With proper entry screen design, this should be faster than hand-filing the forms. (By "proper design" is meant two things: every test in the reference lab books should be included in an organized look-up table, and the lists tests in each battery or panel can be called up by the operator just by typing in the name of the reference lab and the name of the panel; and QQ searches for the test name as it's being typed in, so after a few characters the operator can just hit the "enter" key to skip to the result field. The normal (or therapeutic) range for each test will also pop up when the name is entered or accepted by the operator, to permit confirmation that the reference lab has not changed its technique. (If it has, this must be entered and a supervisor must decide whether to change the "default" normal value.)
It would be possible to scan written reports, but editing this scanned data would probably be more tedious than accurately typing it in. The gain in physician efficiency and accuracy that would accompany a well-organized laboratory record is well worth a moderate amount of hand entry.
Lab technicians typically write the results of bench tests at least twice: once when they perform the test, in a log, and then on a lab slip after verifying the result. Keyboard data entry would permit both a log and a report to be generated in one step.
Interface to Commercial labs
Because commercial labs are able to transmit ASCII text to their customers, it is important to capture this to disk and write it into the master data base in the same way as the clinic's own lab data, and reported on the same types of forms. Clearly, a field must be available to note the lab originating the test.
Machine interface and data formatting
Essentially all laboratory instruments for several years have included a serial port. Several companies make software to maintain a master laboratory data base. It should be possible simply to access the record maintained by such software rather than writing a program de novo for QQ. After all, QQ is a clinical information manager whose purpose is to provide executive organization of data specific to each patient.
This task can be done either by extracting the data from the master laboratory data base or by creating an index to it for each patient.
Unified reports
There are two types of unified reports that may be considered. Each represents an improvement in organization. The first is a single list of all the tests that have been performed for a patient on a single day. This is especially to the physician when reviewing the investigations performed during a single visit.
The second type of report is a master list or flow sheet of all the tests that have ever been performed for a patient. Some hospitals produce such a list encompassing the tests done for a single hospital admission. This could logically be extended to use in a clinic. What is required, obviously, is a large archive of all the lab results for all patients since Day One on the system.
What should the paper chart contain? Flow sheets of lab data, organized by type of test in the traditional way. The advantage of having a comprehensive lab data base is that only the latest page needs to be refreshed, only for each patient visit. Completed pages are not reprinted. Each time lab work is done, the results are added to the database, and the last (incomplete) page is reprinted, including any new data. The last incomplete page is thrown away when the new page is filed.
The daily lab list is printed for physician review, but need not be retained in the paper chart.
This strategy will keep the lab section of the chart organized at all times, making it less likely to overlook data and saving search time for the physician.
Because of the huge number of possible lab tests, this section would have to be subdivided into the usual lab categories .
Database contents for lab results: date obtained, date analyzed time
obtained, time analyzed name of test (T) [A code and a lookup table could
be used.] result of test (may be two or more numbers; e.g., protime, control,
ratio, per cent activity) normal range (therapeutic range) (T) units (T)
lab performing test (T) physician ordering test (T).
Powerful notebook-sized computers now available would permit a physician
to take an entire patient database to the hospital for rounds or while
on call. In the small-town emergency room, this would be a special boon
(although in the one-horse medical community, placing a terminal in the
ER for the doctor's use would accomplish more and at less expense).
The admission history and physical is best done with the patient's complete record available. Late at night or at other odd hours, the time or energy may be lacking to go to the clinic, track down the chart, copy from the chart important data, and return to hospital to finish the workup. Because of the expense in time (when too busy already) and personal energy (when already almost too tired to function), this is usually not done. Yet the patient's memory is often incomplete. Most omissions are not important; some are.
The elderly patient is especially likely to have an office record that is too complex to recall easily, a medication regimen that is too complex to reproduce without the list that was left at home, or intellectual deficits that make an accurate history problematic.
All in all, QQ will be especially useful if key elements of the database (recent outpatient encounters, medication history, and past medical and surgical history) are available to the physician in hospital, at all hours.
Important as this is for one's own patients, it is especially useful
when covering for one's colleagues.
Physicians who will be interested in the capabilities of QQ will
mainly be the meticulous sort, especially those with a lot of chronically
ill patients. These typically are internists (including medical subspecialists),
pediatricians, and academicians. Some surgeons will use the capabilities
of QQ to follow their own practice, summarizing the outcomes of various
surgical procedures in their practice, and for those complicated surgical
patients who require prolonged followup. The premier example of surgical
patients requiring prolonged followup are post-transplant patients. QQ
would be worthwhile for these patients alone!
QQ is useful either as a stand-alone or as a value-added product marketed with currently offered medical software packages, which are currently devoted to automation only of the accounts receivable side of the business--billing, scheduling, and analysis of this data.
A stand-alone version of QQ could offer terminal emulation to access data in the accounts receivable record. This could be customized to allow cut and paste or other importation techniques to be used to bring information into QQ to avoid duplication of effort.