date:20170615

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Bert Verhees

First reaction, I need to reread your reply carefully. We also have an MD5
key as part of the archetype to detect changes. What does the build_uid add
to this? I discovered that the template - editor uses the MD5 key for that
purpose.

But I come back to this tomorrow.

Bert

Op vr 16 jun. 2017 00:24 schreef Thomas Beale :

> from here
> 
> :
>
> Two machine identifiers are defined for archetypes. The ARCHETYPE.*uid* 
> attribute
> defines a machine identifier equivalent to the human readable ARCHETYPE.
> *archetype_id*.*semantic_id* , i.e. ARCHETYPE_HRID up to its major
> version, and changes whenever the latter does. It is defined as optional
> but to be practically useful would need to be mandatory for all archetypes
> within a custodian organisation where this identifier was in use. It could
> in principle be synthesised at any time for a custodian that decided to
> implement it.
>
> The ARCHETYPE.*build_uid* attribute is also optional, and if used, is
> intended to provide a unique identifier that corresponds to any change in
> version of the artefact. At a minimum, this means generating a new UUID for
> each change to:
>
>-
>
>ARCHETYPE.*archetype_id*.*release_version*;
>-
>
>ARCHETYPE.*archetype_id*.*build_count*;
>-
>
>ARCHETYPE.*description*.*lifecycle_state*.
>
> For every change made to an archetype inside a controlled repository (for
> example, addition or update of meta-data fields), this field should be
> updated with a new UUID value, generated in the normal way.
> - thomas
>
>
> On 15/06/2017 23:09, Bert Verhees wrote:
>
> Seems that the story is not finished yet. Someone in a project I work made
> the joke to rename HIER_OBJECT_ID to ANY_KIND_OF_ID, because it can
> represent almost any type of id.
>
> What is the official defined purpose of the Archetype.uid property?
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Thomas Beale

from here 
:


Two machine identifiers are defined for archetypes. 
The|ARCHETYPE|.|/uid/|attribute defines a machine identifier equivalent 
to the human readable|ARCHETYPE|.|/archetype_id/|.|/semantic_id/|, 
i.e.|ARCHETYPE_HRID|up to its major version, and changes whenever the 
latter does. It is defined as optional but to be practically useful 
would need to be mandatory for all archetypes within a custodian 
organisation where this identifier was in use. It could in principle be 
synthesised at any time for a custodian that decided to implement it.


The|ARCHETYPE|.|/build_uid/|attribute is also optional, and if used, is 
intended to provide a unique identifier that corresponds to any change 
in version of the artefact. At a minimum, this means generating a new 
UUID for each change to:


 *

   |ARCHETYPE|.|/archetype_id/|.|/release_version/|;

 *

   |ARCHETYPE|.|/archetype_id/|.|/build_count/|;

 *

   |ARCHETYPE|.|/description/|.|/lifecycle_state/|.

For every change made to an archetype inside a controlled repository 
(for example, addition or update of meta-data fields), this field should 
be updated with a new UUID value, generated in the normal way.


- thomas

On 15/06/2017 23:09, Bert Verhees wrote:
Seems that the story is not finished yet. Someone in a project I work 
made the joke to rename HIER_OBJECT_ID to ANY_KIND_OF_ID, because it 
can represent almost any type of id.


What is the official defined purpose of the Archetype.uid property?



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Bert Verhees

Seems that the story is not finished yet. Someone in a project I work made
the joke to rename HIER_OBJECT_ID to ANY_KIND_OF_ID, because it can
represent almost any type of id.

What is the official defined purpose of the Archetype.uid property?


Op 15 jun. 2017 19:41 schreef "Pablo Pazos" :

> Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have
> to start with a specific arc 1. or 2.
>
> http://www.oid-info.com/cgi-bin/display?tree=
>
> On Jun 15, 2017 4:33 AM, "Bert Verhees"  wrote:
>
>> Although the OID and UUID as used in the archetypes are (in the most
>> simple (one arc) OID-occurrence) technical interchangeable is their
>> semantical meaning completely different. So what do we want to express
>> here? Is it ever used in the way a OID is meant to be used? (to trace back
>> the organization that is responsible for creating/maintaining the archetype
>> and assign a purpose/meaning to the archetype)
>>
>> The OID is a paper tiger, it suggests something, with structured meaning,
>> but no organization I know has the overhead of maintaining useful use of
>> OID's in archetypes implemented. That is why, also, they do not occur in
>> CKM and no-one ever complained about that, for ten years. No software I
>> know is interpreting the arcs of the OID in the uid-property of an
>> archetype, it would run into trouble when it did. The tooling (including
>> CKM) has no way to support administrative overhead.
>>
>> That the use of OID in the uid-property of archetypes is not useful, is
>> illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x
>>
>> When remaining to the OID in 1.4.x, we create an illusion, we suggest
>> some structure in the uid-property which is not there. In fact opposite, we
>> suggest that all archetypes are to be maintained by different organizations
>> because they have a different uid and only one arc.
>>
>> The problem I have is that the current situation with OID in the
>> uid-property corrupts the administrative use. We write a UUID, we call it
>> OID but we treat it as a UUID, because the practical use does not allow to
>> see it as a meaningful structure.
>>
>> Bert
>>
>>
>>
>>
>> On 15-06-17 03:17, Heath Frankel wrote:
>>
>> Hi Thomas,
>>
>> Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used
>> for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value
>> attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID.
>>
>>
>>
>> The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a
>> XML schema perspective as UUID is a simple type with a restricted string
>> value while HIER_OBJECT_ID is a complex type with a child element value.
>> The V1.4 AOM XML schema uses this HIER_OBJECT_ID type (as per the AOM
>> specification) and since the OPT schema inherits this model, it also uses
>> this type and all OPTs generated by CKM (and the template designer)
>> populate the uid element with the template GUID specified in the OET file.
>>
>>
>>
>> I suggest that the ADL 2 specification is that one that needs to change
>> or there needs to be a specified mapping between the two.
>>
>>
>>
>> Regards
>>
>>
>>
>> Heath
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org ] *On
>> Behalf Of *Thomas Beale
>> *Sent:* Thursday, 15 June 2017 5:40 AM
>> *To:* Openehr-Technical 
>> 
>> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
>>
>>
>>
>>
>>
>> Bert picked up an anomaly in this PR
>>  that I think should
>> probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but of
>> type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the openEHR type
>> for OIDs). However it appears that all ADL1.4 archetypes that have a uid
>> have it as a Guid (i.e. UUID), and I assume the various tools do as well.
>> We avoid Oids like the plague in openEHR, and I am not aware of them being
>> used anywhere.
>>
>> If we can verify that everything assumes a UUID for this field, then the
>> spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this
>> as an error correction.
>>
>> Could tool makers check this issue and report here?
>>
>> thanks
>>
>> - thomas
>>
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Team, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>> 
>>
>>
>> ___
>> openEHR-technical mailing 
>>

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Pablo Pazos

In 1.4 the description of Archetype.uid saying "OID..." is incorrect. It
should say "UID root with no extension".



On Jun 15, 2017 7:50 AM, "Thomas Beale"  wrote:

>
> On 15/06/2017 02:17, Heath Frankel wrote:
>
> Hi Thomas,
>
> Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used
> for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value
> attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID.
>
>
> Right. I was skimming over that detail... I remember now the logic of this
> choice - we originally thought we should accommodate UUIDs (Guids) and
> OIDs, which does require a HIER_OBJECT_ID in the openEHR type system.
>
>
>
> The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a
> XML schema perspective as UUID is a simple type with a restricted string
> value while HIER_OBJECT_ID is a complex type with a child element value.
> The V1.4 AOM XML schema uses this HIER_OBJECT_ID type (as per the AOM
> specification) and since the OPT schema inherits this model, it also uses
> this type and all OPTs generated by CKM (and the template designer)
> populate the uid element with the template GUID specified in the OET file.
>
>
>
> I suggest that the ADL 2 specification is that one that needs to change or
> there needs to be a specified mapping between the two.
>
>
>
> from the point of view of continuity, that is probably correct. However we
> wouldn't need to do that just in order to maintain XSD compatibility - we
> can maintain the XSD HIER_OBJECT_ID type in that field, in a version of the
> AOM2 XSD that aims to be compatible with the AOM1.4 XSD, while in a more
> efficient AOM2 XSD which we might write, it would just be a restricted
> string field, i.e. a UUID.
>
> I am more inclined to make the AOM2 specification, which is normative, as
> clean as it can be. And since it has other breaking changes, having this
> one as well is not problematic.
>
> I also think that the AOM1.4 spec is correct as it is, given what Heath
> says above. So really it comes down to how we treat XSDs and XML, not the
> normative models of archetypes.
>
> - thomas
>
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Pablo Pazos

Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have to
start with a specific arc 1. or 2.

