Questions about the necessity of ITEM_SINGLE
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
Questions about the necessity of ITEM_SINGLE
I model using ITEM_TREE as default in every archetype, except where we might need a table structure. So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does. Heather -Original Message- From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 4 October 2011 6:29 AM To: For openEHR clinical discussions Cc: openehr technical Subject: Re: Questions about the necessity of ITEM_SINGLE Hi Pablo, I agree with your analysis here especially the last one regarding evolution of archetypes. Regards, Rong On 3 October 2011 16:23, pablo pazos pazospablo at hotmail.com wrote: Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- 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 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Questions about the necessity of ITEM_SINGLE
Yes - and if you want to go one further, ITEM_LIST is nothing more than a special case of ITEM_TREE as well. Modelling this explicitly hasn't been extremely useful I believe, especially if weighed against your evolution argument. Sebastian Am 04.10.2011 01:42, schrieb Heather Leslie: I model using ITEM_TREE as default in every archetype, except where we might need a table structure. So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does. Heather -Original Message- From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 4 October 2011 6:29 AM To: For openEHR clinical discussions Cc: openehr technical Subject: Re: Questions about the necessity of ITEM_SINGLE Hi Pablo, I agree with your analysis here especially the last one regarding evolution of archetypes. Regards, Rong On 3 October 2011 16:23, pablo pazospazospablo at hotmail.com wrote: Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- 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
Questions about the necessity of ITEM_SINGLE
I think Thomas has already mentioned that here there is a good possibility of harmonization with EN13606. At the end it seems that we only need single ELEMENTs and a container with list or table semantics. 2011/10/4 Sebastian Garde sebastian.garde at oceaninformatics.com Yes - and if you want to go one further, ITEM_LIST is nothing more than a special case of ITEM_TREE as well. Modelling this explicitly hasn't been extremely useful I believe, especially if weighed against your evolution argument. Sebastian Am 04.10.2011 01:42, schrieb Heather Leslie: I model using ITEM_TREE as default in every archetype, except where we might need a table structure. So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does. Heather -Original Message- From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical- bounces at openehr.org] On Behalf Of Rong Chen Sent: Tuesday, 4 October 2011 6:29 AM To: For openEHR clinical discussions Cc: openehr technical Subject: Re: Questions about the necessity of ITEM_SINGLE Hi Pablo, I agree with your analysis here especially the last one regarding evolution of archetypes. Regards, Rong On 3 October 2011 16:23, pablo pazospazospablo at hotmail.com wrote: Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/4d18e261/attachment.html
Questions about the necessity of ITEM_SINGLE
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. -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/7588c5be/attachment.html
Questions about the necessity of ITEM_SINGLE
Hi Pablo, I agree with your analysis here especially the last one regarding evolution of archetypes. Regards, Rong On 3 October 2011 16:23, pablo pazos pazospablo at hotmail.com wrote: Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- 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 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Questions about the necessity of ITEM_SINGLE
Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111003/732ac796/attachment.html
