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: 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: openEHR-technical Digest, Vol 64, Issue 19

2017-06-14 Thread William Goossen 
k 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/>
>> 
>> ___
>> 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>
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170614/b2f3996a/attachment-0001.html>
> 
> --
> 
> Message: 3
> Date: Thu, 15 Jun 2017 01:17:37 +
> From: Heath Frankel <heath.fran...@oceanhealthsystems.com>
> To: For openEHR technical discussions
><openehr-technical@lists.openehr.org>
> Subject: RE: AOM 1.4 - Archetype.uid a UUID or OID?
> Message-ID:
>
> <syxpr01mb145562d7cd4ef515a66439689e...@syxpr01mb1455.ausprd01.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
> 
> 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 <openehr-technical@lists.openehr.org>
> 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, Specific