http://www.oid-info.com/cgi-bin/display?tree=

On Jun 15, 2017 4:33 AM, "Bert Verhees"  wrote:

> Although the OID and UUID as used in the archetypes are (in the most
> simple (one arc) OID-occurrence) technical interchangeable is their
> semantical meaning completely different. So what do we want to express
> here? Is it ever used in the way a OID is meant to be used? (to trace back
> the organization that is responsible for creating/maintaining the archetype
> and assign a purpose/meaning to the archetype)
>
> The OID is a paper tiger, it suggests something, with structured meaning,
> but no organization I know has the overhead of maintaining useful use of
> OID's in archetypes implemented. That is why, also, they do not occur in
> CKM and no-one ever complained about that, for ten years. No software I
> know is interpreting the arcs of the OID in the uid-property of an
> archetype, it would run into trouble when it did. The tooling (including
> CKM) has no way to support administrative overhead.
>
> That the use of OID in the uid-property of archetypes is not useful, is
> illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x
>
> When remaining to the OID in 1.4.x, we create an illusion, we suggest some
> structure in the uid-property which is not there. In fact opposite, we
> suggest that all archetypes are to be maintained by different organizations
> because they have a different uid and only one arc.
>
> The problem I have is that the current situation with OID in the
> uid-property corrupts the administrative use. We write a UUID, we call it
> OID but we treat it as a UUID, because the practical use does not allow to
> see it as a meaningful structure.
>
> Bert
>
>
>
>
> On 15-06-17 03:17, Heath Frankel wrote:
>
> Hi Thomas,
>
> Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used
> for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value
> attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID.
>
>
>
> The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a
> XML schema perspective as UUID is a simple type with a restricted string
> value while HIER_OBJECT_ID is a complex type with a child element value.
> The V1.4 AOM XML schema uses this HIER_OBJECT_ID type (as per the AOM
> specification) and since the OPT schema inherits this model, it also uses
> this type and all OPTs generated by CKM (and the template designer)
> populate the uid element with the template GUID specified in the OET file.
>
>
>
> I suggest that the ADL 2 specification is that one that needs to change or
> there needs to be a specified mapping between the two.
>
>
>
> Regards
>
>
>
> Heath
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *On
> Behalf Of *Thomas Beale
> *Sent:* Thursday, 15 June 2017 5:40 AM
> *To:* Openehr-Technical 
> 
> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
>
>
>
>
>
> Bert picked up an anomaly in this PR
>  that I think should
> probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but of
> type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the openEHR type
> for OIDs). However it appears that all ADL1.4 archetypes that have a uid
> have it as a Guid (i.e. UUID), and I assume the various tools do as well.
> We avoid Oids like the plague in openEHR, and I am not aware of them being
> used anywhere.
>
> If we can verify that everything assumes a UUID for this field, then the
> spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this
> as an error correction.
>
> Could tool makers check this issue and report here?
>
> thanks
>
> - thomas
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Bert Verhees


On 15-06-17 12:49, Thomas Beale wrote:



On 15/06/2017 02:17, Heath Frankel wrote:


Hi Thomas,

Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is 
used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a 
value attribute of type UID, which may be either UUID, ISO_OID or 
INTERNET_ID.




Right. I was skimming over that detail... I remember now the logic of 
this choice - we originally thought we should accommodate UUIDs 
(Guids) and OIDs, which does require a HIER_OBJECT_ID in the openEHR 
type system.


That is right, the loadValue function creates a UUID from the 
root-value  if it has that specific string-pattern. So the root of a 
HIER_OBJECT_ID can always be a UUID. Nifty construct. My mistake also, 
sorry for the trouble


Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR-technical Digest, Vol 64, Issue 21

2017-06-15 Thread William Goossen


Thank you Thomas,

The use of URI's is well known, but just not fitting with the billions 
of HL7 v3 implementations. As long as identification is correct each 
variant of ids is fine.


I partly agree to your point here:

codeSystem="2.16.840.1.113883.6.96

This is not how it normally appears in an DCM or HL7 v3 message and i suggest 
should not appear in an archetype.
Normally it reads like

