Peter Johnson <[log in to unmask]> writes:

>I'm emailing you alone with this as I had sent my original email to
>which you replied solely to the gp-uk mailing list, and I haven't
>been involved in any other lists/ other conferences on this subject,
>so I am unaware of the full context in which you have been
>discussing SGML. I take it Gerard Freriks forwarded my email to you
>and others.

He has started -- by other messages coming my way -- one of his
usual thought  and mail provoking multilogues..

>I have no problem with you publicizing the contents of this email
>if you feel it would be helpful to do so .

Dear Pete:

I certainly do... as a lot is to be gained. I picked out your
paragraph from your longer discussion, because I found it to be such
a good straw man to open a broader discussion of perceptions about
SGML and other approaches to  information notation, communication
and storage. It seems to me that once your objectives outlined
immediately below are stated, that SGML is a very plausible way to
proceed:

>My area of interest in this is to aid decision support systems -
>this means using the EMR for a task which the user did not have in
>mind (most likely) when he recorded the entry.  The reason why I
>still pursue this goal, is that there are workers (only a few, I
>admit) in AI who believe that it is possible to get to the holy
>grail of task independent knowledge, and a great many who believe it
>is possible to get close to this, if not actually reach it.  What we
>should be able to achieve is a great improvement on the current
>situation.  That may be enough to achieve what we want.  But I'm
>sure the use of SGML per se isn't going to solve these problems.

I fail to see where your certainty in this matter comes from. There
are good indications, but as yet little data, to hypothesize that SGML
should  address many of these problems, at least in part...

(As an aside, from an interim message to you and by way of an
introduction to the larger audience: I have not consulted
extensively in England since a guest of the NHS and visiting
Professor at St.  Thomas, London in 1972... but issues of how one
should get control of the variability of health care data were
already much debated.)

>Before I start voicing my opinions, and taking issue with your
>reply on this subject, I thought perhaps I needed to get some basic
>facts straight, to make sure we're talking about the same things.

>From my review of your message, we are talking about the same
things, but we see them quite differently.

>a) SGML is being promoted on gp-uk as the answer to everything for
>EMR's.

There is no answer to everything -- so that is an overstatement on
somebody's part. Yours or theirs? I don't know gp-uk, but I take it
that "gp" stands for general practice.

>b) people are taking this seriously

That SGML should be able to address certain issues should be taken
seriously, because there is tentative good evidence that it may help
with a difficult and long-standing problem: the tension between
standards, aggregates and order -- represented in the US by the ICD
(still 9) codes -- and the importance in all of biology and behavior
of individual variation -- which have motivated the development of
SNOMED with its multiple (once five, now nine) axes.

>c) IMHO SGML may well be an enabling technology. but, certainly in
>the UK (and I know things are different in the US) this is not the
>main problem, at least not in primary care. We have EMR's covering
>the majority of the UK population, that have been used for around 10
>years. Thus for primary care in the UK we don't need enabling
>technologies.

That is a strong and sweeping statement and at least points up deep
differences between us in what enabling might mean. It is my
understanding that you have a partially satisfactory coded scheme
for describing a patient's condition based on the Read codes, which
are a further specification of the ICD codes. I have come around to
the point of view that EPR (P=patient) or EHR (H=health) is a better
abbreviation, because the electronic record might otherwise be
limited to such coded facts.

>What we do need are answers to the problems that have arisen from
>the use of our loosely structured EMR's of the last ten years. How
>can we create EMR's which are usable for purposes other than that
>for which they were recorded?

This is exactly where we see the contribution of SGML to be, in which the
many loosely structured documents that contribute to the clinical record,
by virtue of sufficient and appropriate markup, become the stakeholder
neutral and task-neutral carriers of information, interpretable and
extractable by intelligent agents.

>d) The problems facing EMR use in the UK  can be summarized as - we
>lack standardized, closely controlled definitions of concepts used
>in health care, which are independent of the context in which they
>were recorded. This wasn't realized until many years use of loosely
>structured EMR's, when people tried to use the data in these EMR's
>for other purposes.

NOW HERE IS WHERE WE DIFFER! Which came first, categories or the
natural variety of things? In organizing information, does one start
systematically, or does one start otherwise? I stand with Stephen
Gould who finds variation to be the sine qua non of life.[For
example, Gould, Stephen, "Full House;" New York, Random House 1996.]
He states: "Categories are human impositions upon nature (though nature's
factuality offers hints and suggestions in return)." Everything I know from
my background in pathology is that the disease categories to which we
assign specimens and patients are convenient but flawed constructs.  No
matter how well we refine them, they fool us.  I borrow the following from
Alfred North Whitehead: "In all systematic thought, there is a tinge of
pedantry.  There is a putting aside of notions, of experiences, and of
suggestions, with the prim excuse that of course we are not thinking of
such things.  System is important.  It is necessary for the handling, for
the utilization, and for the criticism of the thoughts which throng our
experience.  But before the work of systemization can commence, there is a
previous task -- a very necessary task if we are to avoid the narrowness
in all finite systems... [Thus the framework] should never start from
systemization.  Its primary stage can be termed assemblage." [Whitehead,
Alfred N., "Modes of Thought," New York, Capricorn Books, 1939.]

