FHIR Chat · DICOM providing FHIR CodeSystems and ValueSets · terminology

Stream: terminology

Topic: DICOM providing FHIR CodeSystems and ValueSets

John Moehrke (May 20 2019 at 13:27):

Note that DICOM now is publishing FHIR CodeSystems and ValueSets See for example http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_29.html
so, should fhir.ini be updated to point at the FHIR resources DICOM publishes?

Grahame Grieve (May 20 2019 at 13:31):

it already was, I thought

John Moehrke (May 20 2019 at 13:33):

looks to me like fhir.ini is importing the HTML.. but maybe I am just interpreting the error message the build gives

Grahame Grieve (May 20 2019 at 13:39):

well, it's supposed to be happening.... make a task for me to check

John Moehrke (May 20 2019 at 14:07):

GF#22483

Michael Lawley (May 21 2019 at 09:46):

publishing FHIR via ftp: -- new kid @ old school!

Robert McClure (May 23 2019 at 15:40):

Kool... But in my quest to best understand how FHIR canonical uri(url) should be used I want to highlight what DICOM is doing in their FHIR content. So here is the example John pointed to and I'll note that they have defined the url with .html at the end. I suspect, but @Grahame Grieve please correct me if I'm off base here, that we should discourage this sort of uri. In fact I'd think we'd prohibit it as it's confusing.