Re: openEHR-technical Digest, Vol 64, Issue 19

2017-06-15 Thread Thomas Beale


Hi William,

this issue here is a specific one about machine identifiers for 
archetypes. There is no need to use OIDs for that purpose, although the 
1.4 specification allows both OIDs and UUIDs.


There is no use in identifying SNOMED CT with an OID. SNOMED CT 
identifies itself with URIs, i.e.  the following, from the SNOMED URI 
standard 
:


http://snomed.info/sct/{sctid} e.g. 
http://snomed.info/sct/9000207008 (SNOMED CT International Edition)


http://snomed.info/sct/{sctid}/version/{timestamp}

FHIR also uses URIs, not OIDs, to identify terminology entities. OIDs 
were an idea that was pursued in HL7v3 vocabulary and by extension CDA, 
but I don't believe they have proven useful. Seeing the following in 
data is just not helpful:


codeSystem="2.16.840.1.113883.6.96

None of this is to say that openEHR can't handle OIDs; it can, that's 
precisely why it has the OID type 
, 
and also HIER_OBJECT_ID type which enables OIDs or UUIDs to be used in a 
particular field of a model. But the global trend in identifying all 
terminology entities is the URI, not the OID.


- thomas


On 15/06/2017 05:43, William Goossen wrote:

Dear all,

If openEHR wants to be really interoperable, it must have a mechanism to handle 
OIDs. Billions of specifications and standards in health informatics are 
deploying OIDS.
Comparing them with the plague, probably in analogy with viruses and worms, 
does not help to solve issues.
How for instance would you be able to exchange SNOMEDCT based coded data e.g. 
In an HL7 v3 CDA that is populated with archetypes and requires SNOMEDCT being 
identified with its OID. Here in the Netherlands we run 200.000.000 v3 messages 
a year through the national switchboard and minimum 250.000 annually for the 
perinatal registry.
One single message instance contains usually between 10 and 1200 single data 
elements, each with a minimum of one OID. If openEHR wants to play some role in 
this, handle OIDs so that communication partners can understand you.

Such decisions should be based on rational underpinnings, not on biased 
preference.

Vriendelijke groet,

Dr. William Goossen




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Thomas Beale



On 15/06/2017 02:17, Heath Frankel wrote:


Hi Thomas,

Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is 
used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a 
value attribute of type UID, which may be either UUID, ISO_OID or 
INTERNET_ID.




Right. I was skimming over that detail... I remember now the logic of 
this choice - we originally thought we should accommodate UUIDs (Guids) 
and OIDs, which does require a HIER_OBJECT_ID in the openEHR type system.


The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from 
a XML schema perspective as UUID is a simple type with a restricted 
string value while HIER_OBJECT_ID is a complex type with a child 
element value. The V1.4 AOM XML schema uses this HIER_OBJECT_ID type 
(as per the AOM specification) and since the OPT schema inherits this 
model, it also uses this type and all OPTs generated by CKM (and the 
template designer) populate the uid element with the template GUID 
specified in the OET file.


I suggest that the ADL 2 specification is that one that needs to 
change or there needs to be a specified mapping between the two.





from the point of view of continuity, that is probably correct. However 
we wouldn't need to do that just in order to maintain XSD compatibility 
- we can maintain the XSD HIER_OBJECT_ID type in that field, in a 
version of the AOM2 XSD that aims to be compatible with the AOM1.4 XSD, 
while in a more efficient AOM2 XSD which we might write, it would just 
be a restricted string field, i.e. a UUID.


I am more inclined to make the AOM2 specification, which is normative, 
as clean as it can be. And since it has other breaking changes, having 
this one as well is not problematic.


I also think that the AOM1.4 spec is correct as it is, given what Heath 
says above. So really it comes down to how we treat XSDs and XML, not 
the normative models of archetypes.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

2017-06-15 Thread Bert Verhees

Although the OID and UUID as used in the archetypes are (in the most 
simple (one arc) OID-occurrence) technical interchangeable is their 
semantical meaning completely different. So what do we want to express 
here? Is it ever used in the way a OID is meant to be used? (to trace 
back the organization that is responsible for creating/maintaining the 
archetype and assign a purpose/meaning to the archetype)


