Hi Diego I think David Ingram has made a valuable contribution; these are empirical solutions to real problems in real systems. The reality of OBSERVATION is that it deals with point in times, intervals ( max, min etc) and analogue readings. These need to be handled consistently or we end up with combinatorial explosion - lab glucose in LOINC is over 200 codes.
Satre said that "belief is confusing things with their names". We need to look at the classes and the utility provided. When we have a small number of archetypes there is no doubt we can manage these things with slots etc. But this requires massive alignment very early in the piece. Cheers, Sam On 21/06/2012 8:19 PM, Diego Bosc? wrote: > Hi Thomas& Ian, > > I see what you mean, and I agree that in its current form > ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there > are other cases where this is still valid (restrict the ENTRY class in > its current form I would say that it has no sense either, but maybe > CARE_ENTRY could be used in the same way). Maybe it is even useful for > those archetypes which is difficult to tell if they are an Observation > or an Evaluation :) > > 2012/6/21 Ian McNicoll<Ian.McNicoll at oceaninformatics.com>: >> Hi Thomas / Diego, >> >> As far as the published archetypes are concerned we will have thought >> fairly carefully about if and when to constrain EVENT to Point or >> Interval, and this is definitely something that should be applied at >> template level in most cases but, as ever, we have to be careful not >> to over-apply constraints when the downstream use cases are not wholly >> clear. >> >> Ian >> >> On 21 June 2012 09:21, Thomas Beale<thomas.beale at oceaninformatics.com> >> wrote: >>> On 20/06/2012 20:30, Diego Bosc? wrote: >>> >>> So you have to select the ITEM_STRUCTURE class but you don't have to >>> select the EVENT class? (most CKM archetypes have now EVENT and not >>> INTERVAL_EVENT or POINT_EVENT) >>> I think it should be allowed/forbidden following only one criteria. >>> >>> >>> >>> in general, there is no harm not choosing a subtype if you are only >>> constraining properties of the supertype. In the case of ITEM_STRUCTURE this >>> doesn't make sense because it is an abstract type with no structure defined; >>> anything you want to constrain will be in a particular subtype. >>> >>> In the case of EVENT however, you can sensibly constrain just EVENT >>> properties, and if you don't force the subtype, you are saying - I don't >>> care if this event happens to be a point event or an interval event, which >>> is entirely reasonable. Although, I must admit I suspect that at least some >>> of those CKM archetypes probably did really intend only a POINT_EVENT, so in >>> some cases, the type constraint should be made. >>> >>> - thomas >>> >>> _______________________________________________ >>> 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 +44 (0)1536 414 994 >> fax +44 (0)1536 516317 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> Clinical Modelling Consultant, Ocean Informatics, UK >> Director openEHR Foundation www.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> SCIMP Working Group, NHS Scotland >> BCS Primary Health Care www.phcsg.org >> >> _______________________________________________ >> 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 >
