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