Knowledge Representation in Medicine and Clinical Behavioural Science
by L.J. Kohout & W. Bandler
Abacus Press, 1986
pages 183-191
PERSONAL INFORMATION SYSTEM FOR DOCTORS
14.1 Introduction14.2 The Doctor's Requirements14.3 The System Outline14.4 The Representation of Information14.5 The Decision Making Unit14.6 The Hillingdon Cardiac System14.7 Conclusions14.8 References
14.1 INTRODUCTION
One of the common objections to computer systems by non-computer personnel concerns the rigidity of the systems and their inability to cope with real life situations. To a large extent this problem arises because of the origin of computers in the "physical science" area. The physical scientists' ideal of a set of well defined laws which act on objects in a closed environment is reflected in the computer's well defined programs operating on neat and tidy data:
Most doctors do not work in such an ordered environment. The information they handle tends to be poorly defined, incomplete, often ambiguous and sometimes contradictory. While more precise information may be obtainable in theory (for instance in a post mortem) in practice such options are rarely open. In addition there are many medical conditions whose natural history is not well understood, so that even if the doctor had perfect information on the patient it might be impossible for him to make a reliable prognosis.
What many doctors require from a computer is an approach to information processing which is specifically designed to work well in a messy real world environment in a way in which they can have good control over what it is doing for them. In this paper a system called CODIL is discussed with specific reference to the problems faced by doctors handling clinical information. Examples are based on an actual system set up in conjuction with Dr. George Sulton of Hillingdon Hospital. However, the background of the system owes much to the author's earlier (non-computer) experiences with a subsidiary of the Wellcome Foundation. In addition many of the ideas have also been used on a very much larger historical data hase which has a similar structure but is concerned with historical careers rather than current medical history.
14.2 THE DOCTOR'S REQUIREMENTS
Let us assume we have a team of doctors, with no knowledge of existing computer systems, who are drawing up a list of requirements for a personal information processing system to be designed from first principles. These doctors have a wide range of research, health care and administration interests and would benefit from the kind of system they are suggesting. It is assumed that suitable terminal and peripheral hardware exists.
The first requirement is that the system must be easy to understand and control.
This requirement is at a deeper level than the so-called "user-friendly" systems which try to hide the constraints of conventional computer technology by a series of restricted questions. (For instance some such systems will ask the user how many characters long he wants the field "surname" to be. The doctor user does not know, or care - but will be harassed by the system until it has got a numeric answer and he will be required to live with the consequences of the answer.) The key point is that the user can only exert positive control over the system if he understands how it works, so that he can take control from a terminal when the unexpected happens.
The second requirement IS flexibility. Not only must the system service a wide range of individuals, but in addition the needs of each will change dynamically as new medical techniques, research ideas, etc., emerge and old ones are discarded. In addition the user may often be faced with incomplete, approximate or contradictory information. Clearly incomplete or contradictory information is undesirable if unambiguous information is readily available, but in the very many cases where this ideal is not attainable, the system must be flexible enough to reflect the limited view of reality seen by the user.
The third requirement is that the system should be cost effective. To busy medical staff this means making the best use of their time, and convenience and reliability factors play an important role. Computing and support staff costs obviously need to be minimised - but not at the expense of the user's own time.
The above requirements show that the gap between the way most medical doctors think about the information environment and the way the Von Neumann computer works, is enormous. A flexible interface which the user can readily understand and use to handle poorly structured input is hard to provide, and mutterings are often heard in computing circles that doctors are woolly minded individuals who don't know what they want and could do with a good dose of computer education. The approach described below takes the less arrogant attitude that if our computer systems do not fit in well with the way doctors work, it is the systems rather than the doctors that are at fault.
14.3 THE SYSTEM OUTLINE
In attempting to design a system that reflects the needs of doctors it was decided to use an approach that allows them to represent their information in a way that was as natural and flexible as possible. A control structure for processing is also needed, and a very simple psychological model was taken as a starting point.
The user describes his problem in terms of "chunks of information" called items. These items are loosely tacked together in statements, to describe real or hypothetical contexts. At anyone time one of these contexts is active and occupies an associatively addressed "short term memory:' called the facts. "Long term memory" consists of a number of associatively addressed files, each file being a loose association of statements. Processing is carried out by comparing pairs of files, via the facts, using a very simple production rule mechanism, the general purpose processing procedure being called the decision making unit.
If viewed as a "conventional" programming language the control structure is so simple as to seem simple minded. The language lacks, for all practical purposes, explicit brackets, condition words like "IF", or sequence changing facilities such as "GO TO". However such an analysis misses the point in that the approach described below leads to a context dependent "data driven" system for which the minimum of explicit control is needed.
The above ideas have been implemented in the CODIL system, and the principal features of this are outlined below, with special reference to medical computing needs, and the novel features of the language. It should be noted that CODIL allows the user, if he so desires, similar control over input/output formats, etc., as many data-base orientated programming languages.
14.4 THE REPRESENTATION OF INFORMATION
For c1arily all CODIL items are printed in upper case letters. In the examples the lines typed in by the user are preceded by a ">" symbol. In fact the latest version of the CODIL software handles both upper and lower case letters.
All information acceptable to the CODIL system must be represented in the forms of items. Each item has a name - which is the name of a set - coupled with other information which partitions a set. For instance, the item SURGEON = YACOUB partitions the set of surgeons in a very simple way, i.e. YACOUB and "the rest" (NOT YACOUB). AGE> 35 partitions the set of ages into two parts, and coupled with a second item such as AGE < 45 brackets the age of a person whose exact age is not known. The whole set and nul set can be used and while a user might well choose to say SEX = MALE or SEX = FEMALE he could also code his data as MALE and NOT MALE (or MALE NONE as it can also be written).
Neither item names nor their values, nor the format of the values, need be predefined and the user is free to use codes or free text, etc., as he chooses. However the option to predefine item formats is there if required, and abbreviated names are also possible. Certain item names, such as CREATE, END, PRINT and ERROR MESSAGE. correspond to system functions, principally associated with the input. output and storage of information.
Items may be associated together to make statements. For instance the following items might be used to describe a patient being referred for an operation at another hospital:
PATIENT NO = 4321 ; DATE = 85/03/11; EVENT = REFERRAL; DATE OF BIRTH = 1915: SEX = M; DIAGNOSIS = STOKE-ADAMS ATTACK; AETIOLOGY = IDIOPATHIC; OBJECT REFERRAL = SURGERY; REFERRAL CENTRE = BROMPTON.
At a later date other statements about the patient might be entered
PATIENT NO = 4321; DATE = 85/03/21; EVENT = OPERATION: SURGEON = PANETH; PROCEDURE = EPICARDIAL STANICOR DEMAND PACEMAKER.
Each statement describes a particular situation that the user wants the system to know about, and the following is just as valid a statement as the above. even if it is likely to be used in a different way.
SEX NOT M; SEX NOT F; ERROR MESSAGE = INVALID SEX CODING.
It should be noted that the system puts no limits on the way in which a user combines items to make a statement, except for a maximum arbitrary limit on the number of items. The user may introduce constraints by defining input or date vet files.
A statement is a list of items ANDed together. and a file is a list of statements ANDed together. The following very simple file consists of a number of state ments - each of which consists of a single item
> CREATE = SURGEONS.> SURGEON = YACOUB.> SURGEON = LINCOLN.> SURGEON = LENNOX.> ...> END.
Such a tile might be used to hold all the valid items for a particular set, and all statements have the same format because the user wants it that way. However there might also be a large "PATIENTS" file containing clinical notes of the type illustrated above. Here the user may well want all statements on a particular patient to be together - although every statement describing such a patient might have a unique format in terms of the number and nature of items it contains. Much of CODIL's flexibility arises from the dynamically variable structure of its files while more conventional data base systems are designed in such a way that the user is forced to predefine his file structure before he can use the system. In addition a number of files will contain mainly control information and be semantically similar to more conventional programs. It should be noted that the name of a file is an item name and "SURGEONS" is just as much an item as "SURGEON = YACOUB". This extension of the concept of an item to include a file is important as it introduces a completely new dimension to what is superficially a simple data structure
14.5 THE DECISION MAKING UNIT
Processing is controlled by a decision making unit that compares pairs of state ments. One is held in the facts and describes the current 'context' as seen by the system. The second statement, the criteria statement, is treated as a simple production rule with the structure "if the non-terminal items are true then the terminal item is by definition true". A few examples show how it works.
Example 1
The facts contain
PATIENT NO = 4321; .... ; SURGEON = YACOUB; PROCEDURE = CABG TO RCA PROCEDURE = CABG TO LAD
The criteria statement is
SURGEON = YACOUB; PRINT VALUE = PROCEDURE
The decision making unit decides that "SURGEON = YACOUB" is true. The terminal item is PRINT command which displays the value(s) of PROCEDURE. The system therefore outputs
CABG TO RCA & CABG TO LAD
Example 2
The facts as example 1 The criteria statement is
SURGEON = YACOUB; REFERRAL CENTRE = HAREFIELD
As before the SURGEON item is true and therefore the final item is true. The decision making unit transfers REFERRAL CENTRE = HAREFIELD to the facts. In conventional programming terms it has interpreted the criteria statement as if it had been written
IF SURGEON = "YACOUB" MOVE "HAREFIELD" TO REFERRAL CENTRE'
Example 3
The facts contain
.... DATE OF BIRTH >= 1900; DATE OF BIRTH =<1910;
The criteria statement contains
.... DATE OF BIRTH> = 1915; DATE OF BIRTH = >1920; ....
In this case the result of the comparison is false. However if the ranges overlapped the results could be ambiguous. The decision making unit treats such situations as true, allowing the user to ask more precise questions (for instance using DATE OF BIRTH(MEAN) > = 1915, etc.) if he wants to reduce the ambiguity.
Example 4
The facts contain some new patient information which has just been typed in with an error
....... ; SURGEON = YACUOB;.The criteria contains a "data vet" statement
SURGEONS NONE; ERROR MESSAGE = UNKNOWN SURGEON
The decision making unit finds that SURGEONS is a file (see above) and compares the file with the facts (in effect the decision making unit recurses on itself). As the mis-spelt item SURGEON = YACOUB is not on the file, SURGEONS is false, SURGEONS NONE is true, and the error message is displayed.
At a higher level the decision making unit will take items of the form
{file name 1} = {file name 2}.
and compares the first (as criteria) with the second (as facts) on a statement by statement basis. For instance, if the file LIST consists of a number of statements whose overall effect as criteria will be to issue PRINT commands, and the file PATIENTS contains the patient clinical records
LIST = PATIENTS
will lead to an automatic mapping between the two files - and an output listing of the PATIENTS file in a format depending on LIST.
14.6 THE HILLINGDON CARDIAC SYSTEM
CODIL has been used to process information on cardiac patients from Hillingdon Hospital for over 10 years and initially all work was done in batch mode. The system has been converted to interactive working, via a dial phone line based in the cardiac care unit. The following examples are designed to illustrate the type of facility that is available.
14.6.1 Simple searching
All that is needed to carry out a simple search is to create a file describing the search requirements. For instance, to list the PATIENT NOs of all the patients with DIAGNOSIS = AORTIC REGURGITATION and REFERRAL CENTRE = HAREFIELD the following is typed in:
> CREATE = SEARCH.> DIAGNOSIS = AORTIC REGURGITATION,> REFERRAL CENTRE = HAREFIELD,
> PRINT IS = PATIENT NO.> END.> SEARCH = PATIENTS4364 5163 ... {list of patient numbers} ... 7421
14.62 Controlled input
While any file could be generated by typing it in after a CREATE item, this is not practical for applications involving large files such as the PATIENTS file. The creation of a file, such as INPUT PATIENT, illustrates (in simple form) the way in which a user can use CODIL to help him format his data.
> CREATE = INPUT PATIENT> INPUT = PATIENT.> INPUT = DATE.> INPUT = EVENT.> INPUT ALL.> STORE ALL.> END.
This prompts the user to type in the required items, together with optional items (as a result of the INPUT ALL)
> INPUT PATIENTPATIENT NO = ?> 4561DATE = ?> 85/09/21EVENT =?> REFERRAL> DATE OF BIRTH = 1910> SEX = M> ...> END
A more compact format can be used by redefining item names. for instance
INPUT PATIENT (ABBREV) = IP
By using such abbreviations, plus colons as separators, the user can use the same file to handle much more compact input, without prompts.
> IP: 4561: 85/09/21: REFERRAL: DOB = 1910: S = M: .... : END.
In practise such a simple approach would only be used for comparatively small applications, and additional features, such as the ability to associate a PICTURE with an item name, or the use of data vet checks, would normally be introduced as the size of the task increases.
14.6.3 Diagnostic modelling
As yet the Hillingdon data has not been used as a diagnostic aid. However there are facilities within CODIL which would allow the system to interrogate the doctor about a patient by automatic comparison with earlier patient records. This is possible because the system can ask the user questions in a way that is 10gicalIy similar to the way that the user asks the system questions. In the folIowing deliberately oversimplified - example, a file, DIAGNOSES, has been produced by subsetting a small number of patient records to relate the DIAGNOSIS and the operative PROCEDURE. $QUERY tells the decision making unit to ask the user if in doubt. The rest is straightforward - there is no application specific "program" involved, but the system has "collected" the relevant items into facts.
> CREATE = DIAGNOSES> DIAGNOSIS = LV ANEURYSM; PROCEDURE = ANEURYSECTOMY.> DIAGNOSIS = RUPTURED VENTRICULAR SEPTUM; PROCEDURE = CLOSURE VSD.> DIAGNOSIS = STOKE ADAMS ATTACK; PROCEDURE = PACEMAKER FITTED.> DIAGNOSIS = AORTIC DISSECTION; PROCEDURE = AORTIC ARCH REPLACEMENT.> END> $QUERY.> DIAGNOSES.DIAGNOSIS = LV ANEURYSM? > NODIAGNOSIS = RUPTURED VENTRICULAR SEPTUM? > NODIAGNOSIS = STOKE ADAMS ATTACK? > YES> PRINT ITEM ALLDIAGNOSIS = STOKE ADAMS ATTACK; PROCEDURE = PACEMAKER FITTED.
14.6.4 Other Features
The underlying architecture of the CODIL system makes it possible to handle medical information in a manner that medical staff can understand. However it is important to be able to back up this with a range of conventional data base facilities, and there is a range of features for print output control, updating files with automatic backup, indexing large files for rapid access, etc.
In the context it is important to realise that, while medical applications have played a major role in the development of CODIL, the whole point of a genuinely flexible system is that it should be independent of .a narrowly defined group of users. CODIL has been used for a wide range of other applications. The biggest involved a historical data base which contains about n million bytes of information on over 4000 people. Other data bases are used for computer aided teaching of classes of up to 100 students and a series of "Teach Yourself CODIL" lessons with an associated HELP facility. In attempting to understand the psychological modelling aspects of the system a heuristic problem solver has been constructed and learning facilities implemented.
14.7 CONCLUSION
By studying doctors requirements in handling poorly structured medical infor mation a highly unconventional computer architecture has been proposed and implemented, in software, on conventional hardware. The trials at Hillingdon Hospital, as well as extensive tests of other applications at BrunelI, have shown that the system can handle both well structured and poorly structured information in volumes appropriate to a personal information system.
More trials are needed to test its acceptability in an unsupported environment but it appears that knowledge of existing computer techniques can be a disadvantage. Weinberg noted that programmers transferring from Fortran to PL1 used the latter language as if it had some of the constraints of the former. In the same way CODIL users who have previously programmed assume that their files must have a regular structure and that they must make a clear cut distinction between "program" and "data". People with no prior knowledge appear to have no such inhibitions.
14.8 REFERENCES
Neal, L. R., 1977. The computer handling of medical information for research purposes. Medinfo 77, Amsterdam, North-Holland, pp. 651-655.
Ohiorenoya, M. A .. 1984. A study of the representation, storage and retrieval of poorly structured medical data. PhD thesis, BruneI University.
Omrani, D., 1979. Some studies of the relational mode! and the CODIL language. PhD thesis, Brunel University.
Reynolds, C. F., 1971. COD1L, Parts 1 and 2. Computer Journal, Vo1.14, pp. 217-20, 327-32.
Reynolds, C. F., 1978. A psychological approach to language design. Proceedings of the Workshop on ComputerSkills and Adaptive Systems. (Liverpool). pp. 77-87.
Reynolds. C. F .. 1981. COD1L as an information processing language for university use, IUCC Bulletin. Vol 3 pp. 56-59.
Reynolds. C. F., Sutton G. and ShackeI M., 1978. Using CODIL to handle poorly structured information. Proceedings of Medical Informatics Europe. pp. 465-74.
Wernberg. G. M .. 1971. The psychology of computer programming. Van Nostrand Reinhold Co.
No comments:
Post a Comment