On Sat, 28 Dec 2003, Tim Churches wrote: ... > Converters are necessary evils. But having spent far too much time > writing converters (80-90% of any epidemiological or statistical study > is spent in data management and data preparation, which usually means > writing custom converters), I am **very** interested in any means of > having to write fewer of them in the future, not more.
Perhaps more re-use and more automative generation will lead to less need for custom, hand-built converters that you are familiar with? ... > > This like saying if we "standardize English" then we won't have to > > worry about learning new words and slangs. ... > People with strong individualistic traits tend to be suspicious of > standards. This is quite characteristic of many physicians and scientists. ... > > These may be useful - but they are not replacements for converters. > > Thus, they must not prevent development of an adequate "converters" > > infrastructure. > > I have never seen any data dictionary, minimum dataset, terminology or > other "data harmonisation" effort which has said "Thou shall not develop > data converters or converter infrastructure". Never, not once, ever. Promoters of restrictive terminology tend to suggest converters are needed only for "exceptional" cases and ought not be used regularly. Instead of recognizing converters as a desirable part of the semantic network, they tend to see them as necessary evil :-). ... > > As I pointed out repeately, a "constraint language" is not sufficient. We > > also need a "translation" infrastructure. This is exactly why OpenEHR, in > > its current form, is inadequate. > > I agree with you here - that a translation infrastructure is needed - > one that can take data collected in accordance with given metadata, and > automatically convert the data into another form as defined by different > metadata. AFAIK, openEHR does not currently provide that. But I have a > hunch that openEHR may provide an excellent, principled basis on which > to build such converter infrastructure. Maybe you would be willing to help in this effort? ... > > The tricky part is avoiding falling into the same trap our predecessors > > fell into. OpenEHR's emphasis on creating common archetypes suggest it > > may fall into that exact same trap. > > Which trap was that? Focusing on forming political structures to build and promote common archetypes/terminology rather than constructing translator/converter tools. ... > > To the extent that OpenEHR does not provide a translation facility, it > > will be rather hard for humans to create their own unique archetypes and > > make full use of them. > > Sorry, you've lost me there - what does a translation have to do with > the ability to create archetypes? Lack of translation tools leads to significant *disincentives* of organized medicine to permit individual physicians the option of creating their own archetypes. ... > do you mean that everyone should have their own definitions of data > items? Not that they "should" - but that they "can". > With translators between them? Instead of shared definitions? Yes. Without a translator infrastructure in place, "shared definitions" (=restrictive terminiology) will be the only remaining option. > > Pretty soon, some will argue (effectively) that the > > solution to mutually incompatible OpenEHR archetypes will be to agree on a > > standard set of archetypes to use. > > I think the idea is to try to avoid the stage of mutually incompatible > archetypes as far as possible, and skip straight to agreeing on a > standard set of archetypes. Such thinking leads us straight back to SNOMED, HL7, etc. Note that "mutually incompatible" archetypes need not come from "human error" - instead, they can also be caused by lack of "translators"! :-) ... > Information system standards reflect existing constraints, not cause > them. By not providing an infrastructure to support translators, information systems such as the one proposed by OpenEHR will be far more restrictive and less semantically "descriptive" than free text. Organizations that choose to adopt such systems will likely place new restrictions on their physicians' ability to communicate. ... > > The question is _who_ should be allowed to "describe medicine to > > computers"? Should it be the "priesthood" of software engineers? The > > "priesthood" of elitist medical experts? Or "any willing physician"? > > That's a good question, and no-one is sure of the answer yet. That is not so. Through design-decisions that we make when we construct, test, and deply these information systems, we give clear answers to this set of questions. > Certainly the priesthood model has often failed, or often been rather > unsatisfactory. Surprisingly, we often do not act like we learned anything from these lessons. ... > > > It is only possible to standardise those areas in which there is > > > consensus or shared knowledge (or sometime shared belief). That's a lot > > > of medicine, but not all of it. > > > > And who shall decide which fragment of knowledge to carve into stone? > > Yup, a good question. There needs to be a willingness to try new models > of standards development beyond the traditional "expert committee", and > online communication tools can definitely help here. We need much more than communication tools. We need tools that allow "any willing user" to design, deploy, and use their individually authored, "pre-standard" fragments of knowledge. ... > > A classic case of blaming human users for inadequate information > > systems!!! Now, let's whip the human end-users into submission so that > > they won't dare question the wisdom of the perfect machines :-). > > What are you saying here, Andrew - that people shouldn't form > collectives to develop information standards? People cannot develop information standards if they cannot individually construct and use non-conforming, pre-standard fragments. We need to take great care when we construct information systems that we do not squash human involvement and contribution. Designing or building systems that include no provision for supporting ongoing human modification creates huge problems. It is not the human end-users' fault that they had to circumvent restrictive terminology sets by intentionally mis-coding. It is not the fault of human end-users when they set up political hierarchies to agree upon and try to enforce terminology standards. > > > Yes, without collective effort at standardisation we are back to writing > > > zillions of data converters (form-to-form translators), > > > > And - who is too lazy to fit the information system to the needs of human > > users? > > I don't understand to whom you are referring in this comment. We will write translators/converters - if that's what it takes to accurately model real patients. We cannot refuse to write zillions of data converters just because we don't like to write zillions of data converters. ... > > > It doesn't matter how easy it is create new data converters > > > > Sure it does. What if computer software can create these data converters > > without human intervention? > > Exactly! That's the goal. But to do that, we need to describe a lot of > medicine to computers in a way that they can understand. That may be one approach. But, I think there is at least one other approach (which is what we are implementing for the OIO project). ... > Time will tell whether any of these criticisms of openEHR are valid, Time will tell whether OpenEHR will overcome these weaknesses. I don't need more time to know OpenEHR has these weaknesses. > or important. It seems rather too early to venture an opinion. I disagree. Without frank and timely feedback, OpenEHR may languish and we will all suffer for it. If Thomas has issues with any of the critique that I offered, I am willing to discuss the specifics in greater detail. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
