But then what do we do with current implemented adl 1.4 archetypes?
El 8/10/2015 11:56, "Ian McNicoll" <i...@freshehr.com> escribió:
> 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: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 8 October 2015 at 10:23, Heath Frankel <
> heath.fran...@oceaninformatics.com> 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" <dam...@gmail.com> wrote:
>>
>>
>> 2015-10-08 1:23 GMT+02:00 Heather Leslie <
>> heather.les...@oceaninformatics.com>:
>>
>>> 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
>> openehr-implement...@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openehr-techni...@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openehr-techni...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