SGML is an enabling technology that helps us avoid the narrowness of
all finite systems.

>e) Those promoting SGML seem to believe it will solve such failures
>of existing UK EMR's, but I see it making exactly the same mistakes,
>unless there is some universally defined DTD to which every user
>commits. (and thus an 'intelligent agent' can also commit)

See above: "context free categories" are only context free because
the context has been stripped off to make them fit some preconceived
notion, and thus are subject to misinterpretation by omission -- a
sin more difficult to correct than sins of commission.

>To give you some background: UK primary care EMR's use coding
>systems, which result in loosely structured data, similar to that
>available from tagging and DTD's in SGML (In fact, arguably they
>should give you better structured data).

Read codes can certainly annotate a document; however, they are but
one derivative convenience that, like all other coding schemes,
aggregate toward what they are looking for. These are secondary and
interpretive tags that can enrich an otherwise tagged document that
focuses on content as (loosely) categorized observations and
actions.

>Given this loose structure, people have believed they can use the
>EMR for other than it's original intended purpose. By this I mean
>other than the purpose in the mind of the recording HCP while he/she
>was recording the EMR. My definition of the UK HCP's intended
>purposes are
>
> a) to remind the Health Care providers of what they have done,
>what their strategy is, and b) as a medico legal record.

In this regard, the present coded schemes are very cryptic and
condensed. The important context remains in the memory of the HCP.
SGML seeks to get this out in the document.

>The particular hope was that the EMR could be used for
>epidemiological purposes (not usually in the mind of the HCP at
>point of entry).

There are well known confusions that make this difficult. The HCP is
generally in pursuit of a diagnosis or problem statement (which will
suggest the predictable course of the patient and the most prudent
therapy). The codes needed must reflect this (but may not). The
epidemiologist wants to know how it turned out. To borrow from fox
hunting, the epidemiologist is not interested in the chase, but in
the kill. There are points in the clinical record where this
information is approximated, and can be located if it is properly
tagged.

>My hope was to use it as a Knowledge Base about the patient, for DSS
>purposes. Both of these hopes have in the main been disappointed.
>The reasons for this disappointment are:
>
>a) loosely structured data is heavily reliant on the subsequent
>interpreter of that data understanding entirely the context in which
>it was recorded. This isn't evident from the information itself - it
>needs an understanding of the process by which it was recorded, and
>the background of those recording the information (was it a nurse?
>was it a doctor? In primary care? Secondary Care?. Who was it
>exactly? Do we know if they are any good?) All these thoughts pass
>through a human interpreter's mind, and are essential to understand
>how to interpret the record. This ability to interpret background is
>not possible in epidemiological use of the EMR, or DSS use.

We would suggest that you have defined an EMR as the data document
in hand, which has all of the deficiencies that you note. Is exactly
that sort of context (and more) that content and process oriented
(not format oriented) SGML tagging is designed to accomplish --
without predefining what the categories must be -- after all, less
than four years ago in the US we would not have dreamed of the
organizations that have evolved, and the skill mixes that they use.
The categories that you suggest above have already become instant
legacies in many parts of our country, because they do not meet the
richness of the alternatives: was the encounter by a physician's
assistant? was a therapy overruled by a secondary screener, and with
what background? was a medication substituted with or without the
agreement or knowledge of the prescribing physician? We would
suggest that you do not have an EMR/EPR/EHR without such data.

