 |
 |
[snip lots in discussion between Tom Lincoln and Pete Johnson] Lincoln continues: >>Here (with a distinctly medical flavor in vocabulary) is a tentative >>working outline [for the subset "reports"] to start things off: >> >>1) the source of the problem; >>2) the (sometimes subjective) problem context; >>3) objective data; and >>4) the assessment (stated as problems or diagnoses); with >>5) a plan that can be further divided into >> 5a) actions preemptively taken (not everything can wait); >> 5b) next steps that follow from the assessment; and >> 5c) follow-up to test the accuracy of the assessment and >> affect the reliability of the intended result. and Pete replies: >I agree with this approach, but extensive work of this type has already >been done - both generally and more specifically for medicine. It has in >general been done under the banner of 'data modelling' though, as that is >what it is. (and why I said other tools might better suit this work) That is, of course, correct. Most work revisits older work. HL-7 incorporates a data model, as do many data base designs. One of the problems is the assumption that one can define a static data model "once and for all" in a changing world. SGML offers the possability of taking all of the best ingredients of a data model and placing them in a more locally and globally managable structure, in which a properly aware application can then deal with the changes as they come along. Once again, it seems to depend upon what comes first: flux or fixed categories, and whether both ends of a handshake have to agree in advance about the definitions, or whether the definitions can be shipped along with the data under an agreed upon meta-structure. >One specific example is the Common Basic Specification, and COSMOS clinical >process model developed in the UK NHS - all of the concepts you mention >above for example are represented in this model, which has been developed >over many years. I suppose I need a reference... and perhaps some specific comparisons... [snip: speaking about different local uses of vocabulary, because different groups (most notably surgeons and internists) respond differently to the same vocabulary -- but often different surgeons in different hospitals] >>It is this unstated "village context" about which you are >>complaining, and it arises because communication is largely >>behavioral. We need tools to navigate in such an imperfect world, >>but we must accept its existence. [...] >It does exist, but I am claiming that by careful choice of terminology and >the semantic tags, we can minimise the effect. We do not have to accept it >as something we cannot do anything about. In fact, in my opinion if we are >to have a valid claim of a shareable medical record, we have to tackle this >problem to the best of our ability. It is certainly something we can do something about. First, as you suggest, by a careful choice of generalizations to emphasize the invariant component as explicitly as possible; and secondly using disciplined indirection to manage the variation. Lincoln again... >>Here again it is a matter of man machine interaction, with the >>scope for judgment left to an educated human being. A well tagged >>document makes this combined navigation easier (and on revisited >>documents, cumulatively easier). >I don't argue with this, *but* one of your fundamental claims is that >intelligent agents can use the documents. This implies non-human agents. >Semantic tagging alone is not enough to achieve this. In general, if done properly, one gets a modest oversort, from which non-conforming items or documents can be removed by human judgment or kept as questionable or unresolved ambiguous cases. In the former case, over time a rule can be developed to eliminate these; in the latter case, over time, what data would resolve the ambiguity can be identified, and sought out in the future in an evolutionary, hill climbing manner. [now... out of order:] >I agree with your view of a DSS, But unfortunately you cannot get away >from a computational component making some decisions for you if it is to >be useful(gain from use > cost of use). Typically these are at the >abstraction level from the EMR , and humans don't even think of them as >decisions. For example, "This patient is anaemic" derived from >haemoglobin values. Sounds simple - instant judgement by most clinicians. >But it is very context and temporally dependent. If the patient has >rheumatoid arthritis that suddenly shifts the window of values. How long >is it valid to say they are anaemic for? Even if the haemoglobin was done >this morning, if they had a transfusion afterwards it may no longer be so. >So there are hundreds of little decisions to be made, which you cannot >expect the user to make - it will infuriate the user if they have to >confirm all of these before a DSS will state an opinion. A point well taken. This property limited (and perhaps still limits) the use of Larry Weed's "Knowlege Coupler," and left MYCIN as a decision making tool for the student with lots of time.. Nevertheless what you suggest is partially tactical. Lots of programs (such as drug-drug or drug-disease interactions) screen for the kinds of things that you are concerned about via encapsulated "knowledge frame" rules. Experience seems to indicate that only a few such rules can be activated at the time of writing orders or the like -- or the system disappears into cross checking mode for much to long. Here, however, the priorities are properly defined by what a given set of clinicians are likely to miss. It is useful, for example, for someone setting a sprained ankle in an ER <ER =Emergency Room; = something else in UK> to know that the patient is on coumadin <warfarin sodium>, or has an ulcer... or is already on low dose aspirin... if aspirin is prescribed for pain... [an old chestnut]. However, as the HELP system demonstrates, the system, just like physicians, can walk to most emergent situations.. Moreover, most things can be corrected after the fact by lower priority processing (people, luckily, are resilient), and if an automated (Larry Weed type) consult is sought, the information can be gathered in batch, with data confirmed in a like manner, as further questions are asked. (I believe that he has 200 questions for "pain in the knee" -- but if it DOES turn out to be liquorice :-) A particulary good example of an effective decision support system (whereby David Heckerman received the Association for Computer Machinery annual award for the underlying belief network logic in about 1990 -- the only time a thesis in medical informatics has been given such a prize) is the Intellipath system in anatomical pathology. See: Nathwani B.N., Horvitz .EJ., Heckerman D.E. and Lincoln, T.L. "Integrated expert systems and video disc in surgical pathology: An overview," Human Pathology 21: 11-27, 1990. Here at the interface a diagnosis is arrived at by a kind of Nitendo game as particular features are identified and entered. Significantly, the system is intelligent enough to know when it is not converging on a diagnosis, and suggests that (after a review and verification of the entries) that a real expert be called (like Nathwani!) As in Larry Weeds programs, about 200 observations are possible in a given domaine, but a probability list is updated at every entry. (Entries can be removed or changed to test the system, as one would test a person in training.) Observations can be made in any order, and (as in a chess playing program) one can ask what next observations would maximally discriminate between benign or malignant; or which ones would serve to separate the lead diagnosis from the rest... This thumbnail description does not do justice to the system, but it does serve to note that keeping a professional's interest depends upon how well the interface is designed to retain the user's independence of thought, and how perplexed the user is about the case... Once again, DSS is full of very human variables as well as data ones. I could go on... Tom p q \|/ /|\ TOM LINCOLN [log in to unmask] \|/ "Life is short, art long, opportunity fugitive, /|\ experimenting perilous, reasoning difficult." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%