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