>b) when a health care provider records an entry for one particular
>purpose (medico legal, reminders to themselves and other HCP's) they
>do not record distinctions that are essential for other tasks which
>may be applied to the same data, or if they do record the
>distinctions, they use criteria of definition which are different
>from that required for the new task (e.g. DSS use, epidemiological
>use).

As I understand it, you have a labor intensive recording scheme aimed at
one player in an increasingly integrated practice endeavor.  That is not
an EHR/EPR or even an EMR, at least by our standards.  In a more
interactive on-line scheme, the necessary data are accumulated in the
course of doing business.  However, clearly, this is not yet the case
except in a few settings, which nevertheless are proof of concept. (Not to
mislead, none to my knowledge use SGML.)

>This is a well known problem - drug trial data collection for
>example is specifically tied to that task, usually by using
>questionnaires with tightly defined terms -

Unless you have quite different physicians in practice than we have, labor
intensive questionnaires that do not have a meaningful reward for the
physician or user in question will not be filled out, except under duress.
And under duress they will not be filled out except in a wasteful
pro-forma way.  A good hospital example, is the epidemiology of nosocomial
infections, which presently uses especially tasked nurses as clerks to
collect the data.  Much of it, however, would be derivable from a more
integrated system. Then an evaluation could be made by a knowledgeable
individual examining each case from a terminal using a DSS... with a call
to the floor to resolve ambiguities.

>If for example we are examining the effect of antihypertensive
>agents, the definition of a diastolic blood pressure observation
>suddenly takes on a whole new definition, which *is not* the same as
>a blood pressure observation taken in routine clinical practice (see
>the definition of a blood pressure observation for the MRC trials
>comparing antihypertensive agents for example, defines
>preconditions, how long someone has rested, whether they be sitting
>or lying, which sound to listen to, etc.) Thus the definition of
>something which one expects to be totally quantitative, like
>diastolic blood pressure - it has a value and units - surely it is
>as quantitative as you can get - is quite different when viewed from
>the task of a drug trial.

Good example.However, drug trials, including the data collection are paid
for.  Moreover, the clearer the result the less consistency is needed in
the detail.  When a child in the early 1940s, I was a part of a penicillin
drug trial to establish its possible efficacy against gram positive
bacteria.  The candidates were chosen for our nearly predictable terminal
end points.  Despite the rough and ready nature of the trial, the lack of
a formal second arm, the variations in dose and bioefficacy (the active
material was pipetted off of culture plates), and the many institutions
where it was carried out, the impact was very evident very quickly, almost
by inspection.  Today, many trials seek out very small distinctions, and
some are set up to "sea lawyer" some standard therapy into being.  For
such results to be convincing, cases must be closely matched.

>What I am saying here is that in current medical records, the
>context and definitions are made explicit prospectively - before the
>record is made. The task - the way the record will be used, is
>integrally bound with the record. The record cannot be considered
>valid outside the task/context in which it was recorded.

That is properly observed, and what a SGML markup, properly
introduced, is intended to correct.

>These two problems are fundamental to the hopes for EMR's.  SGML
>offers no answer to them at all.

Now just stop for a minute, and tell me why this is so... as it runs
directly counter to our observations, but perhaps not on the same data..

>Basically they come down to the questions:
>
>1) Is it possible to define the semantics of an EMR (say tags) and
>the terms in a way which makes them task independent? i.e. they mean
>the same if I am to use them for medico legal purposes, or for
>decision support purposes, epidemiology, in primary care, in
>secondary care? (etc.)
>
>2) If I can achieve 1), is it usable in practice, by the normal HCP?
>
>Unless both 1) and 2) can be answered, we have failed in being able
>to use the EMR across care and geographical boundaries, for purposes
>other than that in the mind of the HCP recording the data.

Properly observed... This is the direction we are taking.

>The way SGML is being promoted in the UK for EMR's suggests it will
>answer these problems, while the truth of the matter is that it
>isn't tackling these problems at all.

That may be the case.  I am not sufficiently aware of what is being done in
the UK, and what your thinking is.  However, much thinking has been
influenced by HTML and its quite evident communication and presentation
capabilities.  This does a poor service for SGML, both by skewing the
focus and by presenting an oversimplified impression.  As we see in all
early work, most of the exploration appears chaotic until directions are
worked out.  This is a natural result of assemblage. It is true in every
field.

>In fact by making the suggestion that it answers such problems, and
>makes a medical record widely available outside the context (task,
>geography, ethnic) of it's recording, is downright dangerous, as
>inferences may be falsely drawn in such circumstances.

These are blatant statements for which you surely have some grounds,
but I certainly see the matter differently. The ability to capture
the relevant context by no means guarantees that this context will
be captured, but this is exactly the enabling capability that one is
looking for with SGML -- using content oriented tags modified or
extended by an open ended set of attributes. Getting this done poses
some problems for which we have some technological approaches, using
encounter tablets. Given that the information has been brought
together, nothing will ever prevent false inferences from being
drawn from it. To pick the example before us, starting from the same
ISO standard, the inferences and conclusions that you draw about
SGML are almost exactly the reverse of what we put forth as
considered hypotheses (by no means yet properly tested). Without
these tests, we will never know. (This is not to say that
exploratory tests have not been done , which are encouraging.)

