Sam Heard wrote: > Mattias and Tom > > First point Tom has covered - we use the archetype model constraint > classes. These can be made TOTALLY openEHR if required, but I think we > will do better from an acceptance point of view to go with more > generic type names (ie without the DV_). This could be changed in > future if people preferred. > > The issue about using items as the attribute of ITEM_STRUCTURE (an > abstract class) is interesting and one that had not reared its head > for those at Ocean working on this. The fact is that we are using the > path statements as the glue between the classes in the model. This is > how you need them to be when you are applying them - but it is not > strictly the reference model classes. This allows a generic statement > about constraints on an abstract structure such as ITEM_STRUCTURE as > we only need to address items (rather than root, item, items etc). > > The path statements generated from this approach apply in the design > environment and in the run time data collection environment - there > are a lot of advantages in keeping this closely aligned. I believe > that the representation feature on ITEM_STRUCTURE used to be called items!
It probably did. But we should stick to the reference model - it should now be "root" for ITEM_TREE. In the near future, this kind of alignment & checking will be done with a software module that reads a schema expression of the openEHR RM (or an internationally standardised version of the parts of the model from COMPOSITION down) and picks up errors in the archetypes. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
