Hi Bert, The reason that I have pushed to introduce an ENTRY class is to avoid having these kind of arguments!! Fundamentally I think your post beautifully highlights the problem.
At first you rightly complain about the ad-hoc styling and variability of archetypes i.e we need more consistency, more frameworks. more top-level patterns. In theory, I agree, in practice, I could point to the very many inconsistent java coding frameworks available, the very, very many competing code libraries in the open source space and simply assert that trying to enforce consistent style will be impossible. The experience of clinical modellers and the clinical requirements they are trying to model are just too varied to have any realistic prospect of imposing control. Then at the end you say you want more freedom (via the ENTRY archetype) and to let 'a thousand flowers bloom'. This of course will result in even greater variation in the way that archetypes are modelled with no consistency at all. You may be correct that some useful frameworks emerge through competition, but you can be certain that developers will end up using multiple 'frameworks' just as tends to happen in other developments, simply because no clinical modelling team will ever have the capacity to 'drink the ocean'. As I understand it, the idea of the ENTRY sub-classes was to remove some of this variability in the top-level patterns and strike some sort of balance between your two contradictory wishes. That balance may be wrong but I am struggling to understand how you would reconcile the simultaneous need to reduce 'ad-hoc styling' and to increase innovation - these two wishes are completely opposed. The ENTRY sub-classes is an attempt to introduce some sort of framework to clinical models at a very abstract level. Contsys is attempting to do something very similar. I think we probably agree that having a generic ENTRY class will help reduce angst about 'which class is appropriate' and may help people examine alternative approaches but ultimately this will create more variability not less. Ian On 18 February 2014 07:20, Bert Verhees <bert.verhees at rosa.nl> wrote: > Hi Ian, > > Maybe it is hard to find an classified evaluated observation. You are right. > Maybe this is a bad example. > > Maybe it is only a matter of art or style, I am talking about. > > What I see is that there is no congruent style in archetypes. > They are (excuse me, no offense meant) a collection of archetypes written by > several people in several styles. > > (Sorry I have to bring in some styling in this message, it is to keep it > readable.) > > ------------------------------------------------- > Ad hoc styling of archetypes is bad. > ------------------------------------------------- > It is not that one writes an archetype, and everyone agrees that is a good > one, that there does not exist another way to write also a good one, and for > which everyone agrees that it is a good one. > So there is no absolute superiority in the individual archetypes itself. > There is no best archetype. > > It is like having a taxi-company and having cars from different branches > which were good at the moment of buying, good price/quality. The owner was > sharp paying attention, when buying. > So all cars are good, more or less. There are other cars on the market which > are good too. > So all the cars are different, but they have four wheels and are fit and > safe to transport people. > > And then there is a garage maintaining those cars, and for every car the > mechanic needs to find another manual. > The old mechanic who is in the garage long time has no trouble with this. > But younger mechanics, they hate some cars. > > In fact, carwise, that taxi-company is a mess, all cars are good, but they > are all different. Only look how many different types of spare-tires are > needed. > ------------------------------------------------- > Styling of products is good: > ------------------------------------------------- > This is the same with archetypes, they are good ones (I cannot qualify that > anyway), but also the good ones are all different. > > Developers, programmers maybe know what I mean. > There are frameworks, good frameworks, like Turbo C++, old but reliable. > There are many of these, also in Java or Pascal, or maybe Eiffel. > > Developers who don't use frameworks are less productive, make more errors, > and write harder to maintain code. Have to invent the wheel many times. > When you read frameworked sourcecode, you know at forehand how things are > solved, because the frameworks have a preferred way. > > It would be nice if there could exist congruent frameworks of archetypes. A > new competition-playfield would come to life. > Which university, which company writes the best framework of medical > data-classification and worked out in the best styling of archetypes? > > Turbo Archetypes! > ------------------------------------------------- > Change is the only way to improve things. > ------------------------------------------------- > We are in a lucky time, we have two-level-modeling software. We can write > our own frameworks. > We can express ideas about classes and ideas about styling. > > But there are still some legacy-ideas: maybe good ideas, but still, they do > not fit on some new ideas which might be good too, so these legacy-ideas are > blocking innovation. Because they are enforced in the RM. > > And of course, most medical data-analyst like the (in Netherlands we call it > SOEP) idea of four nouns to classify medical data. It is not for them > freedom is important. They just want to be productive. > Those are important people, they cure other people. But there are also > people, who want to rethink things. Some of those write the guidelines for > tomorrow. > > To have true and innovative advantage of two level modeling, we need a RM > that stands back as much as possible. > > Let thousands flowers bloom, and let for example, CIMI, trying to be one of > these blooming flowers. > > But as Thomas already mentioned yesterday, we will get the generic > ENTRY-class, I don't know how it looks like, but that seems good news. > Maybe it was not meant for this, it will surely fit in the idea to give > freedom in innovation. > > I still wonder why the OpenEHR-community decided to have a concrete > ENTRY-class. > > Best regards > Bert > > Ian McNicoll schreef op 17-2-2014 23:17: > >> Hi Bert, >> >> I think the problem here is that many people get hung up on the idea >> of the ENTRY classes being a formal classification upon which some >> sort of abstract computing will take place e.g. query for all >> OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the >> philosophy and do not focus on the utility. In other words if I >> weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will >> be lost computationally. >> >> I think there is value in having a true generic ENTRY since it avoids >> getting into these kind of marginal ontological discussions but I >> still think there is place for the more complex constructs where these >> make sense i.e when data requires a consistent date/event pattern as >> in OBSERVATION or to support consistent state machine behaviour as in >> ACTION. >> >> I'm not sure that you gain a whole lot from moving these more complex >> constructs into the archetype layer. either you force modellers to >> recreate the structures de-novo, or you end up inheriting from a set >> of reference top-level archetypes which have to be just as tightly >> constrained and controlled as if they were in the RM. >> >> Although CIMI has decided to move 'domain semantics' to the archetype >> layer, there is also an intention to model against top-level >> archetypes and to enforce quite struct adherence to 'patterns'. I'm >> not convinced that this will actually end up being much different from >> where we are now, in terms of flexibility. >> >> I don't find the examples of 'Interpreted Observations' convincing. To >> me, an EVALUATION is an interpretation that applies to the person as a >> whole, not just to a specific test or set of findings. A radiological >> diagnosis of 'Lung cancer' is always for me an Interpretative >> statement about the chest x-ray - not the patient. The only place that >> the person reporting a lab test is the same as the person making the >> formal diagnosis might be in haematology. It is interesting that the >> haematologists use the term 'synthesis' to describe the final >> diagnostic assessment which relies on much more than their >> interpretation of the blood film and count. >> >> In any case, if I did create an EVALUATION.blood_count archetype and >> later think that this might 'ontologically' be an OBSERVATION, I would >> see no reason to change it. We are not trying to do reasoning on the >> Entry class category. >> >> Ian >> >> >> >> >> >> On 17 February 2014 19:30, Bert Verhees <bert.verhees at rosa.nl> wrote: >>>> >>>> Bert, >>>> >>>> I don't really understand this. The clinical modellers will decide on >>>> Observation or Evaluation, and build their archetypes and templates. The >>>> paths will come from the archetypes, whatever their choices were. There >>>> might be occasionally some ambiguity for clinical modellers, but once >>>> they >>>> decide on their model, there's no ambiguity. >>>> >>>> What innovation are you seeking that is being blocked? >>> >>> >>> I was looking at the CIMI model, other models are possible too. >>> >>> Suppose you don't care at design time what kind of Clinical Noun you are >>> classifying, but you describe your data you want to store using a code, >>> maybe SNOMED, maybe a section of SNOMED which does not exist right now. >>> Innovation is a future thing. Let the people afterwards decide how to use >>> the data. >>> >>> For example, say an Observation becomes a Evaluation, because there were >>> reasons to observe something, or a gray area Observation, like an >>> interpreted combination of ECG, radiology. A mixture between complex >>> measurement-data and evaluation. Maybe some data-analyst find the strict >>> separation of observation and evaluation artificial. >>> >>> Whatever, there is not always a clear reason to classify it in one of the >>> four nouns, it could be possible that you afterwards just search for that >>> SNOMED code which is not yet invented. Because you designed a rigid >>> structure, you always know the path to that code, and you always know the >>> path to the datetime. Maybe you don't know what you are looking for, a >>> mysterious decease, and you are just scanning data, or you are >>> datamining, >>> searching for non-obvious relations between deceases. >>> >>> Suppose your rigid structure looks like this, always this model, except >>> the >>> Value, which can be more complex, depending on what it is. >>> >>> ENTRY[at0001] >>> Single_Item[at0001.1] >>> CLUSTER[at0001.1.1] >>> DateTime[at0001.1.1.1] >>> Code[at0001.1.1.2] >>> Value[at0001.1.1.3] >>> >>> You see, this is not possible in the current RM, first because there is >>> not >>> yet a generic ENTRY (except the hesitater-generic-entry, which no-one >>> wants), second, because there is no complex structure possible under a >>> CLUSTER, so the rigid structure here needs some adjustment. ;-) >>> >>> But it illustrates what I want to say, there is always a Code at the same >>> path and archetype_node_id, and there is always a datetime under same >>> condition. This should give special opportunities, only because from >>> point >>> of view of indexing, but in more aspects, and of course, it needs more >>> thinking, this is just an illustration. >>> >>> But the point is: >>> It is a semantic structure, completely defined in archetypes. It is an >>> archetyped schema. This is no chaos, this is order. >>> And it is making true the promise of two level modeling. All modeling is >>> in >>> second level. >>> >>> This should create a complete new playground for medical data-analysts. >>> Innovation can go its way, there are no semantic boundaries. >>> >>> The only thing needed for this is a generic non-semantic RM, like the EHR >>> section in 13606 is more or less, and the next version of OpenEHR will >>> be, >>> as you say. >>> >>> Maybe you cannot imagine anything at what I am saying here, my wife can't >>> (she is a GP), but still you have decided to make of ENTRY a concrete >>> class, >>> although there already was a GENERIC_ENTRY. Why is that, if it is not for >>> the reasons I mention? >>> >>> Thanks, >>> Bert >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
