Hi Sam, The problem with this is that we currently use the RM inheritance to assist in these structure constraints, i.e. an ITEM_LIST only contains a CLUSTER containing only ELEMENTs. However, if you think about it, the semantics of CLUSTER and ITEM_TREE are equivalent. It is only the level in the model that is different. The question is, would it be helpful to have other ITEM_STRUCTURE subtypes within an ITEM_STRUCTURE, i.e. an ITEM_TREE containing an ITEM_LIST or ITEM_TABLE. This is certainly the case in CEN13606 with the mandatory CLUSTER.structure_type attribute.
I think we need to go back and ask, why are we trying to simplify ITEM_STRUCTURE? Are we doing it to simplify the RM, archetypes or data? For me the data is of interest and it is about 10 years since I first questioned Thomas about the need for ITEM_STRUCTURE. Not only does it lengthen paths but it requires a whole level in data that is necessary and requires mandatory structural only attribute values such as node_id and name. >From a domain model perspective I see the value of supporting additional properties and methods on these sub-classes but in a persistence model they add no value, we just need to know which domain class to materialise. In XML this can be done using the built-in schema type attribute and this approach would support XML-class generator libraries, whereas using the CEN 13606 model defined attribute would require an additional adapter to materialise the domain model class. My point is, we probably need to separate the RM representation from the persistence ITS. Even with the current RM, we could probably simplify the XML schema to collapse this level of data, although we still need a way to represent the mandatory node_id and name attributes of the ITEM_STRCTURE. This would be easier if they were not mandatory, but that is topic for another day. However, if we want a RM change with migration path, the minimal change that I can see is to make ITEM inherit from ITEM_STRUCTURE. We could make the ITEM_SINGLE, ITEM_TREE, ITEM_TABLE and ITEM_LIST sub type of CLUSTER but the only true sub type of CLUSTER is ITEM_TREE. In future we could merge CLUSTER and ITEM_TREE and remove ITEM_SINGLE. Regards Heath From: openehr-clinical-boun...@openehr.org [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Monday, 10 October 2011 1:40 PM To: 'For openEHR clinical discussions' Subject: RE: Questions about the necessity of ITEM_SINGLE Hi My (clinician?s thinking) idea was to have ITEM_STRUCTURE inherit from Cluster (it is a fancy one anyway). This would make ITEM_TREE and ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster to only allow ELEMENTS. ITEM_TABLE could then have additional attributes . Cheers, Sam From: openehr-clinical-boun...@openehr.org [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Thursday, 6 October 2011 5:22 AM To: openehr clinical Subject: RE: Questions about the necessity of ITEM_SINGLE Done: http://www.openehr.org/issues/browse/SPECPR-74 -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos _____ Date: Tue, 4 Oct 2011 17:07:27 +0100 From: thomas.be...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: Questions about the necessity of ITEM_SINGLE On 04/10/2011 16:18, pablo pazos wrote: Hi! Your comments are very interesting, and I think we all converge to the same point. For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package. We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future. Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists. yep there is - post a problem report issue here <http://www.openehr.org/issues/browse/SPECPR> . - thomas _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111011/b4e1bef9/attachment.html>
