Stream: IG creation
Topic: Using DICOM's FHIR value sets
Abderrazek Boufahja (Jul 01 2021 at 15:45):
Hi. I have this kind of errors generated in QA report, related to referencing DICOM value sets within the FHIR profiles :
ValueSet http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html not found by validator
The QA report is under this link: https://build.fhir.org/ig/HL7/fhir-radiation-dose-summary-ig/qa.html
Another kind of error is reported if we use direct json link to the value set definition:
The valueSet reference ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/json/CID_4052.json on element Observation.component.value[x] could not be resolved
Does someone experienced using successfully DICOM value sets in IGs ?
Elliot Silver (Jul 01 2021 at 16:26):
@John Moehrke might have an answer. Your valueset canonical URLs look right to me. However, I don't think that the DICOM value sets are in the terminology server referenced by the build. There should be a way to have a valueset resource in your IG for validation, but not included as part of the output, but I don't know how to do that.
John Moehrke (Jul 01 2021 at 16:46):
They should be in UTG. I get them in my basicAudit IG.
Diana_Ovelgoenne (Jul 02 2021 at 07:31):
I do have the same problem, however I am using http://dicom.nema.org/resources/ontology/DCM which is supposedly the URL that shall be used, according to https://terminology.hl7.org/CodeSystem-v3-DCM.html. I have noticed there is a mismatch from what ImagingStudy Resource has defined versus the UTG.
Abderrazek Boufahja (Jul 02 2021 at 10:24):
Thank you for your different responses. I am also using codes coming from http://dicom.nema.org/resources/ontology/DCM which works fine. However, when I reference Value Sets, it does not validate well. @John Moehrke , I am not able to find references to DICOM value sets in BasicAudit IG , but only usage of codes from DICOM Code System.
John Moehrke (Jul 02 2021 at 14:40):
Ah, they might not been pulled into utg.. you can pull them from dicom... They are published in the dicom publication in various formats including as fhir.
Elliot Silver (Jul 02 2021 at 16:18):
I think the issue is not finding the value sets manually, but rather referencing them from an IG, and failing IG validation.
John Moehrke (Jul 06 2021 at 11:57):
You can tell the ig build about URI that are special... In the IHE FormatCode IG I have to add the DICOM oid to the ignore warnings.
Diana_Ovelgoenne (Jul 07 2021 at 11:18):
For me adding the Valuesets generated by DICOM is not a problem (except that the experimental = false needs to be removed or there is a compiling error. The same goes for codes inside the ontology, not a problem. But the question that I have is: when needing to define on code either a CID or a TID, how are these supposed to be defined when putting them on the corresponding code value are they CID_xxx, CID xxx, xxx, sect_CID_xxx? And shall the code system be http://dicom.nema.org/medical/Dicom/current/output/chtml/part16 instead of http://dicom.nema.org/resources/ontology/DCM ?
I also have problems when using ImagingStudy, as the IG Publisher complains about the URL for the SOP classes and the one from radlex for imaging procedure code.
@Elliot Silver @Jonathan Whitby do you happen to know the answer? Please help! the ImagingStudy errors are the only missing errors on my IG.
Elliot Silver (Jul 07 2021 at 19:17):
Hi @Diana_Ovelgoenne, I haven't poked around with DICOM value sets in a while, so bear with my poor memory.
- For codes, the system should be http://dicom.nema.org/resources/ontology/DCM.
- For value sets/context groups, the canonical url of the value set should be the appropriate section of the chunked html version of the standard (e.g., http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html for modality). The system URL of the codes in the value set is the DICOM ontology, or the LOINC code system, etc.
- SOP classes and other OIDs should use urn:dicom:uid (or, perhaps, urn:ietf:rfc:3986 -- there is some ambiguity) as the system.
- RSNA and LOINC have changed the documentation for Radlex codes since we orginally wrote the binding. I'd point you at the "LOINC/RSNA Radiology Playbook and Playbook Core" section of https://loinc.org/fhir/ to get the latest value set.
Diana_Ovelgoenne (Jul 09 2021 at 08:01):
@Elliot Silver thanks for the answer, i have updated my canonicals as per your example. still a little fuzzy to handle with shorthand.
@Chris Moesel I am doing the recommendation from Elliot to put the full URL at the canonical, but sometimes, not always, sushi complains that I need to put a code system rather than this URL. I am truncating in those scenarios from the definition "http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_3805.html#CID_3805" to "http://dicom.nema.org/medical/dicom/current/output/chtml/part16#CID_3805" and then sushi doesn't complain. But this is happening just with some of the CID values I need to put in, not with all. Do you happen to know why there's this inconsistency? Or how I shall better handle it?
Abderrazek Boufahja (Jul 09 2021 at 08:01):
I kept the warnings related to DICOM ValueSet not found by validator, I will suppose that the canonical URL is well (thanks @Elliot Silver for having already confirmed this). I have another error from the same kind :
Error from server: Unable to provide support for code system http://snomed.info/srt
This happen when I reference the DICOM value sets as "include" within a new value set: https://build.fhir.org/ig/HL7/fhir-radiation-dose-summary-ig/ValueSet-radiopharmaceutical-rds-vs.html . The Publisher try to create a global expand of the new value set, and end up with an error:
image.png
and the error reported below about the code system http://snomed.info/srt
http://snomed.info/srt is an old code system used by DICOM, and the latest version of DICOM has migrated to SCT. Thus, I think somewhere in the terminology server there are old DICOM value sets with the old codes from SRT and not SCT. But, I cannot be sure about it.
Chris Moesel (Jul 09 2021 at 15:54):
@Diana_Ovelgoenne -- I do not have any specific knowledge about DICOM or the nuances of using it in FHIR, so please consider that as you read my response! ;-)
When I download the "FHIR JSON" from http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_3805.html, it gave me a ValueSet definition containing SNOMED-CT codes. But it sounds like you want to reference CID 3805 as a code -- not a ValueSet. Is that right?
As @Elliot Silver noted above, FHIR defines http://dicom.nema.org/resources/ontology/DCM as the proper canonical URL for DICOM Controlled Terminology codes, but I've noted that it does not contain CID 3805 as a valid code (perhaps because it only includes codes from Chapter D?).
The problem with using http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_3805.html when referencing a code is that this URL is actually the canonical for a ValueSet (which I confirmed by downloading the FHIR JSON for it). You cannot use a ValueSet canonical as the system URL for a code. You can only use a CodeSystem canonical as the system URL for a code.
When you do {url}#{code} in FSH, SUSHI tries to resolve the URL to ensure it is a valid CodeSystem URL. If it resolves to something else (like a ValueSet), SUSHI will emit an error. But if SUSHI cannot resolve it, then SUSHI assumes it is OK (because it would be annoying if SUSHI emitted an error for every URL it cannot resolve to a definition). This explains why you sometimes get errors and sometimes do not -- it all depends on if the URL you're using is recognized by SUSHI or not. And whether or not it is recognized may depend on what dependencies you've declared in your config.
Elliot Silver (Jul 09 2021 at 16:29):
@Diana_Ovelgoenne, you mention "http://dicom.nema.org/medical/dicom/current/output/chtml/part16#CID_3805". The actual canonical URL for that value set is "http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_3805.html". Also, I don't see any SNOMED RT codes in the radiopharmaceutical value set you mention (there are a couple listed as synonyms, but none as primary values), so I'm not sure where your error is from.
Just to make sure there isn't some confusion: there is a canonical URL that defines a code system. All codes from that system are qualified by that canonical URL, this is how we tell 12345 in SNOMED CT from 12345 in DICOM. Separately, there are value sets, which identify sets of codes from one or more code systems that can be used together for a purpose, like the radiopharmaceutical value set. The value set also has a canonical URL as its identifier, but that is the identifier of the value set, not the system for the values in the value set. The value set URL doesn't actually show up in a resource instance, only in profile or resource definitions. It is the code system for the code used that is included in the resource.
@Chris Moesel, although I don't think it applies to this case, I believe fragments are allowed in canonical URLs. Is there some way to use such a code system in FSH? e.g. "http://some.sdo.org/CodeSystems.html#systemABC#1234" (code value 1234 in code system "http://some.sdo.org/CodeSystems.html#systemABC")?
Chris Moesel (Jul 09 2021 at 17:14):
@Elliot Silver -- regarding your last question -- that's a good point. I was kind of hoping that SUSHI would do the right thing (and use the last # as the separator), but it seems that it uses the first instead: https://fshschool.org/FSHOnline/#/share/3htRJDk
I tried to see if maybe using an alias would take care of it, but that reveals a different problem: https://fshschool.org/FSHOnline/#/share/3yH3b4t
(sigh)
Chris Moesel (Jul 09 2021 at 17:14):
I'll log the bugs.
Chris Moesel (Jul 09 2021 at 17:24):
Logged as SUSHI#872 and SUSHI#873.
Diana_Ovelgoenne (Jul 12 2021 at 10:06):
@Elliot Silver All what you have been saying works fine for the CID, but what is it with the TID objects? Their concept name is e.g. "TID 3911 Plaque Properties", they aren't codified, whereas the canonical is http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_TID_3911.html. So if I would want to represent this as a Parent Observation's code in FSH I would put "http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_TID_3911.html" only? I assume FSH would be expecting a value for the code and not just the code system.
Elliot Silver (Jul 12 2021 at 22:34):
@Diana_Ovelgoenne, I don't understand, are you trying to treat the template IDs as codes, or having trouble with the codes used within the template? The codes within the template should be straight forward: EV (122376, DCM, "Total Plaque Volume") is value 122376 from code system http://dicom.nema.org/resources/ontology/DCM. I don't know that there is a defined value set of the template IDs, but I suppose we could ask for DICOM to create one, if you need it.
Diana_Ovelgoenne (Jul 13 2021 at 06:25):
@Elliot Silver what I need is the template IDs as codes, if you see the example I copied http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_TID_3911.html the templates are nested (see calcium scoring results in line 4), so I need an identifier per template so when I put them into FHIR, I can say code = TID Id. I can't use the Total plaque Volume as a whole identifier of the properties, because this is just one out of the 6 defined.
My idea is to have a Diagnostic Report using this http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CTMRCardiovascularAnalysisReportTemplates.html
where each section, but 2 (the DCM ones), is a Parent Observation which needs a code. and if you dig in this template you will see that there are many references to different TIDs.
Abderrazek Boufahja (Jul 13 2021 at 12:45):
regarding the error I get : unknown Code System, I think I found it.
Error from server: Unable to provide support for code system http://snomed.info/srt
It is related to the DICOM value sets in tx.fhir.org : http://tx.fhir.org/r4/ValueSet/dicm-25-Radiopharmaceuticals
This ValueSet in the tx server is an old version (20160314) of the value set http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_25.html
The value set in the tx server refer to the code system http://snomed.info/srt , however the value set in DICOM website refer to http://snomed.info/sct : ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/xml/CID_25.xml (this is a move made by DICOM during last year I think).
Elliot Silver (Jul 13 2021 at 20:03):
@Diana_Ovelgoenne If I understand you correctly, you're trying to recreate a DICOM SR attribute-for-attribute in a FHIR DiagnosticReport/
Composition, which is a use case I'd never considered (and I'm not sure I support). There isn't an obvious code system or value set to use for the TIDs, although you could use your own, at least for now. I suggest discussing this with II/WG-27, both as to whether this encoding is the best approach, and how to resolve the terminology issues. There are a couple of other "codes" used in DICOM (like the list of SOP classes, or false-color pallettes) that also need value sets defined, so this could be done at the same time.
Elliot Silver (Jul 13 2021 at 20:06):
@Abderrazek Boufahja , I think this needs @Grahame Grieve to work with @David Clunie to ensure that updates to the DICOM terminology gets into the terminology server on a regular basis.
John Moehrke (Jul 13 2021 at 21:04):
yes, I have opened this topic multiple times... I think we need an advocate on the vocabulary HTA team to get the right things done. Im working on similar with IHE...
John Moehrke (Jul 13 2021 at 21:05):
with IHE I have taken the additional step to wrap the codeSystem and valueSet resources into an IG; which I think will help with the situation, but as of now don't have any evidence that it is better
Chris Moesel (Jul 26 2021 at 20:38):
@Elliot Silver -- regarding how to specify a code whose system has a fragment in it (SUSHI #873), apparently I totally forgot that you can escape the # sign:
http://some.sdo.org/CodeSystems.html\#systemABC#1234
Proof it works. Sorry it took us so long to figure out that it's been working all along.
Elliot Silver (Jul 26 2021 at 22:47):
Well, that's obvious... once you point it out.
@Diana_Ovelgoenne, not sure if this is helpful to your issue.
Last updated: Apr 12 2022 at 19:14 UTC
