|
Medical Patent Abstract
A system and method for providing computerized, knowledge-based
medical diagnostic and treatment advice. The medical advice is provided
to the general public over networks, such as a telephone network
or a computer network. The invention also includes a stand-alone
embodiment that may utilize occasional connectivity to a central
computer by use of a network, such as the Internet. New authoring
languages, interactive voice response and speech recognition are
used to enable expert and general practitioner knowledge to be encoded
for access by the public. "Meta" functions for time-density
analysis of a number of factors regarding the number of medical
complaints per unit of time are an integral part of the system.
A re-enter feature monitors the user's changing condition over time.
A symptom severity analysis helps to respond to the changing conditions.
System sensitivity factors may be changed at a global level or other
levels to adjust the system advice as necessary.
Medical Patent Claims
What is claimed is:
1. A medical diagnostic system comprising: a computing environment
arranged to receive patient information, comprising a server computer
connected to a communications network; a client processor connected
to the network and in data communication with the server computer
via the network; an input device, connected to the client, to receive
patient information; an output device, connected to the client,
to provide information indicative of a diagnosed medical condition,
wherein the environment executes a program for diagnosing by scoring
a medical condition based on the patient information and communicating
the diagnosed medical condition via the output device, and wherein
the program comprises at least one medical diagnostic code portion
selectively executed based on at least a portion of the received
information, wherein the medical diagnostic code portion scores
at least a portion of the received information and diagnoses a medical
condition associated with the executed medical diagnostic code portion
if the score reaches or passes a threshold; and wherein the program
is arranged to read data from, and write data to, a medical history
file stored in association with the client processor or the server
computer, and wherein the scoring by the medical diagnostic code
portion is affected by the data read from the medical history file.
2. The system defined in claim 1 wherein information transferred
between the client processor and the server computer is securely
transmitted.
3. The system defined in claim 1 wherein data communication between
the server computer and the client processor is intermittent.
4. A computerized system for providing information to any one of
a plurality of patients by communicating information over a computer
network, the system comprising: means for selectively executing
at least one medical software code portion; means for accessing
a patient medical history during an evaluation process, wherein
each patient is associated with at least one record containing medical
information unique to the medical condition of the patient, and
wherein the patient medical history is persistently stored in the
at least one record; means for determining medical advice particular
to a medical condition associated with the medical software code
portion through communication over the computer network with a selected
one of the patients and with information stored in the patient medical
history; and means for providing the medical advice to the selected
patient, wherein the medical advice is stored in a patient consultation
summary.
5. The system defined in claim 4 wherein a physician accesses and
uses the patient consultation summary to make a diagnosis.
6. A computerized system for determining medical advice for any
one of a plurality of patients by communicating information over
a computer network, the system comprising: means for selectively
executing at least one medical software code portion; means for
accessing a patient medical history during an evaluation process,
wherein each patient is associated with at least one record containing
medical information unique to the medical condition of the patient,
and wherein the patient medical history is persistently stored in
the at least one record; and means for determining medical advice
particular to a medical condition associated with the medical software
code portion through communication over the computer network with
a selected one of the patients and with information stored in the
patient medical history, wherein the medical advice is stored in
a patient consultation summary.
7. The system defined in claim 6, wherein a physician accesses
and uses the patient consultation summary to make a diagnosis.
8. The system defined in claim 6, additionally comprising means
for providing the medical advice to the selected patient.
Medical Patent Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to medical knowledge systems and,
more particularly, to systems for giving medical advice to the general
public over networks.
2. Description of the Related Technology
Health care costs currently represent 14% of the United States
Gross National Product and are rising faster than any other component
of the Consumer Price Index. Moreover, usually because of an inability
to pay for medical services, many people are deprived of access
to even the most basic medical care and information.
Many people delay in obtaining, or are prevented from seeking,
medical attention because of cost, time constraints, or inconvenience.
If the public had universal, unrestricted and easy access to medical
information, many diseases could be prevented. Likewise, the early
detection and treatment of numerous diseases could keep many patients
from reaching the advanced stages of illness, the treatment of which
is a significant part of the financial burden attributed to our
nation's health care system. It is obvious that the United States
is facing health-related issues of enormous proportions and that
present solutions are not robust.
One prior attempt at a solution to the health care problem is called
Ask-A-Nurse, wherein a group of nurses provide health information
by telephone around-the-clock. A person with a medical problem calls
an 800 number and describes the problem to the nurse. The nurse
uses a computer for general or diagnostic information on the ailment
or complaint mentioned by the caller. The nurse may then refer the
caller to a doctor from a computerized referral list for a contracting
hospital or group of hospitals. Client hospitals contract with Ask-A-Nurse
to provide patient referrals. A managed care option called Personal
Health Advisor is similar and adds the capability for the caller
to hear prerecorded messages on health topics 24 hours a day. Several
problems exist with these prior medical advice systems. First, these
systems have high costs associated with having a nurse answer each
telephone call. Second, the caller may have to belong to a participating
health plan to utilize the service. Third, if for some reason all
nurses on a particular shift happen to be busy and the caller has
an emergency condition (that is not known by the caller to be an
emergency), precious time in getting emergency services may be lost
during the delay.
Another prior health system was developed by InterPractice Systems
which provides a computerized service that answers health care questions
and advises people in their homes. A health maintenance organization
(HMO) may provide this service to its members in a particular geographic
area. To get advice at home, an HMO member connects a toaster-sized
box to a telephone and calls a toll-free 800 number. Using a keyboard
that is part of the box, the user answers questions displayed on
a screen of the box relating to the user's symptoms. Depending on
the answers, the user might be told to try a home remedy, be called
by a nurse or doctor, or be given an appointment to be examined.
A limitation of this system is the additional expense of the electronics
box, which could either be purchased by the user for approximately
$300 or purchased by the health organization with the expense to
be passed on to the users. Another limitation is that this service
is directed to members of a particular contracting health organization,
such as an HMO. What is desired is a system that does not require
additional hardware for the basic service, but that utilizes the
existing communication network. The desired system should be available
for use by any person, not just members of a certain organization.
A prior attempt at a health care solution for a limited set of
conditions is described in U.S. Pat. No. 4,712,562. A patient's
blood pressure and heart rate are measured and the measurements
are sent via telephone to a remote central computer for storage
and analysis. Reports are generated for submission to a physician
or the patient. U.S. Pat. No. 4,531,527 describes a similar system,
wherein the receiving office unit automatically communicates with
the physician under predetermined emergency circumstances.
U.S. Pat. No. 4,838,275 discloses a device for a patient to lay
on or sit in having electronics to measure multiple parameters related
to a patient's health. These parameters are electronically transmitted
to a central surveillance and control office where a highly trained
observer interacts with the patient. The observer conducts routine
diagnostic sessions except when an emergency is noted or from a
patient-initiated communication. The observer determines if a nonroutine
therapeutic response is required, and if so facilitates such a response.
As previously mentioned, highly trained people are needed by this
system along with the special measurement apparatus (embedded in
a bed or chair).
Other prior attempts at a health care solution are typified by
U.S. Pat. No. 5,012,411 which describes a portable self-contained
apparatus for measuring, storing and transmitting detected physiological
information to a remote location over a communication system. The
information is evaluated by a physician or other health professional.
As before, highly trained people are necessary to utilize such an
apparatus.
Several services to provide medical or pharmaceutical advice are
now available via "1-900" telephone numbers, e.g., "Doctors
by Phone." These services are available 24 hours a day and
7 days a week. A group of doctors, including some specialties, is
available to answer questions about health care or medical conditions
for people anywhere in the United States who call the "1-900"
telephone of one of the services. A group of registered pharmacists
answers questions about medications for the "1-900" pharmaceutical
service.
SUMMARY OF THE INVENTION
The present solution to the health care problem is a computerized
medical diagnostic and treatment advice (MDATA) system that is a
medical knowledge-based system designed to give medical advice to
the general public over the telephone network. The goal of the MDATA
system is to provide everyone with equal access to high quality,
100%-consistent medical advice at a reasonable cost. The MDATA system
provides callers with extremely fast and virtually unlimited access
to health care information, twenty-four hours a day, from any location
around the world. Health care advice is made available to an entire
spectrum of users, from elderly patients confined to their homes
to travelers in a foreign country with telephones in their cars.
The central ideas leading to the development of the MDATA system
are based on the following assumptions: Nearly 90% of all patient
complaints are confined to approximately 100 medical problems. Almost
all primary care decisions involved in these 100 problems can be
made based upon information learned solely by obtaining a detailed
medical history. The results of the physical examination, laboratory,
and imaging studies only tend to confirm a diagnosis. The minimal
amount of information that many doctors believe can only be obtained
from the physical examination can actually be directly acquired
from the patient when given appropriate instructions. In most cases,
a face-to-face interaction between the doctor and patient is not
necessary. A detailed and well-constructed history, along with physical
findings elicited from the patient, can be obtained over the telephone.
Medicine is basically diagnosis and treatment. Although treatment
recommendations change frequently, the fundamental principles of
making the diagnosis do not. There is a significant delay between
the time a new therapy is recognized as safe and effective and the
time physicians are able to provide it to their patients.
These central ideas are utilized in the implementation of the MDATA
system.
A goal of the MDATA system is to give better medical advice than
a family practitioner who is unfamiliar with a patient, e.g., an
on-call physician. A person seeking medical advice frequently will
not be able to see or speak with his or her personal physician in
a timely manner. The MDATA system provides medical advice whenever
desired by the caller--seven days a week/24 hours a day.
All previous medical algorithms, including those used in the military,
are designed for face-to-face interactions. Self-help books generally
do not consider age and sex in their algorithms. Furthermore, a
book cannot take into account how many times a person has consulted
the same algorithm within a short period of time for the same problem.
The medical algorithms used by the MDATA system are designed for
use in a telecommunications setting and overcome the deficiencies
of self-help books.
Previous medical advice systems do not do a time-density analysis
for a number of factors with regard to the number of complaints
per unit of time. The MDATA system uses "meta" functions
to perform these analyses.
Previous medical advice algorithms do not have a way of detecting
the consciousness level of the person seeking consultation. The
MDATA system invokes a "mental status examination" whenever
a complaint or problem has the possibility of an altered level of
consciousness. In addition, the MDATA system uses "semantic
discrepancy evaluator loops" which allow the system to invoke
the mental status exam if there are differences in answers to the
parallel threads of thought that are woven or embedded into the
system.
Other medical advice systems do not have a "re-enter"
feature to monitor a patient's progress or worsening over time.
The MDATA system checks for and responds to changing conditions
over time.
Prior medical advice systems suffer from the inability to be nearly
instantly up-dated as new medical information is made available.
The MDATA system regularly and frequently updates the treatment
aspect of the system.
The computerized medical diagnostic and treatment advice (MDATA)
system is a medical knowledge-based system designed to give medical
advice to the general public over the telephone network. Using a
new authoring language, interactive voice response and speech recognition
technology, the MDATA system encodes a highly useful core of expert
and general practitioner diagnostic and treatment knowledge into
a computerized system for access by non-medically trained personnel.
The MDATA system does not provide advice for every medical problem,
nor does it make an exhaustive study of one vertical cross-section
of medicine. Instead, the MDATA system provides up-to-date medical
advice for approximately one hundred of the most commonly encountered
problems in general practice and emergency medicine. It also provides
valuable information to the public on any number of other medical
topics.
As another embodiment of the MDATA system, a person desiring medical
advice and having access to a personal computer (PC) loads a program
into the PC to produce a stand-alone medical diagnostic and treatment
advice (SA-MDATA) system. Rather than listening to questions and
responding via touch tone keypresses or via voice, the user responds
to questions and directions displayed on the computer screen via
a computer input device, such as a keyboard or mouse. The diagnosis
and/or treatment recommendations provided by the MDATA system are
the same as that provided by the SA-MDATA system. The user of the
SA-MDATA system can procure updates by contacting the MDATA system
sponsor/administrator to obtain the most current treatment table
information for a particular diagnosis.
Yet another embodiment of the MDATA system utilizes communication
networks, such as the Internet, to connect a user or patient with
the MDATA computer. The user utilizes a network access processor
or computer to access the network. This embodiment utilizes medical
diagnostic scripts executed on a script engine to generate medical
advice or a diagnosis. The scripts and script engine may be executed
on the MDATA computer in a manner similar to the telephonic embodiment
above. Alternatively, selected portions of the MDATA software and
one or more scripts may be downloaded to the user's computer for
execution. The MDATA computer may download additional or newer scripts
to the user's computer over the network as necessary.
One aspect of the invention is a medical diagnostic system comprising
a computing environment arranged to receive patient information,
comprising a server computer connected to a communications network;
a client processor connected to the network and in data communication
with the server computer via the network; an input device, connected
to the client, to receive patient information; an output device,
connected to the client, to provide information indicative of a
diagnosed medical condition, wherein the environment executes a
program for diagnosing by scoring a medical condition based on the
patient information and communicating the diagnosed medical condition
via the output device, and wherein the program comprises at least
one medical diagnostic code portion selectively executed based on
at least a portion of the received information, wherein the medical
diagnostic code portion scores at least a portion of the received
information and diagnoses a medical condition associated with the
executed medical diagnostic code portion if the score reaches or
passes a threshold; and wherein the program is arranged to read
data from, and write data to, a medical history file stored in association
with the client processor or the server computer, and wherein the
scoring by the medical diagnostic code portion is affected by the
data read from the medical history file.
The system may also have information transferred between the client
processor and the server computer being securely transmitted.
The system may also have data communication between the server
computer and the client processor being intermittent.
Another aspect of the invention is a computerized system for providing
information to any one of a plurality of patients by communicating
information over a computer network, the system comprising means
for selectively executing at least one medical software code portion;
means for accessing a patient medical history during an evaluation
process, wherein each patient is associated with at least one record
containing medical information unique to the medical condition of
the patient, and wherein the patient medical history is persistently
stored in the at least one record; means for determining medical
advice particular to a medical condition associated with the medical
software code portion through communication over the computer network
with a selected one of the patients and with information stored
in the patient medical history; and means for providing the medical
advice to the selected patient, wherein the medical advice is stored
in a patient consultation summary.
The system may also be such that a physician accesses and uses
the patient consultation summary to make a diagnosis.
Yet another aspect of the invention is a computerized system for
determining medical advice for any one of a plurality of patients
by communicating information over a computer network, the system
comprising: means for selectively executing at least one medical
software code portion; means for accessing a patient medical history
during an evaluation process, wherein each patient is associated
with at least one record containing medical information unique to
the medical condition of the patient, and wherein the patient medical
history is persistently stored in the at least one record; and means
for determining medical advice particular to a medical condition
associated with the medical software code portion through communication
over the computer network with a selected one of the patients and
with information stored in the patient medical history, wherein
the medical advice is stored in a patient consultation summary.
The system may also be such that a physician accesses and uses
the patient consultation summary to make a diagnosis.
The system may additionally have means for providing the medical
advice to the selected patient.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating the components of a presently
preferred embodiment of the computerized medical diagnostic and
treatment advice (MDATA) system of the present invention;
FIG. 2 is a diagram of the off-line process used in producing the
speech files shown in FIG. 1;
FIG. 3 is a diagram of the Node Translation process used in creating
files for use by the system of FIG. 1;
FIG. 4 is a diagram of some of the files and components of FIGS.
1 and 3 that are utilized at run time;
FIG. 5a is a diagram of the utilization of the files shown in FIG.
3 at run time;
FIGS. 5b-5g are an exemplary sequence of data structures of the
system shown in FIG. 1 at run time;
FIG. 6 is a block diagram illustrating a conceptual view of the
database files and processes of the system of FIG. 1;
FIGS. 7a, 7b, 7c and 7d are a top-level flow diagram of the MDATA
system of FIG. 1;
FIGS. 8a and 8b are a flow diagram of the patient login process
250 defined in FIG. 7a;
FIGS. 9a and 9b are a flow diagram of the patient registration
process 252 defined in FIG. 7a;
FIGS. 10a and 10b are a flow diagram of the evaluation process
254 defined in FIG. 7d;
FIGS. 11a and 11b are a flow diagram of the meta function 500 defined
in FIG. 10b;
FIGS. 12a and 12b are a flow diagram of the assistant login process
272 defined in FIG. 7b;
FIGS. 13a and 13b are a flow diagram of the assisted patient login
process 276 defined in FIG. 7b;
FIGS. 14a and 14b are a flow diagram of the assistant registration
process 274 defined in FIG. 7b;
FIGS. 15a and 15b are a flow diagram of the assisted patient registration
process 278 defined in FIG. 7b;
FIGS. 16a and 16b are a flow diagram of the mental status examination
function 508 defined in FIG. 10b;
FIG. 17 is a flow diagram of the semantic discrepancy evaluator
routine (SDER) 510 defined in FIG. 10b;
FIG. 18 is a flow diagram of the past medical history routine 512
defined in FIG. 10b;
FIG. 19 is a flow diagram of the physical self examination function
514 defined in FIG. 10b;
FIG. 20 is a flow diagram of the patient medical condition routine
516 defined in FIG. 10b;
FIG. 21 is a flow diagram of the symptom severity analysis function
518 defined in FIG. 10b;
FIG. 22 is a flow diagram of the treatment table process 256 defined
in FIG. 7d;
FIG. 23 is a flow diagram of the menu-driven treatment selection
process 864 defined in FIG. 22;
FIG. 24 is a high-level block diagram of a network-based embodiment
of the MDATA system that utilizes communication networks;
FIG. 25a is a block diagram illustrating the components of a presently
preferred network-based embodiment of the computerized MDATA system
of the present invention;
FIG. 25b is a block diagram illustrating the components of a user
computer in the network-based embodiment of the computerized MDATA
system;
FIG. 26 is a block diagram illustrating a conceptual view of the
database files and processes of the system of FIGS. 25a and 25b;
FIG. 27 is a diagram of an off-line process used in producing the
medical diagnosis script (MDS) files used by the system of FIGS.
25a and 25b;
FIG. 28 is a diagram of some of the files and components of FIGS.
25a, 25b, 26, and 27 that are utilized at run-time;
FIG. 29 is a flow diagram showing the interaction of the MDATA
computer with the patient's computer via the network of FIG. 25a;
FIG. 30 is a block diagram showing the interaction of the MDATA
computer with the patient's computer via the Internet;
FIG. 31 is a flow diagram of a network program and data transfer
process that is used during execution of the Initial script (similar
to the process shown in FIGS. 7a-7d) and the Evaluation process
shown in FIGS. 10a-10b;
FIG. 32 is a flow diagram showing an excerpt of a network data
transfer process performed during execution of the Initial script
(similar to the process shown in FIGS. 7a-7d) and the Evaluation
process shown in FIGS. 10a-10b; and
FIG. 33 is an exemplary graphical user interface screen generated
during a script that may diagnose Malaria.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The following detailed description of the preferred embodiments
presents a description of certain specific embodiments to assist
in understanding the claims. However, the present invention can
be embodied in a multitude of different ways as defined and covered
by the claims.
For convenience, the following description will be outlined into
the following principal sections: Introduction, System Overview,
Operating Features of the MDATA System, Authoring Language, Run-Time
Operation, Software Structure, Top-Level Flow, Login Process, Registration
Process, Evaluation Process, The Meta Function, Mental Status Examination,
Semantic Discrepancy Evaluator Routine, Past Medical History Routine,
Physical Self Examination, Symptom Severity Analysis, Treatment
Table, The MDATA System Paradigm, Video Imaging, Benefits of the
MDATA System, First Optional System Configuration, Summary of Advantages
of the Present Invention, and Second Optional System Configuration.
I. Introduction
A consultation for a person seeking medical advice begins with
a telephone call to the medical diagnostic and treatment advice
(MDATA) system of the present invention. The MDATA system asks the
caller specific questions and then analyzes each response.
Voice recognition and interactive voice response technology allow
callers to respond to yes/no and multiple choice questions either
by speaking directly into the telephone or by using the touch tone
pad of their telephone.
Easy access to the information in the MDATA system is made possible
by a natural user interface. The computer-driven dialogue consists
of simple yes/no and multiple choice questions. The questions and
treatment recommendations are very simply worded yet skillfully
designed to reflect the accumulated experience of many physicians
in conducting patient interviews.
Although all the MDATA system's questions are designed to be easily
understood, unforeseen situations will inevitably arise. For this
reason, hierarchical staffing is implemented. As an example, for
every 10 telephone lines, one operator fully trained in triage and
the MDATA system will be available. For every 10 operators there
will be one registered nurse in attendance; and for every 10 registered
nurses, there will be one physician in attendance. Staffing requirements
are adjusted as the system is refined toward optimal efficiency.
The MDATA system does not require the operator or the registered
nurse to make any medical decisions.
II. System Overview
Referring to FIG. 1, the components of a presently preferred embodiment
of the computerized medical diagnostic and treatment advice (MDATA)
system 100 of the present invention are shown. A personal computer
(PC) 102 includes a plurality of components within an enclosure
104. A plurality of telephone lines 106 interface the public telephone
network 108 to the computer 102. As an example, one of telephone
lines 106 is shown to be switched via network 108 to connect with
a telephone 110 that is used by a person desiring medical advice
(user) 112. Throughout this document, the words user, caller and
patient are used interchangeably. However, it will be understood
that the caller may be acting as a proxy for the patient. If this
is the case, the caller will be registered as an assistant for the
patient.
The hardware and system software were assembled with two basic
concepts in mind: portability to other operating systems and the
use of industry standard components. In this way, the system can
be more flexible and will allow free market competition to continuously
improve the product, while, at the same time, decrease costs. While
specific hardware and software will be referenced, it will be understood
that a panoply of different components could be used in the present
system.
The system currently runs on the PC 102 with an Intel 80486 microprocessor.
"Telephony" functions use Dialogic Corporation's D/41D
voice processing board 122 based on a digital signal processor (DSP).
The voice processing (VP) board 122 performs several functions including
interfacing the telephone lines, decoding touch tone signals, speech
recording and speech playback. Touch tone signals are also known
as "dual tone multiple frequency" (DTMF) signals. A group
of one to four telephone lines 106 connect to the VP board 122.
The computer 102 may include a plurality of VP boards 122 based
on how many phone line connections are desired for the system 100.
Speech recognition is achieved using Voice Processing Corporation's
speech recognition VPRO-4 board 124 (also DSP based). The voice
recognition (VR) board 124 performs several functions including
recognizing utterances and returning an index number of a recognition
confidence level. The VR board 124 and the VP board 122 both connect
to an industry standard architecture (ISA) bus 126. The ISA bus
126 interconnects the microprocessor 120 with a plurality of peripherals
through controller circuits (chips or boards).
The VP board 122 also connects to a VPRO-Adapt board 128 via an
analog audio bus 130 that is called Analog Extension Bus. Four simultaneous
channels provide a 96 kbit/second data transfer rate. Each channel
corresponds to a telephone line connected to the VP board 122 and
is associated with a current patient consultation. The Adapt board
128 further connects to a digital audio bus 132. The VR board 124
also connects to the digital audio bus 132. The Adapt board 128
performs analog to digital signal conversion to a VPC-proprietary
digital pulse code modulation (PCM) format. The digital bus 132
can accommodate 32 channels and has a data transfer rate of 2.048
Mbits/second.
The computer ISA bus 126 has a plurality of peripherals connected
to it through adapters or controllers. A video adapter board 136,
preferably at VGA or better resolution, interconnects to a video
monitor 138. A serial communication circuit 140 interfaces a pointing
device, such as a mouse 142. A parallel communication circuit may
be used in place of circuit 140 in another embodiment. A keyboard
controller circuit 144 interfaces a keyboard 146. A small computer
systems interface (SCSI) adapter, such as model 1542C made by Adaptec,
provides a SCSI bus 150 to which a 500 Mb or greater hard disk drive
152 and dual Bernoulli 150 Mb disk drives are preferably attached.
The hard drive 152 stores database files such as the patient files,
speech files, and binary support files.
A main memory 156 connects to the microprocessor 120. In the presently
preferred embodiment, the MDATA system 100 operates under DOS version
5.0 operating system 158. The system software is written in Microsoft
C\C++ version 7.0 using structured programming techniques. An algorithm
processor 160 includes a parser and supporting functions that manipulate
a memory variable symbol table and a run time stack, which will
be described hereinbelow. Sequiter Software Inc. Codebase 5.0 allows
access to X-base compatible database records stored on the hard
drive 152. The MDATA system 100 also includes two new authoring
languages (one each is used in two embodiments of the system), which
will be discussed hereinbelow.
The system software includes the following code modules for which
source code is included in the attached Microfiche Appendix: A.
main.c--a collection of functions that mostly deal with telephony
functions, such as answering the phone line, speech file playback,
and DTMF tone collection. Global data structures are defined here.
B. base.c--functions that invoke the CodeBase revision 5.0 library
to perform xbase file manipulation. C. pars.c--the parse function,
and supporting functions that manipulate the memory variable symbol
table and run time stack. D. regi.c--an on-line patient registration
module. E. resp.c--gets the caller's responses, either DTMF or voice,
and figures out what to do next by obeying a command (e.g., "repeat"
or "backup"), or traversing through the algorithm node
map. F. term.c--a useful collection of text phrases for Dialogic
and VPC board termination events and error codes. G. user.c--"non-diagnostic"
portions of the caller session: initial screening questions, caller
login, and the next node playback initiator. H. util.c--a collection
of general purpose functions shared by a run time executable, a
node editor and ASCII translator tools. I. view.c--a module that
controls the graphics system display. J. x10.c--an X-10 computer
interface routine for fault recovery. K. xlat.c--a module linked
with pars.c and util.c object modules to build xlat.exe, a stand-alone
translation executable for offline ASCII text file translation.
The application is compiled with the Microsoft graphics, Dialogic
board, VPC board and CodeBase database libraries.
The Voice Processing Corporation (VPC) VPro-4 VR board has eight
voice recognition channels, which by default are associated one-to-one
with the Dialogic D/41D channels. VPC's pioneering work in the voice
processing field is in the area of continuous speech. This allows
a person to speak a multiple digit number in a natural manner, without
pausing after each digit. VPC supplies two continuous speech vocabularies:
one vocabulary contains the digits 1 through 9, plus "zero"
and "oh", and the other contains just the two words "yes"
and "no". The vendor-supplied digits continuous speech
vocabulary is used by the system 100. In the presently preferred
embodiment, if the score is 75% or better, the response is unconditionally
accepted. If the score is between 20% and 74%, the digits recognized
are read back, and the caller is asked to accept or reject the digits.
In another embodiment of the system 100, the above score thresholds
are implemented as tunable parameters. The scoring parameters are
stored in a configuration file that is manipulated off-line by a
utility program and is read by the run-time system at initialization.
VPC also provides a few discrete vocabularies. Discrete vocabularies
contain one or two word utterances. The vendor-supplied discrete
speech vocabulary of the months of the year is used in the on-line
patient registration process. A speaker-independent discrete speech
vocabulary consisting of the words "yes", "no",
"backup", "continue", "help", "operator",
"pause", "quit" and "repeat" has been
developed using a very powerful set of utilities supplied by VPC,
Scripter and Trainer. These utilities are for collecting samples
and training the vocabulary.
The VR board 124 has the minimum of two MB memory installed. The
default memory configuration has a partition for both continuous
vocabularies and a partition for one discrete vocabulary. Additional
discrete vocabularies may be downloaded if the on-board memory is
reconfigured.
The VR board 124 has four digital signal processors (DSP's) from
which VPC derived eight voice recognition channels. Each of these
eight recognition resources is referred to as a VPro Speech Processor
(VSP). Discrete vocabulary recognition requires one VSP; continuous
vocabulary recognition requires two adjacent VSP's. The MDATA system
100 has a VSP resource manager in the resp.c software module. This
resource manager allocates VSP's in a dynamic manner to VP board
122 channels on a demand basis. As soon as the system receives a
response, voice or DTMF, it releases the VSP's associated with the
caller's VP board 122 channel.
The MDATA system 100 uses VPC's application programming interface
(API) for the C programming language. This makes the application
vendor specific to VPC, but also allows the system 100 to utilize
all the powerful API features, e.g., on-line creation of discrete
speaker dependent vocabularies used for voice pattern matching or
voice printing.
The VPC API supports both continuous speech vocabulary (CSV) and
discrete speech vocabulary (DSV) recognition.
The voice processing (VP) board 122 supports speech recording and
playback, as well as touch tone (DTMF) signal detection and decoding.
A device driver, associated with the VP board 122, is loaded into
system memory during load operations. The device driver supports
communications between the VP board 122 and the application code
at run time (e.g., when a person is seeking medical advice). Through
a shared memory segment, the device driver sends event and status
data to the application code in real-time as events occur on the
associated telephone line. These events include the ring of an incoming
call, touch tone key pressed by the caller, and the hang-up signal.
The VP board 122 plays back speech messages that are stored on the
hard drive 152. The algorithm processor 160 sends a selected speech
file having an encoded speech message that is retrieved from the
hard drive 152 to the VP board 122 at the appropriate time for speech
message playback. A speech message can be of variable length with
a typical message about one to two minutes in length. Several speech
messages may be chained together to produce an extended spoken message,
e.g., giving instructions to the patient. During speech file playback,
the VP board 122 is monitoring touch tone response from the caller.
The VP board 122 may be configured to interrupt speech file playback
when a touch tone signal is detected.
System Operating Contexts The system has an activity flag in the
port status block for each patient currently using the system to
keep track of which state the associated VP board channel is in:
a. Idle Mode--an idle channel waiting for a telephone call; b. Login
Mode--a condition where a patient is in the login process; c. Registration
Mode--a condition where a patient is in the registration process;
d. Real Mode--a condition where a patient is consulting for an actual
medical problem; e. Info (Information) Mode--a condition where a
patient is consulting for information or a hypothetical situation;
f. Pause Mode--a patient-initiated pause condition; g. Pending Mode--similar
to Real mode except that new medical information gathered for a
patient is not automatically added to the patient's medical record,
but rather written to a "Pending" file where it will be
verified off-line by a staff person.
Voice Keywords and DTMF Command Keys The system is responsive to
the following voice keywords and DTMF keys when it is in a prompting
state, i.e., not in response to a menu message:
TABLE-US-00001 Voice DTMF yes 1 Useful for answering yes/no questions.
no 2 backup # Causes the system to back up to the "predecessor"
message (see below), then resume playback. help * Plays helpful
information: either the node's help message list, or the DTMF command
explanation message. operator 0 Causes the system to transfer the
caller to a live person. pause 7 Transitions to pause mode. The
system default pause period is 30 seconds. quit 9 Quits the current
algorithm, and takes the caller to node 110, which asks the caller
if (s)he wishes to select another algorithm. repeat 3 Repeats the
current node's play message list. If this command is given in the
middle of a long play list, then playback restarts with the first
message in the list.
Pause Mode Commands
TABLE-US-00002 yes 1 Extends the pause period by one default pause
interval (30 seconds). continue 2 Ends pause mode. If this occurs
at a Yes/No node, the system will repeat the question. If this occurs
at a Link node, the system will resume playback with the "current"
message. The system resolves the DTMF digit "2" ambiguity,
"no" versus "continue", by examining the pause
mode flag.
FIG. 2 illustrates how speech files are created. A person programming
medical algorithms uses speech messages to communicate with the
person seeking medical advice. As previously mentioned, these speech
messages are of variable length. The programmer typically writes
a script for the speech message. Then using the handset of the telephone
110, a speakerphone feature, or other voice-input device, e.g.,
a microphone, the programmer reads the script into the voice-input
device which is connected to the VP board 122. The VP board converts
the speech into a digital format and records the digitized speech
to a file that is stored on the hard drive 152. In the presently
preferred embodiment, a subdirectory named vox contains the system
speech files, and subdirectories for each medical algorithm. System
speech files are of the form sysxxx, where xxx is some arbitrarily
assigned number. The system messages are used by the "fixed"
parts of the system, e.g., greeting, login process, registration
process. There are a few speech files of the form msgxxx. These
are the past medical history questionnaire messages, and response
acknowledgements. There are additional speech files of the form
msgxxxx in each of algorithm subdirectories, where xxxx generally
matches the node number, which will be explained hereinbelow. Node
messages include information, question, menu and help messages.
III. Operating Features of the MDATA System
One of the MDATA system's main objectives is to bring together
highly-qualified medical experts, encode their knowledge in a central
location, and make it available to everyone. A new and unique authoring
language is used by the MDATA system to help accomplish this objective.
Each day, specialists perform the same tasks over and over. They
enact the same diagnostic ritual of solving a familiar problem.
At the same time, however, primary care physicians attempt to find
the best path through the diagnostic maze of an unfamiliar problem.
This process is inefficient and fraught with error.
In medicine, there is generally one best way to do things. Instead
of physicians spending valuable time duplicating tasks, the MDATA
system utilizes medical experts from each medical specialty who
write detailed algorithms for the treatment of the 100 or so most
commonly encountered complaints in family practice and emergency
medicine. These algorithms are carefully and specifically designed
to elicit historical data and physical findings over the telephone,
rather than in face-to-face interactions.
Several experts could work together to thoroughly research one
particular complaint as well as to anticipate the full spectrum
of possible problems and patient responses. These experts could
also provide and maintain the MDATA system treatment table as well
as the imaging modality of choice and laboratory test of choice
tables. These concepts will be described hereinbelow.
Carefully crafted questions, used in the taking of a medical history,
are the main tools that the MDATA system uses to assess the problems
of patients. The key to getting a good history is to ask the right
questions. In a sense, in the diagnostic process questions are like
tests. It is important to note that the right questions are basically
always right; they don't change. Although they may be refined over
time, in general, once excellent and well-crafted questions are
developed they are good for a very long time. Of course, as new
diseases are discovered, e.g., toxic shock syndrome and AIDS, new
sets of diagnostic questions are developed that are disease specific.
The questions used by an earlier generation of physicians, who
did not have any of the latest imaging modalities (types or methods),
are far more sensitive and precise in diagnosing a patient's problem
than the questions used by doctors today. The MDATA system makes
use of fine nuances of language to diagnose patients as well as
to determine when certain tests or imaging studies are necessary.
The MDATA system's statistic generating capabilities enable the
system to analyze the effectiveness of the questions used in the
diagnostic process. As a result, physicians benefit from the immense
amount of statistical information that is gathered regarding the
wording of questions asked in taking medical histories. For example,
exactly what percentage of patients who answer "yes" to
the question, "Is this the worst headache of your life?"
actually have a subarachnoid hemorrhage? Although this is a classic
description of this problem, the exact probability of having this
kind of brain hemorrhage after answering "yes" to this
question is not presently known.
Currently, doctors can only estimate the probability of certain
conditions based on history. By applying the statistical information
that is generated, the MDATA system not only provides the patient
with advice that is continually improving, but it will also be able
to pass along these probabilities to the entire medical community.
To function optimally, the MDATA system tries to gain as much medical
information about its patients as possible. Although a first-time
caller is given excellent advice, more specific advice can be given
if the system has more information. Therefore, the MDATA system
asks patients for their complete medical history. The MDATA system
can either obtain the patient's medical record over the telephone
or it can mail or fax a detailed questionnaire to each patient.
The patient can then gather the necessary information at their convenience.
The MDATA system will always be available by telephone to clarify
any questions the patient may have.
The MDATA system uses the "International Classification of
Diseases" (ICD-9-CM) codes to help summarize the information
it has about a patient. This world standard is a comprehensive numerical
system used to classify the entire spectrum of medical diseases.
ICD-9-CM codes are also used to classify specific procedures performed
(e.g., appendectomy) as well as the morphology of neoplasm (i.e.,
tissue diagnosis of a cancer).
In addition, the MDATA system 100 uses ICD-9-CM "E-Codes"
to classify environmental events, circumstances, and conditions
as the cause of injury, poisoning, and other adverse effects. These
codes are particularly helpful for storing information about what
drugs the patient has taken or is currently taking, as well as the
context (e.g., therapeutic use, accident, poisoning, suicide attempt)
in which they were or are being taken. For example, E942.1 is the
code for the therapeutic use of digoxin. Medications are also cross-categorized
according to the classification done by the American Hospital Formulary
Service List (AHFS) Numbers. The MDATA system 100 also uses "V-Codes"
to classify other types of circumstances or events such as vaccinations,
potential health hazards related to personal and family history,
and exposure to toxic chemicals.
It is estimated that the alphanumeric component of a patient's
medical history will not exceed 1,000 atoms or pieces of information.
An atom is considered herein to be a separate identifiable data
item or point. With this assumption, the medical records of every
person on the planet could currently be stored on approximately
1,000 optical disks.
While a patient interacts with the MDATA system, the system is
constantly determining what questions to ask, based upon the information
it has about the patient. Just as a physician gathers relevant pieces
of information from his or her dialogue with a patient, the MDATA
system flags and later stores all pertinent pieces of information
that it learns from each interaction with its patient. Therefore,
certain questions, because their answers remain the same, need not
be repeated. For example, if the MDATA system learns that a patient's
mother has suffered from migraine headaches, it will never have
to ask for this information again.
Again, the more information the MDATA system has about a patient,
the more specific is its advice. It is not uncommon for the MDATA
system to give different advice to different patients calling for
the same complaint. In other words, the advice given is patient-specific.
Not only can the MDATA system's advice be different for different
patients, but there are times when the advice given to the same
patient (calling for the same complaint but at different times)
is different. For example, one of a group of functions called "meta"
keeps track of the number of times the MDATA system has been consulted
for the same problem. Once a threshold is reached, the MDATA system
advises the patient that the number of consultations alone, for
the same complaint, may signify a problem. The system then makes
an appropriate recommendation.
Before the MDATA system stores any information, the system verifies
its accuracy. To accomplish this task, "confirmation loops"
are used. Any piece of information that will become a part of the
patient's medical record is sent through a confirmation loop where
the system asks the patient to verify the accuracy of the information
that the system has collected. The confirmation loop enables the
system to verify new patient information and make corrections before
it enters this information into the patient's medical record.
IV. Authoring Language
The MDATA system uses a new authoring language that is specifically
designed to allow medical knowledge to be encoded into a usable
computer program. The presently preferred voice response or telephony
version of the MDATA system is written in object-oriented Microsoft
C\C++ version 7.0. This allows the MDATA system to easily interface
with industry-standard database programs, including those that are
SQL-based, as well as to be portable to other operating systems.
The operating system is transparent to the user.
Before the development of the MDATA system's authoring language,
there was no practical way for medical experts to encode their knowledge
into a meaningful, useful, and accessible structure. Although other
computer languages have been used to build medical expert systems,
they have almost always required a knowledge engineer and a programmer
to be involved. Quite often, the knowledge encoded in these systems
could only be accessed and fully understood by physicians. Typically,
the programmer would try to translate the doctor's diagnostic skills
and treatment rules into computer code. This separation of the physician's
knowledge from the encoded treatment recommendations often engendered
anxiety in the physician and has, at times, led to inaccurate treatment
recommendations.
The MDATA system's authoring language, however, is designed to
allow physicians to transfer their knowledge into a computer program
that can be directly accessed by non-medically trained personnel.
Recursive and iterative techniques are used to acquire the knowledge
from the expert and assemble it in a way that allows it to be immediately
transposed into the MDATA system's algorithms. Because of the simple
interface of the language, and because a formula for writing the
algorithms has already been developed, physicians who are not computer
literate can encode their knowledge as well as understand exactly
how that process takes place.
The MDATA system's authoring language allows flat information to
be restructured into a hierarchical or layered format in which the
arrangement of the knowledge conveys meaning. Thus, a textbook description
of a disease can be transposed into a form that allows useful treatment
recommendations to be made.
The new language also allows the formation of a structure in which
multiple overlays of screening questions, combined with the application
of recursive techniques, sequentially exclude some diagnoses while
at the same time reaching treatment recommendations. The MDATA system's
simplicity and elegance would not be possible without the new language.
The MDATA system's authoring language allows an algorithm programmer
to retrieve information from a patient's medical record, request
additional information from the patient, and guide the flow of algorithm
execution based on medical history and the patient's responses.
The language allows the programmer to implement an algorithm in
a natural scripted style.
The course of an algorithm is determined by caller responses to
questions that the MDATA system asks. For simple "yes/no"
questions, the flow of interaction can be described by a binary
tree. Multiple-choice questions (e.g., menus) provide multiple branches
in the tree. Each question can be considered a node, and the acceptable
responses to this question are branches leading to the next question
(node). Using this abstraction of an algorithm, one can draw a directed
graph (also known as a node map) of the nodes and branches of an
algorithm, beginning with the initial question, and ending with
all possible terminal points.
The node table is built in this manner: 1. An author develops an
algorithm. 2. The algorithm is broken up into separate nodes. 3.
A directed graph is drawn up, which is a flow chart of the algorithm's
operation. 4. Each node's definition is entered into the MDATA system,
either by: a. using an ednode utility to write each node's definition
into the system's machine readable node table, or b. using an xlat
utility to translate an ASCII file of human-readable node definitions
into the system's machine readable node table.
Referring to FIG. 3, a process for translating a medical algorithm
written in the authoring language will be described. FIG. 3 illustrates
an ASCII (American Standard Code for Information Interchange) format
text file 170 as an input to a translation utility 172. An ASCII
file can be created by use of a text editor or a word processing
program (may need to export to the ASCII format). The ASCII file
170 contains node definitions conforming to the syntax briefly described
hereinbelow.
The purpose of the ASCII node definition translator utility 172
(xlat.exe, along with functions in pars.c and util.c) is to convert
a human-readable document into a machine readable format that the
MDATA system reads at run time to process an algorithm. This utility
172 may be considered to be a preprocessor; the translation must
be accomplished prior to run time.
The output of the utility 172 is a set of binary (NOD_BLK) records
written to a node table 174 (filename of node.fos), and a set of
binary list files 176 (in a subdirectory \list\listxx\xxyy, where
xx is the first two digits of the node number, and yy are the last
two digits). Four list files 176a-176d are shown as an example.
Each "list" file, e.g., 176a, contains a "next"
table (i.e., the `next node after this one`), a message play list
for this node, and a "work" list (i.e., one or more "things
to do" at this node before beginning speech playback). The
binary record written to the node table 174 (node.fos) has fields
containing the node number (which is redundant; the record's position
in this file also indicates the node number), the node's "type"
attribute (Menu, Link, Prompt, Yes/No, Return, Hangup) and a parent
node number.
The node table 174 is a table of 10,000 NOD_BLK records. This table
174 is indexed by a node number, e.g., the fiftieth record corresponds
to node 50. The contents of the individual node records may be viewed
by selecting "Display Node" while running the ednode utility.
The node records are modified by either using the ednode utility,
or when translating node definitions from ASCII to the node file
with the xlat utility.
One of the following keywords is necessary as the first item on
each line, but only one keyword is accepted per line; any excess
information will be discarded. Node The Node keyword denotes the
beginning of a new node and defines the node number. Parent The
Parent keyword defines the parent of the node being defined. Type
The Type keyword defines the class of the node being defined. Acceptable
type names are: Menu This node presents a multiple choice question.
YesNo This node presents a simple Yes/No type question. Link No
caller response is required at this node, algorithm processing will
continue at a predetermined node. Prompt This node requests some
numeric information from the caller. The information is placed in
a DTMF buffer which is then stored in the next node. Return Returns
from a subroutine call (e.g., after configuring a past medical history
object). Hangup The system will release this caller after it finishes
speech file playback, or if the caller interrupts playback with
a DTMF key press. Wait nn This node will play the message list,
then pause for the specified nonzero number of seconds before continuing.
@ The @ keyword defines the action to be taken for a response to
either a Menu or YesNo type node. Digits The Digits keyword is used
in conjunction with Type Prompt to indicate the maximum number of
DTMF digits to collect from the caller. Play The Play keyword defines
a play list of one or more messages to be played at this node. Help
The Help keyword defines a play list of one or more messages containing
useful hints for interacting with the system. These messages provide
helpful instructions for a new or confused caller. Next The Next
keyword defines the next node to jump to after the node being defined.
It is used in conjunction with node types Link and Prompt. Work
The Work keyword indicates a sequence of one or more operations
to perform when arriving at the node being defined. This processing
occurs before speech playback begins.
A select set of math functions, relational operators, and nested
if-then-else statements are supported. A pound sign (`#`) or a hyphen
(`-`) in the first position on a new line will cause the translator
to skip over the rest of the line. This is useful for inserting
comments, or delimiting between individual node definitions. The
translator also disregards blank lines.
In order for a node to be properly defined, a minimum number of
keywords must be present for each node, and other keywords must
be included depending on the node type. The minimum keyword set
for a properly defined node is:
Node, Parent, Type, and Play.
Dependency rules: (1) The Menu type requires at least an @ 1 line
and an @ 2 line. (2) The YesNo type requires an @ 1 and an @ 2 line
(@ 3, etc. are ignored). (3) The Link type requires a Next line.
(4) The Prompt type requires a Digits line and a Next line.
The first keyword in a node definition must be Node. The other
keywords may be given in any order. The next occurrence of the Node
keyword will invoke a completeness test. If the completeness test
is successful, then the node definition is saved in machine readable
(binary) format, and translation continues with the new Node line.
A set of reserved language keywords is listed in Table 1.
TABLE-US-00003 TABLE 1 Reserved language keywords (case insensitive):
@ link return and menu test digbuf meta then digits next type else
node wait essf parent write flush play work hangup pop xor help
prompt yesno if push keep reenter
V. Run-Time Operation
Referring to FIG. 4, the run time interaction among the hardware
and software components of the MDATA system 100 will be described.
As previously mentioned, algorithm processor 160 includes the parser
and supporting functions that manipulate the memory variable symbol
table and the run time stack. For a selected medical algorithm,
a node record is read from the node table 174 and a list file is
read from the plurality of list files 176. The algorithm processor
also interacts with the Vpro voice recognition (VR) board 124 for
speech recognition and with the Dialogic voice processing (VP) board
122 for speech playback and DTMF detection. The VP board 122 further
is interconnected with a set of speech files 180 that are stored
on a portion of hard disk 152 and with one of the telephone lines
106 that connects via the telephone network 108 (FIG. 1) to the
patient's telephone 110. The VR board 124 further connects with
the voice print vocabularies 182, previously described, also stored
on a portion of hard disk 152. The algorithm processor 160 utilizes
the speech recognition, speech playback, and DTMF detection resources
as directed by the medical algorithm that is retrieved from the
node table 174 and the list files 176.
Referring to FIGS. 4, 5a and 5b, several data structures are utilized
at run time. These data structures are described as follows: A.
Port Status Block (PSB). A port status block is created at run time
for each VP board 122 channel. The PSB contains flags, buffers and
tables that hold the state information of the channel, retain responses
from the caller, and keep track of where to transfer control in
response to voice recognition and telephony events. The PSB keeps
track of whether the caller prefers to use spoken or touch tone
responses, the caller's last response, the number of consecutive
errors the caller has made, and other context sensitive parameters.
B. Node Block. This structure 196 contains the node number, the
type attribute (link, menu, yes/no, hangup, prompt, wait, return)
and pointers to: a. Help list--a Play list of help information;
b. Play or Message list--a list of one or more messages or speech
files to play in sequence at each node; c. Next table or list--contains
entries for each possible response to a yes/no or menu node that
are evaluated at run time to determine the next node to branch to;
and d. Work list--things to do before message playback starts. The
load_node( ) routine 194 in util.c builds the node block structure
196 in memory by first reading in a node record 190 from the node
table 174. Then linked lists are attached to the pointers help,
play, next and work. These lists come from the list files 176, in
subdirectory path \list\listxx\xxyy, where xxyy is the node number,
wherein each list file 192 is associated with a unique node. C.
Symbol Table. Each patient has their own associated symbol table.
A portion of a symbol table 212 is shown in FIG. 5b. The symbol
table is loaded at run time with memory variables that hold patient
specific data (age, sex, and items from medical history) and algorithm
specific data. The items in the symbol table can be flagged for
storage to the patient's medical history. D. Run Time Stack (RTS).
Each Dialogic VP board 122 channel has a RTS associated with it.
The RTS is used by the parser. The algorithm programmer can push
to and pop from the RTS, e.g. to temporarily store a value of a
variable.
The work list has the non-playback tasks that are performed at
each node. There is one work list for each node, and it is identified
with the work keyword in the ASCII node definition file. The work
list may be empty. Each time the system transits to a new node,
it will execute the work list. If the patient repeats a node, the
system will not execute the work list again; it will simply replay
the message(s). If the patient requests the system 100 to back up
the node map, the system will execute the work list of the node
it backs up to. Typical tasks in the work list involve manipulating
objects on the run time stack or in the symbol table, testing for
the presence of memory variables, configuring past medical history
or current medical condition objects, or writing database records.
An example of a complex work list follows: "Test OBJECT2; Phone=DIGBUF;
Push Age" This example tests for the presence of a patient
record object labelled "OBJECT2", loads the contents of
the digit buffer into memory variable Phone, and pushes the value
of memory variable Age onto the run time stack.
Each node has the "next" table or list. The next list
indices range from 1 to 9, inclusive. The next list contains either
a single node number, or an if expression. For all node types, except
the Hangup node, there will be at least one next list: Link and
Prompt nodes: the next node is stored at table index 1. Yes/No node:
the next node for the Yes response is stored at table index 1, and
the No response is stored at index 2. This corresponds to the prompt,
"if the answer is yes, press 1; if no, press 2." Menu
node: the response number and the table index are the same. Even
though the actual data structure has a `0` index in the C programming
language, this index is not used in the next table because a `0`
response is reserved for operator assistance.
Following is an example of a next list: "If Male and Age >55
then 100 else 200" is interpreted as: If the patient is both
male and over 55 years old then go to node 100 else go to node 200.
Speech files 180 may be of an arbitrary length. A message may be
informational, a list of menu options, or a yes/no question. A "two
paragraph" or "under one minute" limit has been adopted
as a style convention for the presently preferred embodiment. Typically,
a node is programmed as a sequence of Yes/No nodes, with "informational"
Link nodes interspersed as needed. When there is a lengthy discussion,
the speech is recorded in multiple files. To simplify algorithm
programming and enhance readability (viz., eliminate long chains
of link nodes), the Link node's play list may contain up to ten
message numbers.
Upon arrival at a Link node, the system positions a "current
message" pointer at the beginning of the play list (trivial
case: single message play list; interesting case: multiple message
play list). As playback proceeds, the current message pointer moves
down the play list. After the system plays the last message on the
list, it moves on to the next node.
If the caller issues a "backup" command, the system will
move the current message pointer back one message, and resume playback.
If the pointer was at the beginning of the list (e.g., trivial case),
the system backs up to the previous node and places the current
message pointer at the beginning of the play list. If there is more
than one message in the list, the system cues the pointer to the
last message in the list. The system then resumes playback. In the
"pause" mode, when the caller issues the "continue"
command, the system will resume playback at the current message.
The MDATA system 100 uses three basic operating modes: A. Real
Mode--involves an actual medical problem. In this mode the system
100 loads the past medical history, saves new past medical history
objects, and writes a meta record for each algorithm consulted.
The medical algorithm programmer is responsible for providing code
to jump past meta analysis in Information mode. B. Information Mode--involves
a "what if" scenario. In the Information mode the system
100 disregards past medical history, does not save newly configured
past medical history objects, does not write a meta record for each
algorithm consulted, and does not perform meta analysis. The patient
has an option in Information mode to change the age and sex parameters
to emulate a hypothetical patient. C. Pending Mode--handles the
situation when a patient's voice sample does not match the patient's
reference sample. Pending mode is utilized also when an assistant
is interacting with the MDATA system 100 on behalf of a patient
and both the assistant's and the patient's voice samples fail the
voice printing test. In the case where the assistant's voice sample
fails the voice printing test but the patient's voice sample passes
the test, Pending mode is not utilized. In Pending mode, the MDATA
system 100 considers the patient's medical history and performs
meta analysis during this consultation. However, a meta record is
not written for this consultation and any new medical information
gathered on this patient will not be written to the patient's medical
record. The new medical information is written to a "Pending"
file. The Pending file is verified off-line by a system administrator
or staff person, and then is added to the patient's medical record
only if the information can be verified.
One of the drawbacks of the traditional doctor-patient relationship
is the short amount of time that physicians are able to spend with
patients. The MDATA system 100, however, allows patients as much
time as they wish to learn about their problem as well as to obtain
information on any number of other medical topics.
Through the "Information mode" feature of the MDATA system
100, callers can learn about a disease process, an illness or the
latest treatment for any disease, without adding any information
to their personal medical record. Although the system 100 keeps
track of the interaction, it is labeled as an "Information
mode session." The record of the caller's path through the
system is not used as the basis for any future advice, nor is it
considered in generating system statistics.
The Information mode is not limited to complaints for which the
MDATA system 100 offers medical advice. Information about early
detection and treatment of many other diseases as well as the latest
advances in medicine can be made available through the Information
mode.
Referring to FIGS. 5b through 5g, as an example, a run time sequence
of steps of how a patient may traverse a main menu node map several
steps into a chest pain algorithm node map will be described. A
portion of the main menu node map with associated script, and of
the chest pain algorithm node map with associated script is included
in the Microfiche Appendix. Six nodes with a portion of an associated
symbol table will be discussed.
At FIG. 5b, the algorithm processor 160 loads the first node #100,
represented by node block 210. The variables for Age, Sex, and Real
mode were loaded into the symbol table 212 during the login process
(which will be described hereinbelow). Throughout this example,
the help list is empty, i.e., no help information is played for
the patient. The work list sets the Problem variable of the symbol
table 212 to be Menu. Then the system 100 begins playback of message#100.
This message gives the patient a menu of choices to choose from.
The Digits entry equal to one means that a one digit response is
expected from the patient. The patient may respond by pressing a
touch tone (DTMF) key on the telephone or speak the choice response
into the telephone handset microphone. In this example, the patient
selects menu option "1". The parser evaluates the Next
list based on the patient selection and branches to node #101.
At FIG. 5c, the algorithm processor 160 loads node #101, represented
by node block 214. The work list is empty, so the system 100 goes
right to playing back message#101 which presents another menu of
choices to the user. The Next list has four nodes for possible branch
points. In this example, the patient selects menu option "1"
for a chest pain complaint. The parser evaluates the Next list based
on the patient selection and branches to node #2200.
At FIG. 5d, the algorithm processor 160 loads node #2200, represented
by node block 218. The work list command is to update the value
of Problem in symbol table 220 to CCHP (chest pain). Then the system
100 begins playback of message#2200. No response is required from
the patient for a Link type node. The Next list has two nodes for
possible branch points depending on the value of symbol table variable
Real. The parser evaluates the If expression in the Next list for
the value of Real and, in this example, branches to node #2201.
At FIG. 5e, the algorithm processor 160 loads node #2201, represented
by node block 222. The work list command is to write a Meta consultation
record for future use by a Meta function. The play list is empty
so no message is played. No response is required from the patient
for a Link type node. The main purpose of this node is to write
the Meta consultation record (because the system is currently in
Real mode for this patient). The Next list has only one node so
no decisions are necessary by the parser which, in this example,
branches to node #2205.
At FIG. 5f, the algorithm processor 160 loads node #2205, represented
by node block 226. The work list is empty in this node so the system
100 goes right to playing back message#2205 which presents a yes/no
type of question to the user. The Next list has two nodes for possible
branch points depending on the response of the patient. In this
example, the patient responds "no", and the parser evaluates
the Next list based on the patient selection and branches to node
#2210.
At FIG. 5g, the algorithm processor 160 loads node #2210, represented
by node block 230. The work list is empty in this node so the system
100 goes right to playing back message#2210 which presents a yes/no
type of question to the user. The Next list has two nodes for possible
branch points depending on the response of the patient. If the patient
answers "yes" to the question, the parser branches to
node #2211, but if the patient answers "no" to the question,
the parser branches to node #2215.
VI. Software Structure
Referring to FIG. 6, the system utilizes eight principal, separate
processes and seven related databases. A patient login process 250
is used by the system 100 to identify a patient who has previously
registered into the system by prompting for a patient identification
number (PIN). An assistant login process 272 is used by the system
100 to identify an assistant who has previously registered into
the system by prompting for an assistant identification number (AIN).
An assisted patient login process 276 is used by the system 100
to identify a patient who has previously registered into the system
by prompting for the patient identification number. If the caller
is the patient, a patient registration process 252 is used by the
system to register new or first-time patients. If the caller is
not the patient, an assistant registration process 274 is used by
the system to register new or first-time assistants. Then, if the
patient is not already registered, an assisted patient registration
process 278 is used by the system to register the patient. These
processes will be further described hereinbelow.
Once a caller has logged in or registered, the system provides
a choice of two other processes in the current embodiment. The first
of these processes is the evaluation process 254 that performs a
patient diagnosis. The second of these is a treatment table process
256 to obtain current treatment information for a particular disease
or diagnosis. In another embodiment, other choices are added to
access other medical information processes.
Associated with these eight processes are a patient and assistant
enrollment database 260, a consultation history database 262, a
patient response database 264, a medical history objects database
266, a patient medical history database 268, a pending database
269, and a patient medication database 270 that are described as
follows: A. The master patient and assistant enrollment database
260 is created at run-time by one of the registration processes
252, 274, or 278. This database 260 is read by the patient login
process 250 or the assisted patient login process 276 to validate
a patient's identity at login time and by the assistant login process
272 to validate an assistant's identity at login time. The database
260 is essentially a master file of all registered patients and
assistants indexed by their patient ID number or assistant ID number,
respectively. The patient ID or assistant ID, date of birth and
gender fields are entered by the on-line registration process; the
system administrator manually enters the name of the patient or
assistant in an off-line manner. The patient and assistant database
260 contains one record for each patient or assistant. This database
260 is indexed by the identification number. The system appends
the enrollment database 260 after a caller is successfully registered.
The "next ID number" is stored in a binary file, config.fos,
and is incremented after each successful registration. Each record
has the following fields:
TABLE-US-00004 Field Name Data Type Width Usage ID Numeric 10 ID
number TYPE Character 1 User type: "P"--patient, "A"--assistant
ASST_PERM Boolean 1 Permanent assistant flag ASST_EXP Date 8 Expiration
for permanent assistant RELATIONS Pointer 20 Pointers to related
patients/assistants ORGZTN Character 8 Organization alphanumeric
code NAME Character 20 Patient/Assistant name SEX Character 1 Gender
YEAR Numeric 4 Year of birth MONTH Numeric 2 Month of birth DAY
Numeric 2 Day of birth ACCESS Date 8 Last access RV_PATH Character
20 Path name of recorded voice file
B. The consultation history or meta database 262 is created at
run-time by the evaluation process 254. A consultation record contains
alpha-numeric codes for the patient's complaint, the affected anatomic
system and the diagnosed cause of the patient's complaint. When
the meta function is invoked at run-time, it compares alphanumeric
strings provided by the evaluation process with the fields of all
the patient's meta records that fall within a time window specified
by the evaluation process. The meta function returns the number
of matches found, and an indication of the frequency of the patient's
complaint. Each patient has an individual meta file that is part
of the consultation history database 262. At the conclusion of the
evaluation process and dependent on the run-time operating mode
flag, the system will create a new meta record, populate its fields
with the information gathered during the evaluation process, and
append this record to either the consultation history database 262
or the Pending file 269. For example, information used in the new
meta record may come from a "Write Meta" command in a
node Work list. Each record has the following fields:
TABLE-US-00005 Field Name Data Type Width Usage DATE Date 8 Date
stamp PROBLEM Character 5 Patient complaint/symptom SYSTEM Character
5 Anatomical system affected CAUSE Character 5 Diagnosed cause of
complaint
C. The patient response database 264 is created at run-time by
the evaluation process 254. The response database 264 is an audit
trail: each record is time stamped and registers the patient's response
to each question. This database 264 can later be analyzed off-line
with a database program such as FoxPro/FoxBase to reveal how the
patient responded to questions during the evaluation process 254,
or a database program can be developed to gather response patterns
and statistics and generate appropriate reports. Each patient has
a response trace file that is part of the patient response database
264. The system 100 appends this response trace file with a response
record every time the patient answers a question or provides algorithm-requested
data. For human readability, the system also inserts "Begin
Call" and "End of Call" records in this file. Each
record has the following fields:
TABLE-US-00006 Field Name Data Type Width Usage DATE Date 8 Date
stamp MM/DD/YY TIME Character 8 Time stamp HH:MM:SS NODE Numeric
6 Current node number TYPE Character 5 Response type: DTMF or VOICE
RESP Character 5 Response command or digit string MODE Character
1 Consultation operating context VERSION Character 20 Version or
Begin/End call comment SENS_FACT Character 20 Current sensitivity
factor settings
D. The medical history objects database 266 is an auxiliary database
that supports a key feature of the MDATA system 100: past medical
history. The medical history objects database is a catalog of unique
alphanumeric codes, each code corresponding to a medical condition
or diagnosis that is not expected to change during the life of the
patient (e.g., a diagnosis for asthma is coded as "RWHZAST").
In addition to the alphanumeric codes, the MDATA system 100 uses
the "memo" field in a Foxpro database to store binary
objects. Currently, these binary objects are clinical sounds obtained
from the patient over the telephone. It is anticipated, that as
database technology gets more sophisticated (moving toward multi-media
and so forth), it will allow storing of larger and more complicated
binary files such as the following: a digitized x-ray, a digitized
CAT scan, a digitized MRI scan. In addition, as video-telephone
technology advances, it is anticipated that the system 100 will
store video images or even holographic images of the patient. For
every past medical condition there is a record in the medical history
objects database that contains the attributes of the medical condition,
and contains a pointer into the past medical history questionnaire.
The attributes of a medical condition include its data type (e.g.,
Boolean or numeric) and the number of digit positions needed to
store the value of a numeric value associated with this condition
(not applicable to Boolean type). The pointer field is useful for
obtaining medical history at run-time. If a patient has an incomplete
medical history questionnaire on file with the MDATA system 100,
then the pointer field allows the evaluation process to momentarily
suspend the evaluation, go to the medical questionnaire and ask
an individual question, collect and verify the patient's response,
and then resume the evaluation process. This "ask-when-you-need-it"
approach relieves the new patient of going through an exhaustive
medical history questionnaire before the first consultation of the
diagnostic process. Each record of the medical history objects database
has the following fields:
TABLE-US-00007 Field Name Data Type Width Usage LABEL Character
8 Object code name TYPE Character 1 Object data type DIGITS Numeric
3 Maximum number of digits in response CALL Pointer 6 Identifies
question(s) to be asked to configure this object AUDIO Binary N/A
Voice print IMAGERY Binary N/A Face print RFU Character 20 (For
future use)
E. The patient medical history (PMH) database 268 is created at
run-time by the evaluation process 254 or by use of a past medical
history questionnaire. The PMH database 268 is read by the evaluation
process during run-time. This database 268 contains each patient's
individual medical history. A new patient has an option to go through
the entire medical questionnaire at one time, thereby configuring
all the past medical history objects listed in the objects database
266. Alternately, the new patient can bypass the questionnaire and
go right into the diagnosis of a medical complaint. Then, if a medical
algorithm requires a past medical history object that has not yet
been configured, the evaluation process 254 invokes a past medical
history function before it continues with the algorithm. Each patient
has their own past medical history file, which is part of the PMH
database 268, that contains records which describe medical events
or conditions from the patient's life. The system 100 appends a
record to this file each time a past medical history object is configured
for the patient. The contents of this file are installed in the
symbol table when the patient logs in to the system 100. The medical
algorithm programmer is responsible for using a TEST command to
verify that necessary items are present in the symbol table before
algorithm execution. A side effect of a negative TEST result is
that the system 100 prompts the patient to provide that information.
The system 100 flags any new or modified items, and asks the patient
to confirm these values during an Exit Confirmation Loop which will
be described hereinbelow. Each record has the following fields:
TABLE-US-00008 Field Name Data Type Width Usage LABEL Character
20 The object's label TYPE Character 1 Object data type VALUE Character
10 Object's configured value CERT Numeric 3 Certainty of object's
value DATE Date 8 Object configuration date ICD9A Float 5 First
ICD-9 code | | | | ICD9E Float 5 Fifth ICD-9 code
F. The "Pending" database file 269 holds medical information
gathered during Pending mode for offline verification. The Pending
database record structure is the same as that used for the past
medical history (PMH) database 268. The evaluation process writes
to the Pending database at run-time when it configures a new past
medical history object for a patient during a Pending mode interaction.
The contents of the Pending database are reviewed off-line by a
staff person, and if the information is verified, the staff person
appends the information to the patient's past medical history file.
G. An optional patient medication database 270 contains a file for
each patient containing information about medication they are taking,
or have taken in the past. The medication database 270 is created
by the evaluation process 254 at run time. A "Write Drug"
command builds a record and fills its fields with same-named memory
variables from the symbol table. The evaluation process 254 may
read the medication database 270 during run time as needed. The
treatment table 256 optionally reads the medication database 270
to determine the medication(s) being used by the patient.
TABLE-US-00009 Field Name Data Type Width GENERIC_NAME Character
20 TRADE_NAME1 Character 20 TRADE_NAME2 Character 20 TRADE_NAME3
Character 20 ICD-9-CM_CODE Character 10 ICD-9-CM_ECODE Character
10 ICD-9-CM_VCODE Character 10 OTHER Character 20 DOSAGE Character
20 ROUTE_OF_ADMINISTRATION Character 10 FREQUENCY Character 10 USE
Character 20 START_DATE Date 8 STOP_DATE Date 8 OTHER1 Character
20 OTHER2 Character 20
VII. Top-Level Flow
Referring to FIGS. 7a, 7b, 7c and 7d, the top level flow 300 of
the MDATA system 100 software will be described. The telephone number
used to access the MDATA system 100 may vary in various embodiments
of the system. If the sponsoring agency or hospital wishes to provide
access to the MDATA system 100 at no cost to the caller, then a
toll-free 800 service number can be used. If the sponsoring agency
or hospital wishes to recover the costs of running the MDATA system
100 from the caller, it may use a pay-per-call or premium charge
number (e.g., 900 service). "Current Procedural Terminology"
(CPT-4) codes are available to describe and bill third party payers
for telephone consultations. They are a listing of the descriptive
terms and identifying codes for reporting medical services and procedures.
CPT-4 codes are the most widely accepted nomenclature for reporting
physician services to insurance companies.
Beginning at a start state 302, a person 112 (FIG. 1) desiring
medical advice calls the telephone number for the MDATA system 100
on a telephone line 106. The caller may be the patient or may be
an "assistant", e.g., parent, relative, or friend, that
is helping the patient. Moving to state 304, the system 100 answers
the call automatically and greets the caller 112 with an introductory
greeting message by playing back a speech file stored on the hard
drive 152 by use of the VP board 122. Proceeding at state 306, the
MDATA system 100 asks each patient who calls the system a series
of "initial screening questions." These questions are
designed to identify patients who are critically ill; they are not
designed to identify the patient's problem. The initial screening
questions enable the system to filter out patients who require immediate
medical attention.
Moving to decision state 308, any patient found to be critically
ill is instructed to dial the emergency response telephone number
"911" at state 309 or will be automatically connected
to the nearest emergency medical services system in the patient's
area. The telephone call is terminated by the computer 102 at state
310. The following are examples of initial screening questions:
IS THIS A MEDICAL EMERGENCY? ARE YOU HAVING DIFFICULTY BREATHING?
ARE YOU EXPERIENCING SEVERE PAIN OR PRESSURE IN YOUR CHEST?
If the system determines that the patient is experiencing a medical
emergency, it may provide the patient with a menu of emergency medical
procedures at state 311. In situations where the patient or the
caller for the patient is far from the nearest emergency help, e.g.,
a rural setting, the caller may need to initiate emergency procedures
immediately. The menu of emergency medical procedures provides several
choices to the caller. If the caller presses touch tone key "1"
or speaks the word "one" into the telephone mouthpiece,
the computer 102 branches to state 312 wherein well known CPR (cardiopulmonary
resuscitation) information is recited. If the caller has a speakerphone
capability associated with the telephone 110 being used, the caller
may be able to listen to and perform the instructions given by the
system 100 in a hands-free manner away from the telephone. If the
caller presses touch tone key "2" or speaks the word "two"
into the telephone mouthpiece, the computer 102 branches to state
313 wherein well known Heimlich Hug information for choking is recited.
At the completion of either state 312 or state 313, the telephone
call ends at state 314.
If the patient is determined at state 308 not to have a medical
emergency, i.e., the MDATA system 100 is satisfied that no immediately
life threatening condition is present, the computer 102 moves to
a decision state 315 to determine if the caller is the actual patient.
If so, the computer 102 proceeds to a decision state 316 to determine
if the patient has previously registered or ever consulted with
the system 100, i.e., is not a new or first-time caller. If so,
the system 100 verifies the patient's identification and retrieves
their medical record at the patient login process 250, which will
be further described hereinbelow. At the completion of process 250,
the computer 102 proceeds through off-page connector C 317 to state
344 (FIG. 7d). If the patient is not registered, the MDATA system
100 proceeds to the patient registration process 252 for a new patient,
which will be described hereinbelow. At the completion of process
252, the computer 102 proceeds through off-page connector C 317
to state 344 on FIG. 7d.
If the caller is not the patient, as determined at state 315, the
computer 102 proceeds through off-page connector A 318 to state
320 on FIG. 7b. There will be times when the patient may not be
able to use the MDATA system 100 directly, e.g., due to injury,
weakness or altered level of consciousness. In these cases, an "assistant"
may interact with the system on behalf of the patient.
An assistant registers with the system through the assistant registration
process 274 which will be described hereinbelow. The assistant registration
record is identical to the patient registration record in structure,
but three fields have special significance for an assistant: ASST_PERM,
ASST_EXP, and RELATIONS. The ASST_PERM field is a Boolean flag that
can only be set true off-line by the system administrator who has
verified, through separate means, that a relationship exists between
a patient and an assistant. The relationships are one-to-many, i.e.,
a patient may have one or more assistants, and an assistant may
be related to more than one patient. The ASST_PERM flag may also
be constrained by the ASST_EXP field, which contains a timestamp
for the expiration of the ASST_PERM attribute. If the ASST_PERM
flag is true, then the RELATIONS pointers will point to one or more
patient records for whom this assistant is a "permanent assistant;"
otherwise the RELATIONS field will be empty.
The medical information gathered during an assisted consultation
is written to the patient's medical record only if the following
three conditions are met: (a) the assistant's ASST_PERM flag is
True (b) the ASST_EXP timestamp has not been reached (c) the assistant
has a relationship pointer to the patient record
If any of these conditions are not met, then any new medical information
gathered on this patient will be saved to the Pending file 269 for
off-line verification by the system administrator.
The system 100 establishes at state 315 whether the caller is the
patient, or an assistant. If the caller is not the patient, then
the system asserts that the caller is an assistant and, at a decision
state 320, determines if the assistant is registered. If the assistant
is not already registered with the system, the system enrolls the
new assistant at the assistant registration process 274. If the
assistant is already registered with the system 100, the computer
102 performs the assistant login process 272. At the completion
of either process 272 or process 274, the computer 102 advances
to a decision state 321.
If the patient is not already registered with the system 100, as
determined at decision state 321, then the system allows the assistant
to register a new patient at the assisted patient registration process
278. However, if the patient is already registered with the system
100, as determined at state 321, the computer 102 performs the assisted
patient login process 276. At the completion of process 278 or process
276, the computer 102 proceeds through off-page connector B 327
to a decision state 334 on FIG. 7c.
At decision state 334, the computer 102 determines if the patient's
date of birth is in the patient's medical record. If so, the computer
proceeds through off-page connector C 317 to state 344 on FIG. 7d.
If not, the system 100 attempts to get the patient's date of birth.
Moving to state 335, the system 100 asks the assistant if the patient's
date of birth is known. If so, the computer 102 advances to state
336 to request the patient's date of birth. At state 337, the system
100 recites the patient's date of birth obtained at state 336. At
a decision state 338, the assistant determines if the date of birth
is correct as recited by the system 100. If not, the computer 102
loops back to state 336 to request the patient's date of birth again.
If the patient's date of birth is correct, as determined at state
338, the computer 102 flags the date of birth for saving in the
patient's medical record at state 339, and proceeds to state 344
on FIG. 7d.
If the patient's date of birth is not known, as determined at state
335, the computer 102 proceeds to state 340 wherein the system requests
the assistant to provide an approximate age of the patient. The
age is an important parameter used in the evaluation process 254
and treatment table 256. At state 341, the system 100 recites the
patient's approximate age obtained at state 340. At a decision state
342, the assistant determines if the age is correct as recited by
the system 100. If not, the computer 102 loops back to state 340
to request the patient's approximate age again. If the patient's
approximate age is correct, as determined at state 342, the system
100 advises the assistant at state 343 to get the patient's actual
date of birth before the next consultation, and proceeds to state
344 on FIG. 7d. The system 100 uses the approximate age in the consultation
during the evaluation process 254 and the treatment table 256.
At state 344 on FIG. 7d, the system 100 presents the caller with
a system selection menu. Here, the caller is asked to select from
among four choices: diagnostic system, treatment table, a future
process/function, or end call as described below: A. Diagnostic
System: The system starts the evaluation process 254 at a menu,
where it asks the patient to begin identification of the complaint.
B. Treatment Table: The system takes the patient to the treatment
table process 256 at a menu, where it asks the patient to select
a treatment selection method. C. Future Process/Function: A future
process or function 280, undefined in the present embodiment, that
reads and/or writes the databases shown in FIG. 6. D. End Call:
The system performs several steps and then terminates the telephone
call.
In either process 254 or 256, the computer 102 functions as an
interpreter as performed by algorithm processor 160 in following
the node map created by the algorithm programmer. At the exit point
of the evaluation process 254, the system 100 gives the patient
the option of selecting another complaint. At the end of the treatment
table process 256, the system gives the patient the option of selecting
another treatment.
At the completion of the evaluation process 254, treatment table
process 256, or future process 280, the system 100 loops back to
state 344 and recites the system selection menu to the caller. If
the caller chooses the End Call selection at state 344, the MDATA
system 100 moves to a decision state 345. At decision state 345,
the system 100 determines if process 254, process 256, or process
280 did not occur in Information mode, i.e., did occur in either
Real mode or Pending Mode, and examines the patient's symbol table
to determine if any of the configured memory variables are past
medical history conditions that need to be saved to the patient's
medical history file. If both conditions are true at state 345,
the system 100 advances to a decision state 346 to determine if
the consultation is being performed in Real mode. If not, the consultation
is being performed in Pending mode, and the system 100 then writes
any new patient information obtained during the consultation to
the Pending file 269. If state 346 proves to be true, i.e., Real
mode, for each past medical condition that needs to be saved, the
MDATA system 100 asks the patient at state 348 to grant permission
to save the datum to the patient's medical history file and to confirm
that the datum is correct. For example, during a consultation for
cough, the MDATA system 100 learned that the patient has been diagnosed
as being HIV positive. The system 100 will ask, "May I record
the information about your HIV diagnosis in your medical record?"
If the patient responds "yes", then the system 100 will
ask, "Please verify that your diagnosis for HIV was positive,
is this correct?" If the patient responds "yes",
then the system 100 writes this fact to the patient's medical history
file. After confirmation, each data item is stored in the patient's
file in the patient medical history database 268 (FIG. 6).
At the completion of either updating the history database 268 at
state 348, state 345 proves to be false, or at the completion of
state 347, the system 100 moves to a decision state 349. Before
the MDATA system 100 ends the consultation with the patient, it
presents a summary of all the advice it has given. The patient is
asked to write down and repeat back the key points. The MDATA system
100 then gives the patient the option of receiving a summary of
the consultation session and specific recommendations provided by
the system by facsimile, electronic mail (E-mail) or a mail service,
such as first-class mail. If a fax or E-mail is desired, the system
100 moves to a decision state 350 to determine if information to
send the summary and recommendations is available in the system.
If not, the system 100 asks the patient for the information, e.g.,
a fax number, E-mail address or mail address, at state 352. The
patient also has the option to send a summary of the consultation
to his or her health care provider or specialist. Proceeding to
state 351, the computer 102 adds the transcript of the current telephone
session to a fax queue or an E-mail queue, as desired, for subsequent
transmission. At the completion of state 351 or if the system 100
determined at state 349 that the session transcript was not to be
sent, the telephone call is terminated at state 353.
VIII. Login Process
Referring now to FIGS. 8a and 8b, the patient login process 250
defined in FIG. 7a will be described. This process 250 is called
if the patient has previously called and registered with the system
100. Beginning at a start state 358, the computer 102 moves to state
359 and initializes a match flag to true. The match flag is checked
later in this process 250 in conjunction with setting the mode of
the consultation. Proceeding to state 360, the computer 102 prompts
the patient for the patient ID (identification) number (PIN) that
is assigned during the registration process. The patient registration
process 252 will be described in conjunction with FIGS. 9a and 9b.
Proceeding to a decision state 361, the computer 102 determines
whether the PIN is valid. If not, the computer 102 determines, at
a decision state 362, if less than three tries at entering the PIN
have been attempted. If so, the computer 102 loops back to state
360 to repeat the request for the PIN. However, if three attempts
at entering the PIN have been made, as determined at state 362,
the computer 102 plays a polite message that advises the patient
that the login attempt failed and terminates the call at state 363.
The computer 102 reports the failed login attempt to the system
administrator at the sponsoring agency, hospital or other organization.
The patient is allowed to reregister as a new patient, however,
to permit acce |