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