The misinterpretations using SGML, because they are based on
explicit material, are correctable, while the misinterpretations
that derive from data filtered by rigid categories can only be
corrected by collecting the data all over again with new categories.
We see this in clinical trials, such as the lymphoma studies. Of
some necessity, the diagnostic categorization defines the limbs, but
when these categories are found to be biologically flawed, then only
minimal value can be gained by retrospective reevaluation.

>Given this [opinion -- see above], it is my belief that using SGML
>in itself will in no way forward the development of EMR's.

We need testable hypotheses.  Without insight, dedication, and skilled
use, no tool, neither a stethoscope nor a surgical knife, nor set of
computing conventions can further the task set before it.  The real
question is: does the tool in skilled hands make it easier?  Is the tool
enabling?  Once this is accomplished, the experience can be consolidated
for routine practice. All of medical development is like that.

>But deciding what tasks one wants to use an EMR for, and then
>defining a DTD for all concepts one wishes to record, in a way which
>means that all users accept the definitions, will use the tags, and
>can do so in the time available, would be a major leap forward.

But this precommitted focus contradicts your points above -- unless
it means adding an onerous set of questions to given report form --
or unless it suggests a means of (tentatively and automatically)
collecting a broader range of information by a wider reach of
transaction processing.

>But of course there are many other ways of doing this which are
>arguably better, and SGML seems a strange technology to focus on -
>it is just one possible solution of many.

Please suggest some. Clearly, there are well known approaches that
are more efficient, when the task is predefined. However, I fail to
see in your response any examples of  why SGML will not contribute,
and why numerous (but unnamed) alternatives will do a job better,
particularly in creating a knowledge base for DSS or expert systems
to use.

>SGML may well have a place in the communication and storage of
>EMR's.

Those are its strengths

>But it is dangerous for it to be promoted as the answer to
>everything in the way it seems to be at present, as there will be an
>inevitable backlash once it fails.

A morose conclusion before the fact. However, a poor implementation
is always a danger with a new technology, which, in that case, tests
nothing but the novice status of the implementers.  A classic mistake is
to try and use one tool for everything, and to use one that the user is
inadequately familiar with. Imagine you or I building a nuclear reactor!
An amusing book on just this topic of inexperience and overenthusiasm is
"From know-how to nowhere; the development of American technology" by
Elting E.  Morison.  New York, Basic Books [1975, c1974]. His better
known book is "Men, machines, and modern times" Cambridge, Mass., M.I.T.
Press [1966] about absurdities in the rejection of new technologies by
those with an already established position behind older ones.. Both are
a good read!

There is no answer to everything. Rather the best solutions almost
always embody a mixed strategy. I can open a can (you would say
"tin") with an ax, but, unless I am in the woods without other
tools, I would prefer a can opener (do you say "tin opener?"). On
the other hand, I would hate to go after a tree with a Swiss army
knife :-)  However, the Swiss army knife, with its many components,
embodies the mixed strategy for things that can be dealt with in the
small.

BTW: Since we seem to be two countries separated by a common
language, it would be nice of you to follow STANDARD AMERICAN USAGE!
:-) .. but like all other forced standards, this will never come
about (nor should it).

>Are we talking about the same problems?

We are certainly talking about the same problems, but we clearly
have a different understanding of what SGML does and can do.

We in America (for better or worse) have always had a bit of the
libertarian in our blood -- even at the cost of loosing some very
good tea in Boston Harbor. We are suspicious of government except in
times of war and disaster (where the only difference between a
Republican and a Democrat lies in their definition of what a
disaster might be). I think that we get this from the Scots and the
Irish, and, like them, do not take well to regimentation. Thus our
rather diverse and chaotic (and sometimes very unfair) healthcare
system -- if it can be called a system at all.  We see regimentation
in the form of cartoon characters such as Nazi sergeants who are
constantly shouting with a strong accent; "You VILL obey orders!"
(Or those of us with a sense of history hear the distant voice of
George Grenville and the cogent  -- but disregarded --  admonitions
of Edmund Burk... who embodied from his various roots most of our
ideals.)

In the inevitable dialogue between the rules given "top down" and
the requirements that arise "bottom up", we see SGML as offering
structure and order with a malleable soft touch... But only if
implemented with a deep insight into the spirit of the language.


>(btw, do you know a Ka:ren Wiekhart who works for Rand in the bay
>area, I believe? We have had discussions along this line before!)

She is not presently on our roster, and RAND only moves inches
closer to the Bay area from our home in Santa Monica with every
earthquake :-).

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

 p q
 \|/
 /|\   TOM LINCOLN  [log in to unmask]
 \|/  "Life is short, art long, opportunity fugitive,
 /|\   experimenting perilous, reasoning difficult."

			a fine way to spend Saturday afternoon...


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