Description and advantages of an index-driven medical knowledge base

In the FRAMEMED system design, the inherent attributes of its concepts are expressed in the hierarchical lists of its 26 Elements (e.g., Agents, Clinical Manifestations, Diseases, Tests, etc.). These concepts, contained in regular structures, are then alphabetized by phrase (and synonym), forming a combined index in which the user may quickly find a concept either alphabetically or hierarchically. Stored in the structures of the index are pointers to four types of knowledge records: 1) Descriptive (definition); 2) Relational (incidental attributes); 3) Conditional (rules); and 4) Procedural (how to). In contrast to the index which is stored in regular structures for rapid access (like relational databases), the knowledge records are stored in free text (variable length) and may include pointers to imaging and audio records. A particular feature of the FRAMEMED system is careful attention to modifiers, an aspect usually not emphasized in other systems. In trying to structure the free text describing a patient encounter, for example, the major concepts such as cough, fever, stiff neck, etc., are relatively easy to code (although a common system has not yet been agreed upon). The devil lies in the modifiers such as 'history of', 'severe,' 'constant,' 'absent,' 'left,' 'abnormal,' etc., particularly when there is concatenation of modifiers modifying modifiers. Our Relational records (in our knowledge base) and our Chronological Medical Records (CMR) in our patient record have the same format, namely, a title, several related items, and a date/author. For example, our disease profile (Relational record) for 'Influenza' might include 'cough,' 'fever,' and 'stiff neck.' The CMR of a particular patient encounter might include the same items. The only differences would be the title (disease name for the disease profile, date for the CMR, and the omission of the redundant date in the date/author line of the CMR). Each related item in either of these records is expressed in a four-part string, namely: 1) Relation; 2) Code; 3) Phrase; and 4) Comment. Modifiers (common ASCII symbols) are structured into each of these parts. For example, if the patient did not have 'cough,' the default '+' in the Relation would be edited to a '-', while 'history of' cough would be '>'. Each Relation can be graded (on a 5-level scale) for both importance and frequency. The Code for a test can carry the result suffix, '+ positive/high,' '-negative/low,' '# abnormal (qualitatively)', or '1 unremarkable/normal.' Topological information, such as '/left,' can be appended to a Code. If the cough is getting worse, its code can have the suffix, '<'. The standardized Phrases associated with the Codes come from the hierarchical lists of the index section described earlier. Phrases are not stored, being rematched to the codes as needed for user display. This practice not only saves memory space but allows a CMR encounter recorded in one language to be displayed in another second language subsequently, requiring only the existence of the hierarchical code/phrase in the second language. A free-text Comment is allowed for any related item in a Relational record or CMR, to allow the doctor to add important nuances such as 'worse on arising' or for a numeric result such as a test result or a thermometer reading. Some structuring can be accommodated in the Comment by introducing symbols such as '> relieved by,' followed by a list containing entries such as 'antacids.' Time can be sturctured through symbol lists such as '@-2 mo' representing '2 months previously.' Because Relational records in the knowledge ase and patient encoutner records in the CMR both display findings in hierarchical order; all similar items (e.g., Agents, Clinical Manifestations, Tests, Procedures, etc.) occur together and in an unique order. (abstract truncated)