{
    "resourceType":"ValueSet",
    "id":"dicom-cid-29-AcquisitionModality",
    "url":"http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_29.html",
    "identifier":[
        {
            "system":"urn:ietf:rfc:3986",
            "value":"urn:oid:1.2.840.10008.6.1.19"
        }
    ],
    "version":"20190327",
    "name":"AcquisitionModality",
    "status":"active",
    "experimental":"false",
    "date":"2019-04-25",
    "publisher":"NEMA MITA DICOM",
    "description":"Transitive closure of CID 29 AcquisitionModality",
    "copyright":"© 2019 NEMA",
    "compose":{

I'd also say that it seems that the rest of the url path also makes me worried this is really a current server ID and not really a canonical uri.
Am I correct and if so, who will contact DICOM to clarify.

Grahame Grieve (May 23 2019 at 19:28):

absolutely agree. they should not be using .html

Michael Lawley (May 24 2019 at 01:26):

BUT...It is a URI and not a URL, so there's no real technical problem here.

Grahame Grieve (May 24 2019 at 03:00):

right it's not no-conformant. it's just a bad idea

Robert McClure (May 24 2019 at 03:20):

This just highlights that we are not giving useful advice on what a good canonical uri should be. Just look at that uri - it is clear they don't know what it is actually intended to be - a permanent identifier for the value set. As fast as FHIR is running, we have to get ahead of this before this sort of uri becomes imbedded everywhere.

Grahame Grieve (May 24 2019 at 03:31):

actually the advice was given...

Robert McClure (May 24 2019 at 03:51):

then perhaps more than advice is needed - seriously.

Grahame Grieve (May 24 2019 at 05:36):

@David Clunie - have you any thoughts about this?

David Clunie (May 24 2019 at 10:40):

Per the ValueSet.url definition: "the canonical URL that never changes for this value set - it is the same in every copy. The element is named url rather than uri for legacy reasons and to strongly encourage providing a resolvable URL as the identifier whenever possible. Ideally, it should be a literal URL that is the location of the master version of the value set, though this is not always possible".From DICOM's perspective, the URL with ".html" is intended to be permanent and never change, and it is resolvable, and also renderable. Further, since the URL is not supposed to change, and hasn't since 2013 (the target, not the FHIR resource that references it) when DICOM started publishing the chunked HTML form of the standard, it would be annoying if FHIR forbade reference to it retrospectively and required it to be changed (which would rather defeat the purpose of the "never changes" requirement).

Robert McClure (May 24 2019 at 15:48):

@Grahame Grieve @David Clunie's approach to this IMHO highlights the problem that occurs when we overload the meaning and use of a single model element, particularly one as important as this. I say this with my focus specifically on terminology artifacts which I think have some particularly difficult characteristics such as
The need to see the content (render via html) and also manipulate the jason/xml content via api (yes I know that is generally useful for other resources but it is a requirement for value with terminology
1. Frequent (although not in this specific case) version changes with a need to access and use prior versions,
2. Support federation of the resource across many locations. By this I mean understanding that there should be a source of truth location for the resource but that resource may be stored in many other places and somehow communicate that when found, that specific instance may not be the defined SOT.
There are other issues but I do think we need to decide what is the absolute best way to structure this in the various use cases. So DICOM has decided they want the uri to be the url of the permeant renderable view of the current content version. OK, I can understand that. What I want is the FHIR community to discuss and agree what is the best approach for:
1. a terminology authority that creates content and provides no FHIR access points at all (but might in the future)
2. a terminology authority that creates content and only will support FHIR resource access?
3. a terminology authority that creates content, supports access, and also provides a terminology service? @David Clunie does DICOM provide terminology services now? In the future?
It seems his argument is logical: you want the permanent resolvable location and we used the permanent resolvable and renderable url. We certainly have 1000's of those in the spec already, why didn't we do the same thing? What should we encourage others to do: What the FHIR spec currently does or what DICOM did?

John Moehrke (Jun 21 2021 at 14:58):

Is there a problem with the DICOM (DCM) codes in the new terminology release? I am noticing new warnings about valuesets that I am using DICOM codes from.

John Moehrke (Jun 21 2021 at 15:54):

it does not seem to be a general DICOM code problem. I am able to use dicom codes for AuditEvent.type, I am unable to use AuditEvent.agent.type dicom codes

Grahame Grieve (Jun 21 2021 at 19:15):

what, specifically?

John Moehrke (Jun 21 2021 at 19:29):

I am getting this warning on all my examples in the MHD on AuditEvent

[Unable to determine whether the provided codes are in the value set http://hl7.org/fhir/ValueSet/participation-role-type because the value set or code system is not known to the validator]

John Moehrke (Jun 21 2021 at 19:29):

http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/qa.html

John Moehrke (Jun 21 2021 at 19:30):

https://github.com/IHE/ITI.MHD

John Moehrke (Jun 22 2021 at 12:12):

note, it seems to be working now on the build site too. magic

David Simons (Sep 22 2021 at 10:41):

Came across this thread today, in the context of bridging DICOM and FHIR...

@David Clunie Happy to see that DICOM is using FHIR artifacts to distribute CodeSystems, ValueSets, ConceptMaps increasingly.
For example: ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/xml/CID_228.xml.

Are you guys planning to distribute these as versioned FHIR NPM packages via an NPM package server, current and historical versions? (see https://confluence.hl7.org/display/FHIR/NPM+Package+Specification)
and use via package dependencies (in build pipelines and deployments)

E.g a package org.nema.dicom#20190327that includes all corresponding DICOM FHIR-artifacts.

Grahame Grieve (Sep 22 2021 at 10:42):

sorting this out is on my todo list

Diana_Ovelgoenne (Oct 19 2021 at 10:57):

I am testing several of the DICOM provided Valuesets; however they cannot be consumed out of the box.
Issue for @David Clunie : the name of the IGPublisher complains about the names of the files being e.g. CID_4222.json instead of ValueSet-dicom-cid-4222-OphthalmicMacularGridProblem.json. Each CID file needs to be renamed manually. Can the file names be modified at the DICOM level so not each implementor has to modify the files manually? (There are too many CIDs).
Issue for @Grahame Grieve : the IG Publisher doesn't accept the definition of the ValueSets as "experimental":"false", it pops the following validation error: ValueSet.experimental (l15/c28) error Error parsing JSON: the primitive value must be a boolean. Is there something wrong in the syntaxis or on the IG Publisher side? This happens with any of the Value Sets published by DICOM.
ValueSet-dicom-cid-4222-OphthalmicMacularGridProblem.json

Elliot Silver (Oct 19 2021 at 16:08):

@Diana_Ovelgoenne, I suspect the issue with "experimental" is that true and false don't need to be quoted -- they're primitives not strings.

Diana_Ovelgoenne (Oct 20 2021 at 06:16):

Then something more for @David Clunie to get fixed for the ValueSets to be usable :wink:

@Jonathan Whitby : Please be aware of this, maybe you can help to move forward the fixing of the CIDs.

David Clunie (Oct 20 2021 at 12:47):

For the next (2021e) DICOM release of the standard, which you can expect to see later in November 2021, and the value set resources that will be updated at that time, I will use a boolean value for "experimental" in the JSON files, as well as change their names to be ValueSet-keyword.json|xml, e.g., ValueSet-dicom-cid-4222-OphthalmicMacularGridProblem.json. Note that I would not get too committed to specific keywords if I were you, since the code to generate them automatically from the titles of the tables is crude, and though it removes special characters and whitespace, it does not yet capitalize conjunctions, etc.. So this may change in future until DICOM defines official keywords for context groups and persists rather than generates, which we haven't yet done. Very few will change though (e.g., OphthalmicMacularGridProblem won't, MedicationforSmallAnimalAnesthesia et al probably will).

Grahame Grieve (Oct 21 2021 at 03:57):

I'm trying to follow all this, but I can't. @Diana_Ovelgoenne where are you getting that error? how can I reproduce it?
@David Simons the dicom value sets are not published as an NPM package by DICOM, so we put them in the package fhir.tx.support as a stop gap measure, but these are not maintained as up to date.

@David Clunie we have gone to npm packages as a way to distribute FHIR content, and pretty much all the tools are converging on this. Can I help DICOM publish the value sets and the code system as an NPM package ?

Diana_Ovelgoenne (Oct 21 2021 at 07:16):

@Grahame Grieve I changed the syntax as Elliot said, and there is no error coming from IG Publisher. All cleaning work needs to be done on the DICOM side for the Value Sets to be used out of the box, thanks anyways.

David Simons (Oct 21 2021 at 07:18):

Grahame Grieve said:

David Clunie <cut> Can I help DICOM publish the value sets and the code system as an NPM package ?

Glad to review and test - helping bridge DICOM and FHIR. Here's the spec, btw: https://confluence.hl7.org/display/FHIR/NPM+Package+Specification

David Clunie (Oct 21 2021 at 11:10):

@Grahame Grieve, you are welcome to re-package whatever you want however you want after each DICOM release of the updated content on our ftp server. There is a public notice of each release (sent to a large mailing list, which you may or may not be on already), but if you like I can try and remember to specifically notify you.

Grahame Grieve (Oct 21 2021 at 11:11):

well, I can do that. I was kind of hoping you could build something into your side :grinning:

Grahame Grieve (Oct 21 2021 at 20:02):

if I/we create a DICOM package, how would it be identified?

nema.dicom.fhir
fhir.dicom
dicom.fhir

?

And the version... DICOM uses 2021d but I need to use semver. So it would be...? @David Clunie have you looked at semver for dicom before?

Grahame Grieve (Oct 21 2021 at 20:05):

and I don't think, after looking in my email, that I'm on the list for notice of new release - how do I get on it?

David Simons (Oct 22 2021 at 12:35):

David Clunie said:

... after each DICOM release of the updated content on our ftp server....

My hope, for one, would be for DICOM to evolve from ftp based distribution of files, to NPM package distribution (via http), and particularly FHIR NPM packages for the codes and valuesets. I think that is also what Graham is proposing (requesting).

Note that more and more browsers are dropping ftp:// support, incl. Chrome (https://www.chromestatus.com/feature/6246151319715840)

David Clunie (Oct 25 2021 at 16:10):

That's why real programmers use the command line, and know where to find an ftp client if they need one :)

David Clunie (Oct 25 2021 at 16:11):

Grahame Grieve said:

if I/we create a DICOM package, how would it be identified?
...
And the version... DICOM uses 2021d but I need to use semver. So it would be...? David Clunie have you looked at semver for dicom before?

DICOM WG 6 should probably consider this, and a request should come from DICOM WG20/HL7, since someone will probably have a preference +/- a reason for their preference. I haven't considered changing how DICOM labels our releases, since the system we have been using works just fine for us, and we don't need to fight religious wars about how our releases are identified, and we don't need to chase every fad.

Grahame Grieve (Oct 25 2021 at 18:21):

I don't think that you should change how you label your releases, we should just figure out a consistent way to map that into semver, since I won't be the only person to ever ask that question

Grahame Grieve (Oct 25 2021 at 18:21):

anyway, there are people hanging out for this, so how long till there might be an answer?

Grahame Grieve (Oct 25 2021 at 18:23):

@Christopher Lindop @Jonathan Whitby can we initiate a request?

Grahame Grieve (Oct 25 2021 at 18:29):

that is:

• HL7 would like to package up the dicom codes for release as a FHIR Npm package, for convenience for the FHIR implementers, since that is how all FHIR content is being distributed now.
• @David Clunie has suggested that we do the packaging after each release
• in order to do that, we need to agree on a package name, which will be something like fhir.tx.dicom, dicom.fhir, fhir.dicom, or nema.dicom.fhir. All of those are valid, but it's not clear which is best
• there's a practical concern: what other dicom related npm packages might be released? For this reason, 'fhir' should be part of the name - this is the FHIR package for dicom
• there's a branding concern - if I am packaging it up, should it be fhir.tx.dicom? (my person preference). Or does dicom want to own the name - dicom.fhir or dicom.tx.fhir...
• Also, npm requires each package have a semver assigned (https://semver.org/). so we have to map the dicom versioning to semver in some rational way that is reasonable to users

Elliot Silver (Oct 25 2021 at 20:20):

• I would leave NEMA out of the package name. They provide the secretariat for DICOM, and it is conceivable (although unlikely) that DICOM could move to another organization. That said, i HL7/ @Grahame Grieve is doing the packaging, I'd suggest Grahame choose whatever package name he prefers.
• The simplest mapping of DICOM releases to semver would be to turn the year into the major version, and release within the year (a, b, c,...) into minor version. This isn't a perfect mapping, but I think is most straightforward. DICOM is "fully backwards compatible," so we could use major version 3 (the current version), and minor version corresponding to release (1996 - 3.1, 1998 - 3.2, 2021a - 3.45, ...) however that means having to go back and figure out what the current minor version would be.
  Despite the "fully backwards compatible" position, DICOM regularly removes terminology, particularly as the terms are adopted into SNOMED, so from a terminology point of view, each release has the potential to be a breaking release. Therefore, we could also consider each release is a major release (maybe 2021a - 20211, 2021b - 20212).
  DICOM also uses last update date as version for value sets. We could look at that as an option as well (20210515 as major version?).
  With all those options, I don't think any is particularly better technically than another, and to me, my first option seems the most straightforward.

David Simons (Oct 26 2021 at 14:52):

org.nema.medical.dicom.valuesets.fhir|2021.d.0 ?!

if it contains all of ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/*
so leverage that naming scheme.

(packaging would not only be done for uploading to tx.fhir.org and registry.fhir.org)

and correspondingly the http://dicom.nema.org/resources/ontology/DCMcodesystem artifacts
(the latter is the canonical used in the valuesets)

Grahame Grieve (Oct 29 2021 at 04:14):

@David Clunie a different question - sorry to keep bothering you about this... does Dicom publish an updated version of the code system underlying most of these value sets? At the moment, we are working off this one, which is not up to date:

https://hl7.org/fhir/codesystem-dicom-dcim.html

This is the master, right? ftp://medical.nema.org/MEDICAL/Dicom/Resources/Ontology/DCM/dcm.owl

Grahame Grieve (Oct 29 2021 at 06:52):

well, ok, here's a draft package for comment. @David Clunie one more thing: you have Ids longer than 64 characters in some of your resources.

Grahame Grieve (Oct 29 2021 at 06:52):

fhir.dicom2021.3.0.tgz

Grahame Grieve (Oct 29 2021 at 06:53):

I'm proposing to use a simple versioning system: major = year, then a number for consecutive releases 1.2.3.4, and .0. What I really want is predictable, and not to misuse patch version

Grahame Grieve (Oct 29 2021 at 06:56):

anyway, if people are happy with this, I'll write up how to produce /release it, and release it into the package system.

Releasing a new version is pretty simple:

• use an FTP client to make a local copy of ftp://medical.nema.org/MEDICAL/Dicom/Resources
• run the IG publisher with the parameters -dicom-gen -src {folder} -dst {folder} -ver 2021.3.0
• release it like other fhir.xx packages (documented elsewhere, done by the FHIR product manager or delegate)

David Clunie (Oct 29 2021 at 09:43):

Grahame Grieve said:

David Clunie a different question - sorry to keep bothering you about this... does Dicom publish an updated version of the code system underlying most of these value sets? ...

This is the master, right? ftp://medical.nema.org/MEDICAL/Dicom/Resources/Ontology/DCM/dcm.owl

Yes . Also, within the OWL file there is version information, e.g., "<owl:versionInfo>2021d_20210910</owl:versionInfo>". The same file is also available from the NCBI BioPortal at "https://bioportal.bioontology.org/ontologies/DCM".

David Clunie (Oct 29 2021 at 09:47):

@Grahame Grieve BTW. You don't have to retrieve all the individual files via ftp; they are packaged with each release in the higher level directory at "ftp://medical.nema.org/MEDICAL/Dicom/Resources/valuesets", e.g., "DICOM_ValueSets2021d_release_fhir_json_20210910144211.zip"

David Clunie (Oct 29 2021 at 09:51):

@Elliot Silver FYI, when I release updates to DICOM, I generally append a datetime stamp down to the second, since if I realize later in the same day that I have screwed something up for a release, I pull it back and put out a new one; i.e., the time may matter as well as the day. I haven't been doing that for the DCM OWL file though.

David Clunie (Oct 29 2021 at 10:02):

@Elliot Silver DICOM does not "remove terminology", rather we flag retired DCM codes as such (you will see that in the OWL file). We do remove codes for concepts from value sets, or replace them, though, if that's what you were referring to, though in general we do try to retain the same "concept" even if it is referred to by an updated code. I.e., you might think of our context groups (value sets) as tables of code-independent concepts, which may be identified by different codes over time, if that distinction makes sense. Of course when the scheme one relies on fundamentally changes its concept model, we encounter problems (e.g., see our recent paper on what the Abdomen means in SNOMED: "https://onlinelibrary.wiley.com/doi/10.1111/joa.13384" ).

Elliot Silver (Oct 29 2021 at 16:05):

David Clunie said:

FYI, when I release updates to DICOM, I generally append a datetime stamp down to the second, since if I realize later in the same day that I have screwed something up for a release, I pull it back and put out a new one; i.e., the time may matter as well as the day. I haven't been doing that for the DCM OWL file though.

So, a mapping into semver could be something like 2021.4.20210910144211 (which would match the release above)?

David Clunie said:

DICOM does not "remove terminology", rather we flag retired DCM codes as such (you will see that in the OWL file). We do remove codes for concepts from value sets, or replace them, though, if that's what you were referring to, though in general we do try to retain the same "concept" even if it is referred to by an updated code.

Sorry, you're correct, I forgot that we flagged the terms as retired, such as (from DICOM Part 16, Table D-1) but don't actually remove:

Grahame Grieve (Oct 29 2021 at 18:25):

I think it would be super tiresome to put the time in the version, and I'm not going to releasing packages more than once on a day, so it's just year.release.date

Robert McClure (Oct 29 2021 at 20:55):

@Carol Macumber @Reuben Daniels I think we need to capture some of this in the official DICOM pages. Just not sure what

Grahame Grieve (Oct 29 2021 at 22:22):

Some doco here. https://fhir.org/packages/fhir.dicom/. You can add to that if you want

Grahame Grieve (Oct 29 2021 at 22:22):

Anyway, this package is released now

David Simons (Nov 01 2021 at 11:02):

Grahame Grieve said:

Anyway, this package is released now

Will you list it in "https://registry.fhir.org/" as a normative source, too?

Or would that be a DICOM SDO responsibility? (yes, in my view)

Grahame Grieve (Nov 01 2021 at 19:53):

it should automatically be in registry.fhir.org

Grahame Grieve (Nov 01 2021 at 19:53):

that's what I meant when I said 'released'

Grahame Grieve (Nov 01 2021 at 19:54):

but I see that it's not.

Grahame Grieve (Nov 01 2021 at 19:54):

@Matthijs van der Wielen ?

Matthijs van der Wielen (Nov 02 2021 at 08:51):

@Grahame Grieve It seems something is causing an issue with the tool that reads the package feeds.
The package.json looks like this when I install it locally:

{
"tools-version": 3,
"type": "fhir.ig",
"license": "free",
"author": "FHIR Project for DICOM",
"name": "fhir.dicom",
"url": "http://fhir.org/packages/fhir.dicom",
"canonical": "http://fhir.org/packages/fhir.dicom",
"version": "2021.4.20210910",
"fhirVersions": [
"4.0"
]
}

I will look into this a bit more.

Matthijs van der Wielen (Nov 02 2021 at 10:08):

It could be that the tool is tripping over the fhirVersion in the package.

David Simons (Nov 02 2021 at 16:00):

thanks!

PS: I still don't like the package name fhir.dicom... recommending org.nema.medical.dicom.valuesets.fhir, given the content originates from ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/* as authoritive source.

John Moehrke (Nov 02 2021 at 16:14):

why does it need "fhir" in the package name at all?

John Moehrke (Nov 02 2021 at 16:14):

these codes are used well beyond FHIR

Robert McClure (Nov 02 2021 at 17:44):

I think it is helpful (but this should be by rule, not haphazard) to have fhir in the name because it contains fhir-resource formatted content. Not all packages contain fhir resource content, correct?

Elliot Silver (Nov 02 2021 at 18:39):

The package name should probably follow the same pattern as for other external code systems packaged by FHIR, and I suggest not including NEMA (who are the current secretariat of DICOM, but that theoretically could change), or an ftp path (which, I pray, will change).

Grahame Grieve (Nov 02 2021 at 22:31):

fhir.dicom = the fhir package for dicom. There could (should!) be other npm packages for dicom

Grahame Grieve (Nov 02 2021 at 22:33):

@Matthijs van der Wielen that is what the package.json looks like, yes.

David Simons (Nov 03 2021 at 08:55):

Note that I am proposing a package name like org.nema.medical.dicom.fhir.r4 based on the canonical urls in the ValueSets (and CodeSystem), not on the ftp source alone (though they seem to go hand in hand, as DICOM permalinks)!

Example

{"resourceType":"ValueSet",
"id":"dicom-cid-12308-UltrasoundShearWaveMeasurements",
"url":"http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_12308.html",
...

{"resourceType":"CodeSystem",
"id":"DCM",
"url":"http://dicom.nema.org/resources/ontology/DCM",

Matthijs van der Wielen (Nov 03 2021 at 11:36):

@Grahame Grieve The thing that seems to trip up the tooling is the fhirVersions which is 4.0 and not 4.0.0 or 4.0.1. Would it be possible to change the fhirVersions to one of the valid semvers?
I am aware that fhirVersions is not mandatory according to the package specification on confluence, but that seems to be an ongoing discussion.

Grahame Grieve (Nov 03 2021 at 17:58):

you should really update your tooling to email the feed owner with the details of errors. It'd be much better than where we are currently

Grahame Grieve (Nov 03 2021 at 18:06):

well, I re-issued the same package

David Simons (Nov 09 2021 at 14:51):

should the canonicals not use https:// instead of http://
(so here starting with https://fhir.org/packages)
from a security/deprecation perspective?

alternatively the server should do a rewrite

image.png

</constructiveFeedback> :)

Grahame Grieve (Nov 09 2021 at 18:26):

redirect is on my todo list

John Moehrke (Nov 11 2021 at 21:10):

the fhir core build does not seem to be finding the DICOM codes for AuditEvent like it did before. Did something change in the way I should define my valueSets to pull in dicom codes? @Rob Hausam @Grahame Grieve

Grahame Grieve (Nov 11 2021 at 23:11):

what's the evidence?

David Clunie (Nov 23 2021 at 10:55):

David Clunie said:

For the next (2021e) DICOM release of the standard, which you can expect to see later in November 2021, and the value set resources that will be updated at that time, I will use a boolean value for "experimental" in the JSON files, as well as change their names to be ValueSet-keyword.json|xml, e.g., ValueSet-dicom-cid-4222-OphthalmicMacularGridProblem.json ...

2021e has been released and contains these changes in the name of the files, etc., as requested.

John Moehrke (Nov 23 2021 at 13:41):

good timing. I am working on updating FHIR Core for ImagingStudy and the build is not finding the DICOM codes. I presume that will get fixed in a few days.
That said, I am still unsure of the canonical URI to use with any given valueSet. For example with ImagingStudy.series.laterality the current build is binding (example) to

        <valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_244.html"/>

are these canonical URI really the .html and from the chtml rendering? Or is there a canonical URI that is independent of the human-rendering-of-dicom-specification?

John Moehrke (Nov 23 2021 at 16:29):

looking at the DICOM published ValueSet (json), the URL I am using in FHIR core ImagingStudy is the right canonical URI.

John Moehrke (Nov 23 2021 at 16:30):

so... It seems we need @Rob Hausam and/or @Grahame Grieve magjic to get these DICOM codeSystems and valueSets available to the FHIR core build.

John Moehrke (Nov 23 2021 at 17:07):

I am noticing that there is a codesystem-dicom-dcim.xml in the FHIR core build under source/codesystem
is this right? Or is this getting in the way?

John Moehrke (Nov 23 2021 at 17:10):

<CodeSystem xmlns="http://hl7.org/fhir">
  <id value="dicom-dcim"/>
  <url value="http://dicom.nema.org/resources/ontology/DCM"/>
  <identifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:1.2.840.10008.2.16.4"/>
  </identifier>
  <version value="01"/>
  <name value="DICOM Controlled Terminology Definitions"/>
  <status value="active"/>
  <date value="2015-04-20"/>
  <publisher value="NEMA/DICOM"/>
...

John Moehrke (Nov 23 2021 at 17:48):

I can build after removing this xml, reference to html from terminologies-system.html, and fhir.ini explicit build of this codesystem... BUT canonical URI to dicom, are still seen as HTML pages and not calls for a canonical URI of a ValueSet.

John Moehrke (Nov 23 2021 at 19:28):

Note the following ValueSets are used in FHIR core
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_404.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_401.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_403.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_400.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_405.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7010.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_B.5.html#table_B.5-1"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_244.html"/>
<valueSet value="http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_402.html" />

Grahame Grieve (Nov 23 2021 at 23:48):

what exactly does 'not finding the dicom codes' mean? What's the specific error message?

Grahame Grieve (Nov 24 2021 at 01:22):

@David Clunie you described the new release as 2021e, but when I look in the dcm.owl file, I see

<owl:versionInfo>2021d_20210910</owl:versionInfo>

Elliot Silver (Nov 24 2021 at 04:59):

I look to me like the OWL file wasn't updated, but the files in the valuesets directory have been updated.

David Clunie (Nov 24 2021 at 13:00):

Grahame Grieve said:

David Clunie you described the new release as 2021e, but when I look in the dcm.owl file, I see

<owl:versionInfo>2021d_20210910</owl:versionInfo>

Fixed.

John Moehrke (Nov 24 2021 at 13:29):

John Moehrke said:

I can build after removing this xml, reference to html from terminologies-system.html, and fhir.ini explicit build of this codesystem... BUT canonical URI to dicom, are still seen as HTML pages and not calls for a canonical URI of a ValueSet.

@Grahame Grieve I did not say code is not found. I said the ValueSet is not. Every place where a DICOM canonical URI (which has .html at the end) is used; it seems to me that the FHIR core presumes this is just a web page and not a canonical URI to a ValueSet.

John Moehrke (Nov 24 2021 at 13:46):

This is why I posted all of the dicom ValueSets that FHIR core calls for, each of them are not brought into the FHIR core build as a valueSet, but rather as a browser link.

Grahame Grieve (Nov 24 2021 at 19:11):

thanks @David Clunie updated Dicom package is now published.

Grahame Grieve (Nov 24 2021 at 19:11):

it seems to me that the FHIR core presumes this is just a web page and not a canonical URI to a ValueSet.

not at all. What's' the actual error?

John Moehrke (Nov 24 2021 at 19:12):

there is not a build error. there is just the resulting html publication that does not include ValueSets, but directs a user to the dicom web site.

John Moehrke (Nov 24 2021 at 19:14):

for example on ImagingStudy for laterality
http://build.fhir.org/imagingstudy-definitions.html#ImagingStudy.series.laterality

John Moehrke (Dec 01 2021 at 19:54):

@Grahame Grieve any progress on this?

Grahame Grieve (Dec 12 2021 at 08:34):

hey @David Clunie I just got this:

Dear DICOM Community,

The 2021e release of the DICOM standard is now available from the NEMA site:

http://www.dicomstandard.org/current/

This is what I already processed, right?

David Clunie (Dec 12 2021 at 11:54):

Yes

Diana_Ovelgoenne (Dec 14 2021 at 07:37):

@Grahame Grieve How can the 2021e release be used? The fhir.dicom package in packages2 still contains the version 2021d_20210910 (Sept not Nov version).

Grahame Grieve (Dec 22 2021 at 05:17):

somehow the release process missed updating the critical file, so I just did it by hand - should start working now

David Simons (Jan 10 2022 at 11:15):

Grahame Grieve said:

it should automatically be in registry.fhir.org

@Matthijs van der Wielen
image.png

For now, I will refer people to <https://fhir.org/packages/fhir.dicom/>

Ward Weistra (Jan 10 2022 at 17:04):

@David Simons I assume the issue is that the package feed lists the FHIR version for fhir.dicom as <fhir:version>current</fhir:version>, which is different from the FHIR version in the package.json and probably generally an invalid version? cc @Grahame Grieve

Ward Weistra (Jan 10 2022 at 17:22):

(Yes, we're working on making the output from the package importer public/mailing it)

David Simons (Feb 25 2022 at 11:56):

a small typo @Grahame Grieve (2021 -> 2022) on http://fhir.org/packages/fhir.dicom/

2022.1.20220124: First release for 2022a (2022-01-24)

David Simons (Feb 25 2022 at 14:09):

PS: Why is this fhir.dicom managed separately from https://github.com/FHIR/packages/tree/master/packages/fhir.tx.support.r4/package ?
(under \packages\packages\fhir.dicom now)

Grahame Grieve (Feb 25 2022 at 20:09):

because fhir.dicom is generated from the dicom sources, so there's no version control over the content

Grahame Grieve (Mar 01 2022 at 02:21):

fixed thanks

David Simons (Mar 08 2022 at 11:25):

ok, this is what I now see (one release, earlier three)

image.png

David Simons (Mar 08 2022 at 21:53):

And getting a HL7 Validator warning on the ValueSet-all.json

     vsd-0: 'Name should be usable as an identifier for the module by machine processing applications such as code generation' Rule 'Name should be usable as an identifier for the module by machine processing applications such as code generation' Failed

Recommending to remove the _space_ in the name on the DCM ValueSet

    <url value="http://dicom.nema.org/resources/ValueSet/all" />
    <version value="2022.1.20220124" />
    <name value="All DICOMTerminologyDefinitions" />
    <title value="All DICOM Controlled Terminology Definitions" />

Grahame Grieve (Mar 15 2022 at 04:28):

fixed

David Simons (Apr 12 2022 at 16:21):

Additional question: is it worthwhile to include the DICOM tables like https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html#table_L-1?
As a ValueSet+ConceptMap?

E.g. to do a lookup from DICOM Body Part Examined (0018,0015) String = "KNEE" to SNOMED-CT code = 72696002 .

I don't think these are available as DICOM FHIR artifacts, yet, right?

Last updated: Apr 12 2022 at 19:14 UTC