The OID is a paper tiger, it suggests something, with structured 
meaning, but no organization I know has the overhead of maintaining 
useful use of OID's in archetypes implemented. That is why, also, they 
do not occur in CKM and no-one ever complained about that, for ten 
years. No software I know is interpreting the arcs of the OID in the 
uid-property of an archetype, it would run into trouble when it did. The 
tooling (including CKM) has no way to support administrative overhead.


That the use of OID in the uid-property of archetypes is not useful, is 
illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x


When remaining to the OID in 1.4.x, we create an illusion, we suggest 
some structure in the uid-property which is not there. In fact opposite, 
we suggest that all archetypes are to be maintained by different 
organizations because they have a different uid and only one arc.


The problem I have is that the current situation with OID in the 
uid-property corrupts the administrative use. We write a UUID, we call 
it OID but we treat it as a UUID, because the practical use does not 
allow to see it as a meaningful structure.


Bert




On 15-06-17 03:17, Heath Frankel wrote:


Hi Thomas,

Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is 
used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a 
value attribute of type UID, which may be either UUID, ISO_OID or 
INTERNET_ID.


The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from 
a XML schema perspective as UUID is a simple type with a restricted 
string value while HIER_OBJECT_ID is a complex type with a child 
element value. The V1.4 AOM XML schema uses this HIER_OBJECT_ID type 
(as per the AOM specification) and since the OPT schema inherits this 
model, it also uses this type and all OPTs generated by CKM (and the 
template designer) populate the uid element with the template GUID 
specified in the OET file.


I suggest that the ADL 2 specification is that one that needs to 
change or there needs to be a specified mapping between the two.


Regards

Heath

*From:*openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of 
*Thomas Beale

*Sent:* Thursday, 15 June 2017 5:40 AM
*To:* Openehr-Technical 
*Subject:* AOM 1.4 - Archetype.uid a UUID or OID?

Bert picked up an anomaly in this PR 
 that I think should 
probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but 
of type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the 
openEHR type for OIDs). However it appears that all ADL1.4 archetypes 
that have a uid have it as a Guid (i.e. UUID), and I assume the 
various tools do as well. We avoid Oids like the plague in openEHR, 
and I am not aware of them being used anywhere.


If we can verify that everything assumes a UUID for this field, then 
the spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. 
treat this as an error correction.


Could tool makers check this issue and report here?

thanks

- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR-technical Digest, Vol 64, Issue 19

2017-06-15 Thread Pablo Pazos

gt; > Subject: AOM 1.4 - Archetype.uid a UUID or OID?
> >
> >
> >
> >
> > Bert picked up an anomaly in this PR<https://openehr.atlassian.
> net/browse/SPECPR-219> that I think should probably be fixed.
> ARCHETYPE.uid is of type UUID in the AOM2 spec, but of type HIER_OBJECT_ID
> in the AOM1.4 spec (the latter type is the openEHR type for OIDs). However
> it appears that all ADL1.4 archetypes that have a uid have it as a Guid
> (i.e. UUID), and I assume the various tools do as well. We avoid Oids like
> the plague in openEHR, and I am not aware of them being used anywhere.
> >
> > If we can verify that everything assumes a UUID for this field, then the
> spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this
> as an error correction.
> >
> > Could tool makers check this issue and report here?
> >
> > thanks
> >
> > - thomas
> >
> > --
> > Thomas Beale
> > Principal, Ars Semantica<http://www.arssemantica.com>
> > Consultant, ABD Team, Intermountain Healthcare<https://
> intermountainhealthcare.org/>
> > Management Board, Specifications Program Lead, openEHR Foundation<
> http://www.openehr.org>
> > Chartered IT Professional Fellow, BCS, British Computer Society<
> http://www.bcs.org/category/6044>
> > Health IT blog<http://wolandscat.net/> | Culture blog<
> http://wolandsothercat.net/>
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <http://lists.openehr.org/pipermail/openehr-technical_
> lists.openehr.org/attachments/20170615/9303fb2a/attachment.html>
> >
> > --
> >
> > Subject: Digest Footer
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org
> > http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
> >
> > --
> >
> > End of openEHR-technical Digest, Vol 64, Issue 19
> > *
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: openEHR-technical Digest, Vol 64, Issue 21

Re: openEHR-technical Digest, Vol 64, Issue 19

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Re: openEHR-technical Digest, Vol 64, Issue 19

11 matches

Site Navigation

Mail list logo

Footer information