Hi all, very interesting discussion. > Another use case is when valid children types are part of the same > class hierarchy (no need for specialization). Do we need at-codes when > we create siblings such as DV_TEXT and DV_CODED_TEXT?
according to the current rules (see my previous post), yes. I would actually still rather avoid this, and am still thinking about it... Thinking about this case, shouldn't be a better design approach to define DV_TEXT at the base archetype, and the DV_CODED_TEXT alternative (with further constraints) in a specialized archetype? So the issue of the codes dissapear and anyone can choose to use the very generic archetype or the specialized one. This is good from an Object Oriented design approach, but right now the specializations defined on the CKM are very specific concepts, not just a way to simplify modeling and reuse of artifacts (as it is in the case I mentioned).I mean, the specialized archetype is not a more specific concept, is just the same concept with just "a little" more detail. E.g. if we take "Healthcare service request" and "Imaging examinaton request", the specialized archetype I would create sits right in the middle of those concepts, in fact is closer to the more generic one. In short, I don't know if this should be defined at the model level or at the modeling proess level. BTW, I aggree with Bert in that we need interoperable archetype design tools. Back in 2009 we needed to choose an editor, and we tested LiU, Ocean and LinkEHR, and we couldn't load an archetype created by one tool into another tool :-/ Maybe now this has improve. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com > Date: Tue, 27 Aug 2013 20:47:11 +0100 > From: thomas.beale at oceaninformatics.com > To: openehr-technical at lists.openehr.org > Subject: Re: Polishing node identifier (at-codes) use cases. > > On 27/08/2013 18:20, Diego Bosc? wrote: > > The problem with this rules come with the (explicit or implicit) > > specialization of single attributes. take this example: > > > > ELEMENT[at0009] occurrences matches {0..1} matches { -- Position > > value existence matches {0..1} > > matches { > > DV_TEXT occurrences > > matches {0..1} matches {*} > > } > > } > > > > What happens if a DV_TEXT is added on the specialization? Does it need > > at code? Do we consider the rule to be applied to the archetype + > > parent or only to the archetypes? Do we need to add an at-code also to > > the parent? > > If it were added in a specialisation with no code, it would be assumed > to be a redefinition of an existing DV_TEXT constraint, assuming there > was one. If added with a code, the post flattening validation (phase 3) > in the current ADL workbench would need to detect this. Right now it > doesn't have checks in that phase for this. I'll have to run this > example through the compiler to see what it does. > > > This would need either a rewriting of the rule to state the issue with > > flat archetypes or a potential problem if an at-code is not specified. > > good point; the rules should specify that they apply to flattened > archetypes, which means that ids are required even if each > specialisation child introduces only one alternative. I'll fix this in > the spec. > > > > > Another use case is when valid children types are part of the same > > class hierarchy (no need for specialization). Do we need at-codes when > > we create siblings such as DV_TEXT and DV_CODED_TEXT? > > according to the current rules (see my previous post), yes. I would > actually still rather avoid this, and am still thinking about it... > > > If we have several different data types, such as DV_BOOLEAN, > > DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT, > > which one of the data types gets an at-code? all? only the text ones? > > none? > > according to the previous rules, none. But DV_CODED_TEXT would be > treated as a preferential constraint over DV_TEXT due to the RM > inheritance relationship. It would be up to apps and tools to make use > of that. > > > > > Again, rewording/clarification is needed or problems may occur. > > yes - I doubt that we are at the final version of the wording on this - > but have a look at the new version and see what you think. > > > > > What is so wrong about having at-codes in every class of the archetype > > with no ontology definition for that code? > > interesting question - so far (10 years!) we have always treated an > at-code as something that is in the ontology. At the moment no tools at > all would handle the assumption that only some codes had definitions; it > would raise questions: how do you know which things need definitions and > which don't? My guess is that there would need to be a special > definition that is connected to the at-codes you want to have no > definitions, which would complicate the archetype ontology section > structure. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/75c6767e/attachment.html>
