Stream: IG creation
Topic: Validation issue: Bundle fullUrl invalid oid
Brian Reinhold (Oct 26 2021 at 18:47):
I am getting the following validation error in my IG. The error is
Bundle.entry[3].fullUrl (l511/c44) error OIDs must be valid. Of course it's just a temporary id. This is error is new. The fullUrl is
urn:oid:3.1568997631834
Its as fake as all the other 'OID' temporary ids that I have. The others DO have more than one decimal place if that is the problem
Grahame Grieve (Oct 26 2021 at 18:47):
oids must start with 0,1, or 2, I think
Brian Reinhold (Oct 26 2021 at 19:07):
@Grahame Grieve I needed to more than just change the 3 to a 0. The following worked:
urn:oid:0.1568.997631834
I have not tried it with a 3 instead of a leading 0. I am wondering if there is a limit to the number of digits between points?
Lloyd McKenzie (Oct 26 2021 at 19:24):
There's no size limit on digits in general, but there are limits in some OID sub-schemes.
Fake OIDs are not allowed. If you're using an OID, it needs to be a real one. If you want something fake, use a UUID.
Grahame Grieve (Oct 26 2021 at 19:32):
here's the regex that's being applied: [0-2](\.(0|[1-9][0-9]*))+
Corey Spears (Oct 26 2021 at 19:32):
I am not sure what the definition of a Fake OID is. The base has meaning as the each node in the hierarchy is assigned. The owner of a specific base can then decide how to assign OIDs below that base.
Is this an area where one might use the HL7 Examples Root OID as a base? https://www.hl7.org/oid/index.cfm?Comp_OID=2.16.840.1.113883.19
How, if at all, is that managed or expected to be used for HL7 artifacts?
Corey Spears (Oct 26 2021 at 19:35):
In case anyone cares to look through the OID Tree: http://oid-info.com/cgi-bin/display?tree=2.16.840.1.113883.19
John Moehrke (Oct 26 2021 at 19:36):
no one wants to look at the OID tree -- Here is my informative article on OID and UUID -- https://healthcaresecprivacy.blogspot.com/2011/02/creating-and-using-unique-id-uuid-oid.html
John Moehrke (Oct 26 2021 at 19:37):
not uncommon to just use 1.2.3... many people understand those are examples. They are not reserved formally, but are mostly recognized as not-to-be-seen-in-the-wild.
John Moehrke (Oct 26 2021 at 19:38):
better is to use a UUID encoded as an OID (algorithm for that)
Elliot Silver (Oct 26 2021 at 19:40):
Corey Spears said:
Is this an area where one might use the HL7 Examples Root OID as a base? https://www.hl7.org/oid/index.cfm?Comp_OID=2.16.840.1.113883.19
Note that the 2.999 arc is also reserved for examples.
John Moehrke (Oct 26 2021 at 19:40):
it is? I didn't find that reserved
John Moehrke (Oct 26 2021 at 19:43):
Much nicer reserved OID arc than the HL7 one. thanks
Elliot Silver (Oct 26 2021 at 19:44):
John Moehrke said:
Much nicer reserved OID arc than the HL7 one. thanks
Did you find a reference for it? You have me doubting myself now.
John Moehrke (Oct 26 2021 at 19:44):
yes multiple OID registries confirmed it
Lloyd McKenzie (Oct 26 2021 at 19:44):
2.999 would be fine then
John Moehrke (Oct 26 2021 at 19:45):
http://www.oid-info.com/faq.htm
- Is there a particular OID that can be used for documenting examples of object identifiers?
{joint-iso-itu-t(2) example(999)} (or 2.999) can be used by anyone, without any permission, for the purpose of documenting examples of object identifiers (in the same way as "example.com" is defined in IETF RFC 2606 as an example for web sites).
David Pyke (Oct 26 2021 at 19:48):
That's cool. I can stop using 1.2.3.4 then
Grahame Grieve (Oct 26 2021 at 19:49):
2.999.1.2.3.4
Lloyd McKenzie (Oct 26 2021 at 19:49):
Is there a place to put useful guidance like this?
Elliot Silver (Oct 26 2021 at 19:49):
So... you can stop using 1.2.3.4, and continue using 1.2.3.4.
David Pyke (Oct 26 2021 at 19:49):
Stop posting your phone number, Grahame, you're married
Elliot Silver (Oct 26 2021 at 19:50):
Would it be helpful on the HL7 OID registry?
John Moehrke (Oct 26 2021 at 19:56):
Should the HL7 registry replicate OIDs in broader OID space?
David Pyke (Oct 26 2021 at 19:56):
Yes, they should.
John Moehrke (Oct 26 2021 at 19:56):
then you and Elliot should submit it
Grahame Grieve (Oct 26 2021 at 19:56):
someone should be designated to find all oids and register them. for $$ too
David Pyke (Oct 26 2021 at 19:57):
Sounds like you've got a real business opportunity there.
John Moehrke (Oct 26 2021 at 19:57):
you mean all the OIDs you created and stamped into the FHIR core spec ?
John Moehrke (Oct 26 2021 at 20:09):
Re: https://jira.hl7.org/browse/FHIR-26398
Elliot Silver (Oct 26 2021 at 20:25):
Grahame Grieve said:
someone should be designated to find all oids and register them. for $$ too
I can take that on, just as soon as I finish cataloguing all the GUIDs.
Brian Reinhold (Nov 01 2021 at 13:37):
@Corey Spears
I call them fake because I could only make temporary IDs in the transaction bundle using oids or UUIDs. OIDs can be short and for most cases I am also re-using V2 PCD-01 OBX-4 (containment tree) as the temporary ids for the observations since it has the form as an OID. Once the transaction bundle is processed, these 'fake' OIDs no longer exist and will not be on the server. These OIDs mean nothing. I am not sure why the temporary IDs in the transaction bundle require UUIDs or OIDs since they are only temporary and exist only until the time the bundle is processed. The only purpose they serve is to let the server define the logical ids.
Lloyd McKenzie (Nov 01 2021 at 14:17):
There's no such thing as "temporary" ids. Once used, they're not allowed to be used for anything else on the server. If you use an OID and forget about it and could potentially re-uses it again, you're non-conformant. (On the other hand if you use a UUID and forget about it, there's zero chance of it being re-used, so you're fine.)
Jens Villadsen (Feb 07 2022 at 09:37):
Getting back to something along the line here - I'm getting an OIDs must be validwhen validating the attached example file.json using java -jar validator_cli.jar file.json -ig https://build.fhir.org/ig/hl7dk/dk-medcom/package.tgz. The OID's in question here are urn:oid:1.2.208.176.1.1and urn:oid:1.3.88. They both seem pretty valid to me
Jens Villadsen (Feb 07 2022 at 14:48):
@Grahame Grieve
Grahame Grieve (Feb 07 2022 at 20:27):
so the problem is the OID 1.3.88. There's an arbitrary rule in the validator that the last . in the oid must be at last 5 characters into the OID - because there's almost no circumstances where a root OID should be used as a namespace
Grahame Grieve (Feb 07 2022 at 20:27):
of course, you found the case :grinning:
Grahame Grieve (Feb 07 2022 at 20:28):
fixed next release
Jens Villadsen (Feb 07 2022 at 21:50):
:medal: for me ;) - thx a bunch
Jens Villadsen (Feb 07 2022 at 22:34):
@Grahame Grieve you got a link to the changeset?
Grahame Grieve (Feb 08 2022 at 00:04):
not committed yet
Last updated: Apr 12 2022 at 19:14 UTC
