FHIR Chat · DICOM valuesets and codesystems · terminology

Stream: terminology

Topic: DICOM valuesets and codesystems

John Moehrke (Oct 03 2019 at 12:54):

Is it possible for tx.fhir.org to pull selected ValueSet and CodeSystem from DICOM? For example ImagingStudy.modality today just points at the DICOM specification (html). This is nice for a human, but not for instrumentation. There is a ValueSet and CodeSystem available there. It would seem better to have these baked into the FHIR Core as ValueSets not html. See http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html

Rob Hausam (Oct 03 2019 at 14:24):

yes, it's possible, as long as there aren't licensing issues

John Moehrke (Oct 03 2019 at 16:43):

So what needs to be done to make that clear? Their publication would clearly be the prime and thus where the canonical URL is found. Yours would be a copy. Right? So as you are indicating the issue is just making sure the organizations agree to this replication. right? I can facilitate that discussion.

John Moehrke (Oct 03 2019 at 19:17):

I started the discussion with DICOM. I presume that the mechanics would be that some list of codeSystem and valueSet would be maintained, and that some regular basis or trigger would cause you to go check DICOM to see if they have been revised? Hopefully it isn't something that would weigh-down the continuous build, but the trigger would need to be often-enough to be effective.

Rob Hausam (Oct 03 2019 at 19:40):

Yes, the FHIR publication would be a copy. I'm not sure that we can set up any automatic trigger mechanism (but it could be worth exploring). If the updates are on a regular schedule or if there is someone (like yourself) who will be monitoring it and can communicate that an update is needed, that might be sufficient (at least for now).

Grahame Grieve (Oct 03 2019 at 20:01):

DICOM should publish all these things as a package so that the FHIR eco-system can pick these up easily

Grahame Grieve (Oct 03 2019 at 20:03):

the package eco-system is going to be rss driven - so you publish an rss feed declaring what packages you have published, and update it when you release a new one. the FHIR registry etc will pick it up from there. See the master list of packages here:

https://github.com/FHIR/ig-registry/blob/master/fhir-ig-list.json

(we can add DICOM there). And see an example feed here:

http://hl7.org/fhir/package-feed.xml

John Moehrke (Oct 03 2019 at 21:10):

oh Grahame, you always want others to do more work than they are already doing... They are publishing them as FHIR ValueSets... why must they then put them in a package?

Grahame Grieve (Oct 03 2019 at 21:17):

where are they as FHIR value sets?

John Moehrke (Oct 03 2019 at 21:27):

they are published with the DICOM standard. go to the above html page

Grahame Grieve (Oct 03 2019 at 21:32):

is there a computer processible list anywhere?

John Moehrke (Oct 03 2019 at 21:35):

I suspect we only need a sub-set... but I would agree it would be nice if there was a comprehensive list from DICOM. I just don't know yet

Grahame Grieve (Oct 03 2019 at 21:38):

@David Clunie it's you that publishes the value sets, right? Do you also publist a code system for http://dicom.nema.org/resources/ontology/DCM, and do you have a list of value sets in a computer processible form anywhere?

David Clunie (Oct 03 2019 at 23:56):

