URIs are often kind of self-explanatory and may implicitly carry information about type/issuer/assigner. Most OIDs are also interpretable using lookup services.
Questions:
Is it reasonable to skip the type/issuer/assigner-attributes when putting self-explaining URIs in the id field
When putting OIDs in the id field for some use cases without the need for type/issuer/assigner-attributes, should we reccomend to prefix the OID with urn:oid:?
When putting an OID in the type field should we reccomend to prefix the OID with urn:oid: to make it clear that it is an oid?
Example of #1, a self assigned ID of a private organisation that does not have a Swedish HSA-ID for care:
Why would you skip it? It seems trivial to fill and could be very valuable, e.g. for a computer or human that doesn’t natively understand the implied metadata.
Mostly to reduce redundancy and space. In the Swedish use case I am thinking of these will be used in the “Identifier” field of the archetype “Organisation” and the “Role” will already be SNOMED-coded as 43741000|Care unit. A sImilar structure will be repeated twice for EVERY composition, thus we want to reduce redundant info.
The issue with skipping those other fields because might be already coded in the id, is querying then needs to decode the id or query inside a string value, because the RM and AQL don’t know how to process the format. This implies that an implementation needs to decode the value first, to know the type, then process/query the value based on the type.
IMO it is way better to have all the redundancy to simplify processing and querying of data, and avoid any encoded data here, which implies a decode is needed.
