[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."
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
