Hi Heath,
I think the suggested change was from
CLUSTER[at1033] occurrences matches {0..1} matches { -- Location
items cardinality matches {1..*; unordered} matches {
ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of
measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025, -- Right arm
at0026, -- Left arm
at0027, -- Right thigh
.....
}
}
}
}
ELEMENT[at1034] occurrences matches {0..1} matches { -- Specific location
value matches {
DV_TEXT matches {*}
}
}
}
}
to
ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of
measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025, -- Right arm
at0026, -- Left arm
at0027, -- Right thigh
..... }
}
DV_TEXT matches {*} -- Specific location
}
which is how we would model it now.
As a side-note, ADL2.0 introduces the capacity to formally deprecate an
existing node, which will be very helpful in these sort of situations.
I also favour adding the 'deg' unit to the existing Tilt quantity, as I
think Sebastian suggested, as an alternative (and not making the change
above). That would allow us to add the critical changes in a non-breaking
manner.
Thanks to everyone who has contibuted so far - we still need other
implementer views!!
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected]
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 8 October 2015 at 10:23, Heath Frankel <
[email protected]> wrote:
> The existing versioning rules allow adding new concepts and opening
> constraints such as allowing additional units. These change the md5 hash
> but does require a version /id change.
>
> This is why Sebastian's suggestion technically works, the existing
> obsolete concept still exists and the new concepts can be added for those
> that want to move to the preferred approach.
>
> However, I am concerned about adding new concepts that are in fact the
> same as an existing just represented differently. This is why I suggested
> to add new units to the existing tilt element (opening the constraint)
> rather adding a new concept for tilt with the new units.
>
> I also suggested adding the new representation for body site as a new
> concept but starting to think this is a bad idea since we are duplicating
> the concept and have two ways in the same archetype to represent the same
> concept and worse the concept has two identifiers.
>
> Having said that I suspect the alternative representation is filling a
> slot with a cluster archetype in a template and hence there is no duplicate
> concepts in the same archetype, there is a new slot and the alternate
> representation is in a template instead. Is this any better? Perhaps
> marginally.
>
> Regards
>
> Heath
>
> On 8 Oct 2015, at 6:42 pm, "David Moner" <[email protected]> wrote:
>
>
> 2015-10-08 1:23 GMT+02:00 Heather Leslie <
> [email protected]>:
>
>> It was Sebastian’s suggestion about governing at an intra-archetype level
>> that has caught my attention - marking an existing data element as
>> outdated, and adding a new one as a revision solves the issue of having
>> correct vs incorrect units and avoids the necessity of a new version
>> immediately. I suggest we make this modification to the existing v1 and
>> republish as stable (and technically correct).
>
>
> But that will not be v1 anymore...
>
> At this point, anyone who has worked for a time with the archetypes of CKM
> knows that the readable archetype ID, including the version number, it is
> not a reliable reference to identify the archetypes (this is said somewhere
> in the specifications, but should be more clearly stated for newcomers).
> The only reliable identifier from a technical point of view is the MD5 hash
> of the definition part of the archetype. Any change to the structure will
> create a different MD5. Any (correctly implemented) system that uses it
> will find that it is a new archetype, call it v1, v1+internal revision, v2
> or whatever.
>
> As Diego said, the less complicated solution is to just follow the
> versioning rules that already exist.
>
> David
>
> --
> David Moner Cano
> Grupo de Informática Biomédica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es
> http://www.linkedin.com/in/davidmoner
>
> Universidad Politécnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
> Valencia – 46022 (España)
>
> _______________________________________________
> openEHR-implementers mailing list
> [email protected]
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
> _______________________________________________
> openEHR-technical mailing list
> [email protected]
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
