Stream: implementers
Topic: Distinguishing OID identifiers
Elliot Silver (Oct 22 2018 at 23:04):
(This issue is the subject of GF#15123 and GF#18064. It is better presented in the latter. Earlier discussions on this can be found at https://chat.fhir.org/#narrow/stream/65-ihe/subject/Request.20for.20DICOM.20identifier.20type)
According to the requirements of the Identifier datatypes, identifiers which are OIDs must use the urn:ietf:rfc:3986 system, and encode the value as uri:oid:1.2.3. (The equivalent applies to UUIDs and URI identifier values as well.) This means that if a resource could be identified by more than one OID (for example, an ebRIM ExternalIdentfier, a CDA id, a DICOM UID) there is no way to distinguish those OIDs based on system.
In ImagingStudy, knowing which of potentially multiple OIDs is the DICOM Study Instance UID is important, as that OID is then used to query the image archive for retrieving the image. In other cases, I expect that knowing what a particular OID identifies will be similarly useful.
There are two general approaches being discussed to address this: use Identifier.type to recognize that a specific OID has a particular use (the solution proposed in GF#18064 to address the ImagingStudy issue), or relax the requirement on Identifier system to allow systems other than RFC3896 for OIDs (and UUIDs and URIs).
I am ready to submit a harmonization proposal for the Identifier.type solution, but during today's Vocab call, it was recognized that this is going to be a general issue for anyone using OIDs, UUIDs, and URIs as identifiers -- medicines, licenses, organizations, etc. What gets decided will likely set the pattern for the future... So, I'm raising the issue here.
@Rob Hausam , @Robert McClure , @Peter Jordan , @Brad Genereaux, @Eric Martin, @Lloyd McKenzie, @Grahame Grieve
Eric Martin (Oct 23 2018 at 00:05):
I believe that the patterning of using identifier.type to distinguish the type of a UUID, etc. is completely consistent with the intent of identifier.type. Hence, I strongly support the proposed solution for DICOM UID as per in GF#18064. Other types of OIDs, UUIDs, and URIs would define a value for identifier.type that indicates the meaning of the identifier item.
Grahame Grieve (Oct 23 2018 at 01:57):
relax the requirement on Identifier system to allow systems other than RFC3896 for OIDs (and UUIDs and URIs)
Grahame Grieve (Oct 23 2018 at 01:58):
that is not a requirement. Specifically, we do not say 'anything that meets the OID regex SHALL be treated as a plain OID". All we say is that "Plain OIDs are represented this way".
Grahame Grieve (Oct 23 2018 at 01:59):
if DICOM wanted to declare that all OIDs issued under the DICOM arrangements for OIDs were in the namespace http://dicom.nema.org/OID and the value was just the plain OID, then that would not be non-conformant.
Grahame Grieve (Oct 23 2018 at 02:00):
it might be tricky for people to get right though; I'm not saying I favor this approach over using the type - I'm just pointing out that it's a legal option.
Rob Hausam (Oct 23 2018 at 03:34):
When I read "If the identifier value itself is naturally a globally unique URI (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986" ..." I don't exactly get that interpretation (or at least it's not the first one that I came away with when I read it). I think it's unclear what the specific boundaries are on what "is naturally a globally unique URI" (emphasis mine) is referring to, and I'm not sure if that is or isn't the same thing as "a plain OID" (which isn't mentioned). So I agree it will be tricky to get that right. I think we should at least try to make the language clearer. If the rule is actually about "plain OIDs" than we at least need to say that and say what a "plain OID" is. And if we end up using a general 'type' code and specific system URIs in some cases and then in others (for OIDs, etc.) we use a pretty much "fixed" value of 'system' and instead rely on the 'type' code for specificity, I think that's at least quite messy and confusing, and I would like to be able to be more consistent and avoid that. Even though Grahame isn't necessarily in favor, I think if using a specific 'system' URI is a "legal" option then it's probably a better way to go.
Grahame Grieve (Oct 23 2018 at 06:25):
ok we could clarify that language. For me, a DICOM assigned OID with a particular meaning is not 'naturally a globally unique identifier" but I agree that this language is quite ambiguous
John Moehrke (Oct 23 2018 at 12:19):
so Grahame, you are seeming to indicate that - where no specific namespace is available, urn:ietf:rfc:3986 shall be used. I think that would make it clear and make way for more specific namespaces to appear as appropriate.
Lloyd McKenzie (Oct 23 2018 at 14:50):
Making clarifications in a "SHALL" statement in a normative portion of the specification is dangerous territory right now. I don't think we can change the sentence, but perhaps we can add a clarifying sentence that explains "naturally".
Robert McClure (Oct 23 2018 at 17:14):
@Lloyd McKenzie I had the same concern. To me, that sentence is just simply wrong if the intent was consistent with @Grahame Grieve comment. But if you all can craft words around what "naturally" and being an OID means, I guess go for it.
As for which approach is better, I agree it is a close call and the v2 Identifier Type code system Type uses is all over the map regards including specific identifier "types" (Amercian Express and Discover, versus also Bank Card Number). Please confirm we want to allow implementers to "do it either way" and then continue to allow very specific types and the general class so that you'll need to look at both the type and the system URI to figure out what identifier you have.
Elliot Silver (Oct 23 2018 at 17:26):
@Grahame Grieve , just so we're clear: These aren't DICOM (the SDO) assigned OIDs. We're talking about implementation-generated OIDs used to identify DICOM entities like an image or a study. (DICOM does have DICOM-assigned OIDs to identify certain concepts, but these aren't the ones at issue here.)
Grahame Grieve (Oct 23 2018 at 20:46):
@Elliot Silver you'll note that I didn't use the words 'dicom assigned OIDs'
@Robert McClure I agree the v2 type is less than ideal - but any take on identifier type has been less than heavenly
@Lloyd McKenzie I agree about the wording and process
Elliot Silver (Oct 23 2018 at 21:08):
@Grahame Grieve:
you'll note that I didn't use the words 'dicom assigned OIDs'
I thought you had:
For me, a DICOM assigned OID with a particular meaning is not 'naturally a globally unique identifier"
However, as long as we're clear about the identifiers we're discussing, all is good.
To make sure I understand, we can't change:
If the identifier value itself is naturally a globally unique URI (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value (OIDs and UUIDs using urn:oid: and urn:uuid: - see note on the V3 mapping and the examples).
But, we can add a sentence along the lines of "Certain uses of OIDs, such as DICOM entity UIDs, are not naturally, globally unique URIs."
Grahame Grieve (Oct 23 2018 at 21:52):
oops. so I did. But when I was being more careful I said:
OIDs issued under the DICOM arrangements for OIDs
so yes, we could add a clarifying sentence like that
Lloyd McKenzie (Oct 23 2018 at 22:19):
I think we need to explain what's meant by "naturally" - listing a single exception isn't enough. We need to explain what the criteria is so we can differentiate future cases too - after all, this is a SHALL statement, so there needs to be determinism around when it applies.
John Moehrke (Nov 01 2018 at 17:27):
II Workgroup approved as a submitted recommended change in GF#19602 --- @Lloyd McKenzie @Grahame Grieve can we get this into R4?
Lloyd McKenzie (Nov 01 2018 at 17:35):
I would love to, but I'm pretty sure that ANSI would consider that a substantive change. What we could do is add a separate sentence noting that there will be specific Guidance for Dicom and similar identifiers coming in R5. That wouldn't be a substantive change and would at least give implementers a cue that there's going to be different rules. We can also apply the approved change as soon as R5 publications are open.
Grahame Grieve (Nov 01 2018 at 18:26):
I think we can clarify what naturally means
Lloyd McKenzie (Nov 01 2018 at 18:59):
Do you have proposed language?
Elliot Silver (Nov 01 2018 at 19:08):
"A natural globally unique URI is one for which a more appropriate identifier system, such as urn:dicom:uid for DICOM entity UIDs, does not exist."
Lloyd McKenzie (Nov 01 2018 at 19:18):
That's the weirdest definition of "natural" I've ever seen... It also effectively guts the "SHALL" because "more appropriate" is totally subjective.
Elliot Silver (Nov 01 2018 at 19:24):
If the US president can use an executive order to reverse the meaning of a bill, so can I.
Cooper Thompson (Nov 01 2018 at 19:25):
@Elliot Silver don't you mean "so SHALL I"?
Grahame Grieve (Nov 01 2018 at 19:29):
add "Naturally globally unique identifiers are those for which no system has been assigned, and where the value of the identifier is reasonably expected to not be re-used - typically, absolute URIs of some kind"
Elliot Silver (Nov 01 2018 at 19:29):
The use of "natural" in the original phrase is pretty weird and, ah, unnatural. What does is it supposed to convey?
If the identifier value itself is naturally a globally unique URI, ... then the system SHALL be "urn:ietf:rfc:3986", ...
What is an unnaturally globally unique URI? What is natural about a URI? Can I get organic URIs, free-range URIs raised on mountain slopes and fed only natural spring water?
@Cooper Thompson, touché.
Elliot Silver (Nov 01 2018 at 19:34):
Although I find the second part of Grahame's statement a little odd (perhaps re-assigned rather than re-used would help), I can go with it. Personally, I'd like a reference somewhere near there to DICOM UIDs, but that isn't a blocker.
Lloyd McKenzie (Nov 01 2018 at 19:39):
Can we make [system has been assigned] a link to the "systems" page - that makes things nicely clear. Then we can define NamingSystems for the DICOM ones.
Grahame Grieve (Nov 01 2018 at 19:40):
yes
John Moehrke (Nov 01 2018 at 19:47):
dicom is in the naming system now
John Moehrke (Nov 01 2018 at 19:47):
and the CR has proposed wording see GF#19602
John Moehrke (Nov 01 2018 at 19:48):
we are only talking about things that don't have a naming system defined, and look like an OID
Grahame Grieve (Nov 01 2018 at 19:56):
yes but 19602 can't propose substantive changes to normative content
Grahame Grieve (Nov 01 2018 at 19:57):
so the wording can't stand as is
John Moehrke (Nov 01 2018 at 19:58):
it seemed in this thread it was understood that this proposed text was the meaning of the current wording. That is the clarificaiton of 'naturally'
Grahame Grieve (Nov 01 2018 at 19:59):
Lloyd challenged that
John Moehrke (Nov 01 2018 at 20:00):
and DICOM has indicated that the OIDs used in DICOM are 'special'... thus not natural... :-)
Grahame Grieve (Nov 01 2018 at 20:01):
Lloyd did not challenge the idea, just the specific wording
John Moehrke (Nov 01 2018 at 20:02):
ah, we tried in GF#19602 to be as clear and generous as possible...
John Moehrke (Nov 01 2018 at 20:02):
but we did recongize it as just a recommendation for FHIR-I to start from
Lloyd McKenzie (Nov 01 2018 at 20:02):
You can't change the sentence that contains the word "SHALL". You can add a sentence that clarifies the meaning of "naturally globally unique identifiers" in a way that seems at least semi-intuitive. If we leverage Grahame's wording (possibly changing re-used to re-assigned) and include a link to our definition of identifier naming systems, that doesn't undercut the SHALL. If you're sending a GUID or OID or something similar and there isn't a defined namespace on that page for it, you SHALL use the ietf naming system.
John Moehrke (Nov 01 2018 at 20:03):
yes, that is the spirit
John Moehrke (Nov 01 2018 at 20:04):
Im unclear how adding clarity within the sentence (within comma clarification) is objectionable, yet a second sentence giving the same clarification is not.. but what ever gets us the right resting place.
Elliot Silver (Nov 01 2018 at 20:46):
If I understand where we landed, I'm good with it.
Elliot Silver (Nov 20 2018 at 18:17):
Where are we on applying GF#19602? Is this going to get into R4 or not?
Grahame Grieve (Nov 21 2018 at 05:09):
I thought it had made it in. but no. @Lloyd McKenzie / @Ewout Kramer ? @Josh Mandel / @Rick Geimer FHIR-I call on this?
Lloyd McKenzie (Nov 21 2018 at 17:56):
We can take it up on Monday. (We didn't have sufficient people for a call this past Monday.)
Last updated: Apr 12 2022 at 19:14 UTC
