Stream: ihe
Topic: Request for DICOM identifier type
Grahame Grieve (Aug 27 2018 at 21:04):
This is really a subject for a dicom stream, but we don't have one of those. GF#15123 proposes adding 3 Dicom identifier types to the identifier type value set. I don't understand
- why add these? how does it help with the original request? how would you use them?
- why 3 types? The type is fixed by location, so only one at the most....
I'm sure I discussed this somewhere, but it's not noted in the task, nor can find it
Elliot Silver (Aug 27 2018 at 21:51):
We discussed it in the FHIR-I call about two weeks ago. The discussion around the tracker item has morphed over time. But let me try to summarize.
Grahame Grieve (Aug 27 2018 at 22:28):
I thought we discussed it, but we didn't make any notes :-(
Elliot Silver (Aug 27 2018 at 22:52):
As a result of a workflow quality report on ImagingStudy, we removed specific elements for holding the DICOM study, series and instance UID values for the images referenced. Instead we gave guidance on using the general ImagingStudy.identifier, ImagingStudy.series.identifier, and ImagingStudy.series.instance.identifier elements for these. Another item that previously had a separate element in ImagingStudy was the accession number identifier. This was also rolled into ImagingStudy.identifier.
However, DICOM UIDs are OIDs, and OID identifiers have a fixed system of rfc3886. Therefore there was no way to distinguish DICOM UID from any other OID identifier that might be associated with that ImagingStudy. We thought about a "DICOM" system, but decided that this is wrong, since all other OIDs are using the common rfc3886 system. We then thought about saying within ImagingStudy the study/series/instance UIDs would be identified with identifier.use=official. Accession numbers would be identified by using identifier.use=secondary. However, that didn't sit well either.
Looking further, we noticed that the identifier.type value set has a value to identify accession numbers: ACSN. Based on that, we thought we should add more types for DICOM UIDs. We debated whether to request a single type for all DICOM UIDs or to have multiple, one each for study UID, series UID, and instance UID. Although the current use case has separate locations for each, we felt that it would be clearer and more reusable to have a different type for each.
There was also talk about adding invariants to ensure compliance with DICOM's restrictions on UIDs (max 64 characters), and DICOM WG-06 has suggested they would like the uri:oid: prefix omitted.
At the time that we talked on the FHIR-I call, you weren't a big fan of this. Pursuing this would require engaging with harmonization. Lloyd (if I recall correctly) had earlier suggested that removing the separate elements for UIDs was an incorrect response to the quality report. And since then, we believe we've found DICOM codes that we could use instead of having this added to the FHIR value set, since Identifier.type is extensible (this still needs confirmation).
Grahame Grieve (Aug 27 2018 at 23:01):
DICOM WG-06 has suggested they would like the uri:oid: prefix omitted
Grahame Grieve (Aug 27 2018 at 23:01):
well, that would be grounds for defining a system then, and specifying that the OIDs are represented without urn:oid: prefix in this system. and you could decide whether to have 1 system or 3.
Grahame Grieve (Aug 27 2018 at 23:02):
I think that what was not stated is 'it's important to know which is the magic dicom identifier to use in WADO-RS' or something
Elliot Silver (Aug 27 2018 at 23:02):
So, the question, I guess, is: what is the work for MnM? I think II is probably willing to take this back, and update the resolution. However, we need to confirm the DICOM codes. I am unconvinced that DICOM's request for a way to represent UIDs without the uri:oid; prefix is worth addressing. Similarly, I'm unsure about the need to enforce DICOM OID rules: you're not going to have a system interoperate with DICOM if it is using 80 character OIDs, so you'll fail pretty quickly.
Elliot Silver (Aug 27 2018 at 23:04):
right. That's the issue: how to tell which of multiple OIDs you want, and where.
Grahame Grieve (Aug 27 2018 at 23:04):
removing the separate elements for UIDs was an incorrect response to the quality report
Grahame Grieve (Aug 27 2018 at 23:04):
? does that invalidate the whole discussion...
Elliot Silver (Aug 27 2018 at 23:06):
I believe @John Moehrke had a different thought about that. His argument, if I recall correctly, is X.identifiers is that pattern we use for all our identifiers, we don't have separate elements for specific identifiers. So he agreed with the report.
Grahame Grieve (Aug 27 2018 at 23:07):
well, we do have separate identifiers in some places. So on it's own, that's not the final word
Elliot Silver (Aug 27 2018 at 23:13):
I think the problem still needs addressing, even if we go back to separate oid elements for these identifiers. I expect, someone, somewhere is going to need to put a DICOM UID in a FHIR identifier. (e.g., a reference with an identifier filled in)
John Moehrke (Aug 28 2018 at 12:18):
So what is the remaining concern with adding the type of indicator that is a DICOM OID? Is the question on if this is one type or three? It seems the desire for a dicom OID type is there, and would be distinct.
Elliot Silver (Aug 28 2018 at 17:26):
One concern is that while we found codes for STudy and series UIDs, but can't locate an existing one for instance.
Grahame Grieve (Aug 29 2018 at 03:49):
@John Moehrke I'm not sure what the desire is for; I'd like to know why it's justified to have 3 not 1
Grahame Grieve (Aug 29 2018 at 03:49):
because this is the type of thing I get asked
John Moehrke (Aug 29 2018 at 12:16):
I tried to advocate for one type, as they are all the same type of object identifier. They simply identify different types of objects. So the variability of the 'type' is not on the identifier, it is on the object. The argument then observed that there is UDI, FILL, and PLAC today; which are all the same type of identifier, different only by the type of object they are identifying.
Elliot Silver (Aug 29 2018 at 17:18):
Lets ignore the current ImagingStudy structure for a minute, and just focus on using issues around OIDs as identifiers. But before I get there, lets look at a more common case:
You receive an identifier with system="urn:oid:0.1.2.3.4.5.6.7", value="2356". We know the assigning authority and value but not that is being identified. This could be an MRN or an employee number or something else. Person.link.target.identifier could easily be either of those. To figure out which one, we either need some context (Person.link.target.type might be enough, assuming it there is a FHIR resource it can point at) or we need to know the identifier type (MRN, EN).
Similarly, for an OID identifier, system="urn:ietf:rfc:3986", value="urn:oid:1.3.12.2.1107.5.8.2.200912223559125.9072", you have no idea what it identifies, other than it is identified by an OID. Even if say, type="DICOM UID", we still are unsure as there are many options: is it a DICOM defined value for SOP class, transfer syntax, or frame of reference? is it an implementation-generated value for creating system, study instance, transaction, radiopharmaceutical administration event, or SOP instance? Now, I don't expect most of these will end up in FHIR, and where they do, they likely won't end up in places where what is being identified is ambiguous. But I imagine there is a possibility. The spec only deals with DICOM Study, Series, and SOP instance UIDs, so we should be able to identify those.
In my mind, interoperability is improved by reducing the opportunities for ambiguity, and specific types would reduce ambiguity. Other than the process to approve three codes instead of one (which I'm currently thinking would be a DICOM, not HL7, task), I can't imagine other costs that would be higher with separate codes than a single. You either know the type of DICOM identifier you are expecting, in which case the identifier type can be ignored or confirmed against the specific value you expect; or you don't know they type of DICOM identifier you are expecting, in which case you need the identifier type to tell you.
That's my thinking right now. I am preparing a DICOM change proposal for them to define a code for "SOP instance UID", and potentially a value set of all DICOM UID types. I expect there will be some discussion of this at the next DICOM WG-06 meeting (Sept 10-14). If we can get into their next ballot, it will be tight, but I think we could get it approved before the R4 publication deadline.
John Moehrke (Aug 29 2018 at 17:33):
I also recall that we identifed a DICOM URI that could be used for the system value when the value is a DICOM UID. This is not noted in the CR. So it is going to be identifable as a DICOM UID, the two things being requested is ( a ) that the value could just be the UID value, and not prefixed with urn:oid:, and ( b ) there be type vocabulary to identify a reasonable subset of DICOM object types (hence the three values).
Elliot Silver (Aug 29 2018 at 17:41):
According to FHIR, if it is an OID, the system has to be rc3886. We can't use a DICOM system.
Elliot Silver (Aug 29 2018 at 17:42):
And, according to FHIR, if it is an OID, it has to be prefixed by urn:oid:, so we can't omit the prefix.
Elliot Silver (Aug 29 2018 at 17:42):
Apparently, the only way we can avoid a prefix, and be compliant with FHIR rules, is to use the oid datatype, but that would move it into a separate element.
Grahame Grieve (Aug 30 2018 at 13:26):
According to FHIR, if it is an OID, the system has to be rc3886. We can't use a DICOM system
Grahame Grieve (Aug 30 2018 at 13:27):
that's not quite correct. If the identifier is intended to be an OID without context, then it's represented as an oid like you say. It isn't intended to prevent you from defining a DICOM identifier system where the value of the identifier is issued under DICOM rules and also happens to be an OID.
Grahame Grieve (Aug 30 2018 at 13:28):
My take on what you wrote, Elliot, is that we don't actually know when you might need to different in the type, but we don't know for sure that you won't need to in some context
John Moehrke (Aug 30 2018 at 13:54):
in addition the DICOM flavor of OID has additional requirements of being short... so it isn't just any OID, it is a DICOM OID... so we can do that, right?
Grahame Grieve (Aug 30 2018 at 14:03):
I think you can, yes,
Grahame Grieve (Aug 30 2018 at 14:03):
"system" : "http://dicom.net/uid',
"value" : "1.2.3.4.5"
Grahame Grieve (Aug 30 2018 at 14:03):
I think that's legal
Grahame Grieve (Aug 30 2018 at 14:05):
doesn't resolve the type issue Elliot is concerned about. But since there's no identified reason for adding them, and it's an extensible value set binding, DICOM could just define the codes, and describe their use in IGs, and not add them to the base list. I'm inclined to push back against adding them to the base list for 'just in case' given it's an extensible binding
John Moehrke (Aug 30 2018 at 14:10):
separating out the issues in @Elliot Silver issue is important. So we can get agreement that there can be an Identifier holding a DICOM OID that doesn't have the "urn:oid:" decoration... Getting that settled is step one.... Step two is the discussion on if there is a need for a type.
Elliot Silver (Aug 30 2018 at 18:22):
My take on what you wrote, Elliot, is that we don't actually know when you might need to different in the type, but we don't know for sure that you won't need to in some context
Correct.
Elliot Silver (Aug 30 2018 at 18:26):
@Grahame Grieve, can you explain how a "DICOM OID" can get out of the RFC3986 requirement?
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).
John Moehrke (Aug 30 2018 at 19:05):
For one... it is a sub-class on OID as defined by DICOM.. so it is not an OID, it is a DICOM
John Moehrke (Aug 30 2018 at 19:06):
it might look like an OID to the uneducated, but the DICOM elite know better
Grahame Grieve (Aug 30 2018 at 20:43):
I would be amenable to clarifying that text to make it clear that this is does not exclude identifier authorities that use OIDs but exert some control over how they are asssigned, and have a reason to do so, can define a system to use instead of treating them as unadorned OIDs
Elliot Silver (Aug 30 2018 at 21:40):
HL7 uses OIDs and exerts some control over how they are assigned. Should they be able to define their own system? How do the non-DICOM controlled OIDs that implementations create to identify newly created DICOM objects meet your criteria? (Are they DICOM controlled OIDs?)
Grahame Grieve (Aug 30 2018 at 22:14):
I'm not sure what control you think we exert, except for the ones we define ourselves. I don't think we should define out own system for them. and I'm not sure about your last question - are they OIDs created following DICOM guidance for the defined purpose of identifying particular dicom objects?
Elliot Silver (Aug 30 2018 at 22:21):
"Image identifiers are OIDs, DICOM defines image format specs" is the same situation as "CDA identifiers are OIDs, CDA is an HL7 defined spec"
My question was trying to poke at how you would draw boundaries if we allow exceptions. (I'm not trying to argue against creation of a separate DICOM system, I'm just thinking about the implications.)
Yes, the OIDs are created following DICOM guidance (which consists of: Use an OID, make it less than 64 characters) for, e.g., for each image. But it is up to the vendor to obtain an OID prefix and determine how the complete OID will uniquely identify that image.
Grahame Grieve (Aug 30 2018 at 22:53):
we do not define 64 char limit. That does make it a little different. I do expect that the subject might come up for CDA
John Moehrke (Aug 31 2018 at 12:16):
Watching Elliot argue with himself is entertaining...
Elliot Silver (Aug 31 2018 at 17:03):
I'm glad I can provide some amusement.
Elliot Silver (Sep 18 2018 at 19:23):
New GF#18064 submitted for this issue. Although I mention it here, because it is where the discussion has taken place, there is connection with IHE for this tracker item.
Last updated: Apr 12 2022 at 19:14 UTC
