Thanks for the input; see the wiki page
<http://www.openehr.org/wiki/pages/viewpage.action?pageId=49053703> for
response.
On 02/01/2014 09:41, Diego Bosc? wrote:
> Made a comment on the wiki page, but I will copy that here too:
>
> Still thinking about this, but I have a first doubt:
>
> What is the result of generating the standard equivalent ADL for this
> ADL code? (from the example)
>
> ELEMENT[id31] occurrences matches {0..1} matches {
> value matches {
> DV_CODED_TEXT[id5002] matches {
> defining_code matches {
> [local::
> at31, -- Naked
> at32, -- Reduced
> clothing/bedding
> at33, -- Appropriate
> clothing/bedding
> at34; -- Increased
> clothing/bedding
> at0033] -- Assumed
> }
> }
> }
> }
>
> Do atxx codes get changed to id codes magically or just new idxx are
> generated? new idxx codes or id500x ones? new objects added to the 1.5
> archetype should always have id50xx?
>
> I'm still wondering if the at000N => idN+1 rule and the id5000 rule
> are a good idea. I see a lot of potential problems and not much benefits:
>
> I don't really think that keeping a at->id correspondence is a
> critical issue: The user defining archetypes shouldn't even be aware
> of the changes, and if we want reuse current systems, things like AQL
> paths should still had to be rewritten to deal with the missing atxx
> codes, so not much benefit of having a rule for direct translation.
>
> My suggestion is to keep things as simple as possible and just put
> idxx codes where needed. Maybe it's a good idea to use the at000N =>
> idN+1 rule, but for the missing ones I would just make another pass
> and put new idxx codes starting from the last idxx code we assigned on
> the first pass. As the 1.4 to 1.5 process only has to be done once, I
> think it's better to make two passes to the original archetype and
> just put new idxx codes from now on.
>
> I'm not a fan of having different ranges of id with different
> meanings. With templates being archetypes I won't discard having
> idxxxx with values dangerously near to 5000...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140102/e6b69baf/attachment.html>
