Send openEHR-technical mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openEHR-technical digest..."
Today's Topics:
1. Re: AOM 1.4 - Archetype.uid a UUID or OID? (Bert Verhees)
2. Re: AOM 1.4 - Archetype.uid a UUID or OID? (Thomas Beale)
3. Re: openEHR-technical Digest, Vol 64, Issue 19 (Thomas Beale)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Jun 2017 09:32:30 +0200
From: Bert Verhees <[email protected]>
To: For openEHR technical discussions
<[email protected]>
Subject: Re: AOM 1.4 - Archetype.uid a UUID or OID?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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:[email protected]] *On Behalf Of
*Thomas Beale
*Sent:* Thursday, 15 June 2017 5:40 AM
*To:* Openehr-Technical <[email protected]>
*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/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170615/3877f18c/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 15 Jun 2017 11:49:45 +0100
From: Thomas Beale <[email protected]>
To: [email protected]
Subject: Re: AOM 1.4 - Archetype.uid a UUID or OID?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170615/1ecd43a4/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 15 Jun 2017 12:11:57 +0100
From: Thomas Beale <[email protected]>
To: [email protected]
Subject: Re: openEHR-technical Digest, Vol 64, Issue 19
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
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://doc.ihtsdo.org/download/doc_UriStandard_Current-en-US_INT_20140527.pdf>:
http://snomed.info/sct/{sctid} e.g.
http://snomed.info/sct/900000000000207008 (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
<http://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1433773265358_317377_9216>,
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
