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
