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.
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/](http://snomed.info/sct/){sctid} e.g. [http://snomed.info/sct/900000000000207008](http://snomed.info/sct/900000000000207008) (SNOMED CT International Edition)
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.