The DCM codes are all uploaded to the BioPortal with each release (https://bioportal.bioontology.org/ontologies/DCM).

David Clunie (Oct 03 2019 at 23:58):

But that is not a list of DICOM "value sets", many of which use non-DCM codes (e.g., SCT); the only automatically updated list of value sets is really the TOC of PS3.16 Annex B, but one could easily produce such a list with an XSLT applied to the XML DocBook source of PS3.16, if you want me to make one. Is there a standard format for a "list of value sets", as opposed to the content of an individual value set?

Grahame Grieve (Oct 04 2019 at 01:29):

I'd prefer an implementation guide:

{
  "resourceType" : "ImplementationGuide",
  "url" : "http://dicom.nema.org/resources/ImplemnentationGuide/terminology",
  "version" : "<dateTime>",
  "name" : "DICOM Terminology Package",
  "title" : "DICOMTerminology",
  "status" : "active",
  "experimental" : false,
  "date" : "<dateTime>",
  "publisher" : "DICOM",
  "copyright" : "© <date> NEMA",
  "packageId" : "dicom.fhir.tx",
  "fhirVersion" : ["4.0.0"],
  "dependsOn" : [{
    "uri" : { "http://hl7.org/fhir/R4" }
  }],
  "manifest" : {
    "resource" : [{
      "reference" : { "ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/json/CID_33.json" }
    }]
  }
}
 ```

Grahame Grieve (Oct 04 2019 at 01:29):

where you just add additional repeats in manifest.resource, one for each valueset

John Moehrke (Oct 04 2019 at 16:57):

if we can get this going, then we can eliminate some valuesets in AuditEvent that were hand created. for example DICOM manages
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_402.html
but FHIR has a hand created similar
https://github.com/HL7/fhir/blob/master/source/auditevent/valueset-dicm-402-roleid.xml
similar issues in ImagingStudy
https://github.com/HL7/fhir/tree/master/source/imagingstudy

John Moehrke (Oct 22 2019 at 16:22):

@Grahame Grieve and @David Clunie is there going to be movement on this? I would like to see the dicom codesystems available for the FHIR core and FHIR IG without manual intervention.

Grahame Grieve (Oct 22 2019 at 17:13):

I haven't heard from David on this....

John Moehrke (Oct 22 2019 at 17:57):

In the mean-time... should I copy them from the DICOM spec into the FHIR spec? this would at-least save me from fat-finger typo...

Grahame Grieve (Oct 22 2019 at 18:03):

well, that depends on how quickly David is going to respond...

John Moehrke (Oct 22 2019 at 18:08):

agree. I can wait for a while as this is to affect R5.

John Moehrke (May 22 2020 at 11:14):

how is this one coming?

Grahame Grieve (Jun 04 2020 at 02:28):

ok remind me what it is that we're trying to achieve here?

John Moehrke (Jul 29 2020 at 14:16):

How can I or the HL7 Imaging Integration co-chairs (@Jonathan Whitby and @Christopher Lindop ) help with getting the DICOM ontology vocabulary into the tx for use by FHIR core and IG builds?
It looks from above (October 3rd) that you would like to have an IG that identifies each valueset to pull into the hl7 terminology server?
does it seem logical to have this valueset be something the HL7 II workgroup manages for the purposes of when HL7 needs a set of codes?
I suspect if it was managed by DICOM they would just identify all codes and all valuesets.

John Moehrke (Jul 29 2020 at 15:48):

Also bringing in @Elliot Silver and @Kevin O'Donnell and @David Clunie

David Clunie (Jul 29 2020 at 16:13):

I do not understand what you are asking for, so if someone is waiting for my input you need to be more specific.

Robert McClure (Jul 29 2020 at 16:31):

@John Moehrke and all on the thread, I've noted that many of you have already been communicating with HTA on the DICOM page there. What I assume John needs specifically, to start, is that the DICOM-created codes, ie: DICOM code system content, into HL7. This versus the Rosetta and the Radlex content which needs those authorities to step up and help HTA and UTG get their content properly managed in HL7. @David Clunie is it you that can act as the link to DICOM? This might be complicated if some of the value sets defined by DICOM include content from multiple code systems - is it? Then we have the issue of how to confirm the accuracy of what ever UTG gets and how to keep it UTD. Do I have the issues?

John Moehrke (Jul 29 2020 at 16:35):

the terminology server that is used by the HL7 FHIR core and by HL7 Implementation Guide build tool is called upon to validate codes. When these codes are DICOM codes, they can't be confirmed. I don't want HL7 to become the authority on DICOM codes, I just want the FHIR core (ImagingStudy and AuditEvent) to be able to use codes from DICOM. And I just want other Implementation guides to be able use DICOM codes.

John Moehrke (Jul 29 2020 at 16:36):

DICOM does publish ValueSets, but does not publish CodeSystem resource

John Moehrke (Jul 29 2020 at 16:38):

These are published raw on an FTP server ftp://medical.nema.org/medical/dicom/resources/valuesets/
Or wrapped in narrative within the DICOM specification http://dicom.nema.org/medical/dicom/current/output/html/part16.html#chapter_B
@Grahame Grieve has asked for a FHIR Implementation Guide, presumably as it would be easier for his tooling to handle

John Moehrke (Jul 29 2020 at 16:38):

@David Clunie one problem is that the codes are not published in a CodeSystem Resource, just in ValueSets. Which is not sufficient

John Moehrke (Jul 29 2020 at 16:39):

The other aspect I am bringing up is that not ALL of the DICOM codes are needed, just those that are being used in FHIR core and a few other places

John Moehrke (Jul 29 2020 at 16:40):

I am mostly focused on ValueSets that are made up of just dicom codes, but there are many valueSets in dicom that include codes from many codeSystems beyond DICOM. These are not as clearly needed... but I am not the authority on what is clearly needed

David Clunie (Jul 29 2020 at 16:45):

If you are looking for all DICOM-defined PS3.16 codes (DCM), they can be found in the OWL and CSV files at "http://bioportal.bioontology.org/ontologies/DCM", being extracted automatically each release, as I mentioned earlier in the thread. You can "validate" the DCM codes you use against that. If you need it in a different format (that is easy to implement) I can create that. I have no means of subsetting them based on what FHIR might or might not use. There is no distinction in DICOM Context Groups (Value Sets) wrt. which contain only DCM codes and which do not, and that could change with any release (e.g., if SNOMED adds a code that we switch to, which often happens). For each DICOM Context Groups (Value Sets), I have provided FHIR JSON and XML representations. So I still have no idea what more you are asking for.

John Moehrke (Jul 29 2020 at 16:52):

I am asking for CodeSystem resource for the codes defined by DICOM (DCM) in addition to the ValueSet resource you provide.

John Moehrke (Jul 29 2020 at 16:53):

Are the ValueSet resources you create compliant with FHIR R4 where ValueSet became normative? Elliot thinks they are STU3 based.

John Moehrke (Jul 29 2020 at 17:00):

@Robert McClure I am confused on what HTA is vs UTG vs simply terminology.hl7.org... so I am pushing as many buttons as I can touch. I dont know what the button does, but pushing it seems to make something happen. I can't yet feel that the something(s) that are happening are useful.

Robert McClure (Jul 29 2020 at 17:11):

Don't want you flying my plane ;-) No worries, I think we're getting there. Seems that what we need is to get DCM code system resources from DICOM if they can create them, if not, then we'd need someone (@David Clunie ?) to help that happen so that @Ted Klein couple regularly bring that into UTG (which = terminology.hl7.org.) There are other approaches based on existing workflows for content creation but I'd say what I'm describing would be the best current approach if others agree.

John Moehrke (Jul 29 2020 at 17:39):

that sounds right to me. We also do need some valueSets.
ImagingStudy -- https://www.hl7.org/fhir/imagingstudy.html#tx

• CID 29 -- acquisition modality --- would be best to import the dicom managed valueSet. Today we replicated it manually

• the SOP classes - Part 4, Section B.5... --- I don't understand this one
  AuditEvent -- https://www.hl7.org/fhir/auditevent.html#tx

• not clear to me what valueSets should be listed here. I have hand made these valueSets off of the DICOM AuditMessage specification. I presume there is some defined valueSets.

John Moehrke (Jul 29 2020 at 17:40):

And lastly I need ONE FormatCode out of DCM --

      <code value="1.2.840.10008.5.1.4.1.1.88.59" />
        <display value="Key Object Selection Document" />

again I am not sure what ValueSet this is in. I only know it by code

Elliot Silver (Jul 29 2020 at 18:08):

I just had a quick look, and it appears that the DICOM-published value sets conform to R4. I don't know if David has updated them from R3, or the portions of the resource used were unchanged between versions.

Elliot Silver (Jul 29 2020 at 18:10):

For the KOS format code, there is no current value set. As far as I can tell, DICOM hasn't considered their defined UIDs for SOP classes, Transfer Syntaxes, etc. to be "terminology."

John Moehrke (Jul 29 2020 at 18:11):

that needs to be fixed... right? Because they are used as if they are codes in the DCM code system

Elliot Silver (Jul 29 2020 at 18:12):

I would suggest so.

Elliot Silver (Jul 29 2020 at 18:14):

I don't think they consider the audit codes as vocabulary either.

John Moehrke (Jul 29 2020 at 18:22):

Elliot Silver said:

I don't think they consider the audit codes as vocabulary either.

no body gives security the respect it deserves.. :-)

Elliot Silver (Jul 29 2020 at 18:25):

I mean, that one has some additional challenges, because it is based on syslog. However, I don't think security is being singled out. DICOM has a much different approach to terminology than HL7.

John Moehrke (Jul 29 2020 at 18:51):

vocabulary is ... vocabulary... matters not what the transport is... some of DICOM works over http, yet that uses DICOM vocabulary.

John Moehrke (Jul 29 2020 at 19:03):

For those ValueSets that I need in FHIR and IG builds; I could make the ValueSets and commit them back to DICOM for long-term maintenance. The alternative is that I have to create them in the FHIR core and my IG build and maintain them there.

John Moehrke (Jul 29 2020 at 19:05):

I would also be happy to kickstart the IG that Grahame has asked for. It would likely be just as thin as my FormatCode one, carrying only the DICOM codeSystem that we need, and the plethora of ValueSets that already exist. Minimal narrative to send them over to the dicom html specification. (The whole reason I did FormatCode is because I knew this would be the ultimate task that would be assigned to someone)

Elliot Silver (Jul 29 2020 at 19:06):

Elliot Silver said:

I don't think they consider the audit codes as vocabulary either.

Sorry, correction: DICOM Audit uses CID 30 DICOM Devices, and CID 404 Audit Participant Object ID Type Code which are defined in Part 16, but that's it. All other vocabulary used in Audit are not recognized by DICOM as value sets.

Grahame Grieve (Jul 29 2020 at 22:20):

so @John Moehrke I'm not sure what you want here. I generate a CodeSystem resource for the Dicom code system from the content that @David Clunie distributes, and that is loaded on tx.fhir.org, and I also load the value sets that David generates onto tx.fhir.org.

What this means that (1) it's not wonder David can't figure out what you want and (2) whatever it is that you can't do, it's not because the infrastructure isn't in place- or at least, it shouldn't be because of that

Grahame Grieve (Jul 29 2020 at 22:20):

we certainly shouldn't put any DICOM content in UTG.

John Moehrke (Jul 29 2020 at 23:01):

I will try again to use this. Is there any way I can navigate the content in tx.fhir.org?

John Moehrke (Jul 29 2020 at 23:02):

what is the definition of things that should be in UTG vs things that should be in tx.fhir.org? Some clarity might help

Grahame Grieve (Jul 29 2020 at 23:17):

UTG is an HL7 publishing mechanism. We shouldn't publish stuff in UTG unless we should publish it. tx.fhir.org should load all code systems that people want to publish value sets for.

John Moehrke (Jul 30 2020 at 17:14):

so is there a DCM codeSystem in the tx.fhir.org? Would then this CR be already resolved? https://jira.hl7.org/browse/FHIR-24908

Grahame Grieve (Jul 30 2020 at 21:30):

I think it's already resolved

John Moehrke (Jul 31 2020 at 14:55):

so then you will close it? The status is triaged.

Grahame Grieve (Jul 31 2020 at 20:07):

well, do you think it's resolved?

John Moehrke (Jul 31 2020 at 21:49):

So you are suggesting that I try updating core to call upon the valueSets without defining them? to see if the build finds them? As it stands today there is a valueSet that I hand coded in the ImagingStudy or AuditEvent resoruce. My hope was to get rid of these as you would get the formal valueSets from DICOM, thus eliminating errors caused by my fingers, or lack of synchhronization with DICOM improvements.

Grahame Grieve (Jul 31 2020 at 21:49):

yes

Grahame Grieve (Jul 31 2020 at 21:50):

I already get the value sets from David's source directly

John Moehrke (Jul 31 2020 at 21:51):

okay, I will try.

John Moehrke (Aug 04 2020 at 21:18):

wow, it works. and I noticed you had some valueSets already being used by ImagingStudy. So the trick is to figure out that there are valueSets available from DICOM for the need, and what URL DICOM gave to that ValueSet (an unfortunate ".html" in their URL for their ValueSets). But it WORKS. I will be finding where I can use this, and submitting an update. I have already prototyped ImagingStudy, so now will look at AuditEvent.

John Moehrke (Aug 05 2020 at 21:23):

YEAH. It worked... I have updated the core build with as many valuesets from DICOM as I could find. So the CR is now pre-applied.

John Moehrke (Jan 07 2021 at 22:13):

I am noticing that the DICOM codesystem might not be fully working. I first noticed this in my IG build, but noticed that the current FHIR core also seems to not be getting everything.. but it is not a total failure.

the valueset for AuditEvent.type -- is working fine, it finds the DICOM codes

but the valueset for AuditEvent.agent.type is not working

Is this a problem with the terminology services?

John Moehrke (Jan 07 2021 at 22:14):

I do find the whole codesystem in build.fhir.org http://build.fhir.org/codesystem-dicom-dcim.html

John Moehrke (Jan 07 2021 at 22:14):

but not in terminology.hl7.org

Last updated: Apr 12 2022 at 19:14 UTC