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 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-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>
