Dear All
As an involved clinician I have been thinking about advantages of using inheritance to relate DATA_STRUCTURES and CLUSTER. This arises from two things we have learned in clinical modelling: 1) At almost every point where a DATA_STRUCTURE is currently specified in the RM it would probably be inappropriate to model any structure other than a ITEM_TREE. This is because any change to this will invalidate existing data and we have learned that information models get more complex with time. So the construct of DATA_STRUCTURE at the moment offers no real value in return for the complexity it introduces as it stands at the moment. 2) A ITEM_TABLE or ITEM_LIST 'constraint' can more usefully appear at any point in the data - even forcing a ITEM_TREE is useful if you can see that specialisation should always allow hierarchical structures. I am suggesting that we change the model to have ITEM_STRUCTURE inherit from CLUSTER. This would mean that ITEM_STRUCTUREs always behaved as clusters (paths etc) but had added features. A ITEM_LIST then becomes a constraint on a CLUSTER to only allow ELEMENTS. And ITEM_TABLE could now appear anywhere in the data. For backward compatibility it would mean that ITEM_SINGLE and its 'item' attribute would have to be made obsolete. In fact an ITEM_LIST with cardinality of 1 offers the same constraint capability. At the moment ITEM_STRUCTURE and HISTORY inherit from DATA_STRUCTURE but I am not sure if that confers any benefit as I do not think that DATA_STRUCTURE is present anywhere in the model. Thomas may want to elucidate this aspect. It may mean that we need a new interface with multiple inheritance in Eiffel if that is important. This does mean that openEHR is more closely aligned with CEN as well - that is to say all data would be clusters with more attributes where ITEM_TABLE was used and more features in software. I am interested in the Techo's response to this idea. Cheers, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100512/219697b8/attachment.html>
