Hi Tom

At 16:30 29/12/96 PST, you wrote:
[PJ >> TL >]
>>Some of the advantages - the 'loose structure' which sounds very
>>appealing up front, turns out to be a major limitation when one tries to
>>use the medical record for other tasks, or in other geographical
>>locations.
>
>I think that this depends upon how much responsibility one wishes to
>allocate directly to computational components, and how much to human
>judgment.  My view of a DSS is that it is no more than that, a support
>system that, like an automobile, needs a driver. Hard to send a car to
>the supermarket to do the shopping...

I do not expect the car to go to the supermarket for me, but I do expect
when I step on the brake that the car doesn't ask me "I think you are
intending to slow the car, can you confirm this?", "The car weight has
shifted towards the front now we are braking, Do you confirm this, if so I
will reduce the fluid pressure in the back brakes so they don't skid?", "The
front wheel looks as though it might be locking up, do you confirm that, if
so I shall use the ABS?"

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.

By carefully selecting terms and the possible relations of those terms, and
what they mean, it is possible to achieve medical records which can be used
by intelligent agents for other tasks. But we cannot ignore this problem,
and it is a large one.

[snip]

>...To my mind we are trying
>to do two things with a common set of conventions: 1) As you suggest,
>extract a context free outline that serves as a general framework of
>common agreement and expectation; and 2) reintroduce and specify
>the particular context of a particular circumstance by annotation.
>One can add the already well explored coding tags as a third component.
>
>At some level, to achieve 1), the context should not even be medicine or
>healthcare more broadly. It should be a true test of such an outline that
>it be domain independent (one is tempted to say, just as SGML is domain
>independent). We have tentatively started to work on this problem, and
>suggest a sketched outline -- by no means definitive, but useful for
>demonstration purposes. Just as one can identify a formalism called a
>"memo" which has certain expected components, one can identify
>another called a "report." (In many ways a report resembles another
>conventional structure called a "logical proof," where a problem has
>been formulated and solved in one way and is now presented for the
>audience in another, cleaned up arrangement -- one would seldom
>suppose that any significant problem was ever solved the way a proof
>is presented.) Likewise, a report is a rearrangement of observations,
>facts and  conclusions in an expected format. Such a report has
>identifiable pieces, although in any given instance some may be
>missing and others may be markedly elaborated upon. (In the same
>way that books have chapters, sections, and paragraphs.) One kind
>of medical document is a report, which may come in many specific
>flavors from numerous different sources. Only the most general
>outline is common to all, but tagging this outline starts the process.
>
>Here (with a distinctly medical flavor in vocabulary) is a tentative
>working outline 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.

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)

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.

Work on medical ontologies in the AI and Philosophy world is tackling the
same problems.

>[...] This
>would be true of a surgical pathology report, where the diagnosis
>is often chosen with an implicit recommendation in mind.
>Indeed, the terminology may differ from institution to institution
>depending upon how the surgeons respond.
>
>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.

>
>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.


Pete

---
Peter Johnson
[log in to unmask]
(+44) 1525 261432



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%