Strategies for populating ProcedureCode in TID1500

[fedorov]

from a discussion with @dclunie

On Fri, Jul 1, 2016 at 7:19 AM, David Clunie [email protected] wrote:

Hi Andrey

I agree that there is not a lot of value in putting a lot of effort into populating a pre-coordinated code when one is not available in the source images, and certainly no point in bothering the user if the application does not already the modality and body part.

In the degenerate case, if the source was not DICOM and not even the modality is known, one can make the argument that it is sufficient to send a very generic code like (P0-0099A, SRT, "Imaging procedure").

If I were building this myself, I would probably use logic something like this:

• if Procedure Code Sequence present and consistent and valid in source images, use it,
• else if Requested Procedure Code Sequence present inside single item of Request Attributes Sequence and valid, use it,
• else if DICOM images and modality present and consistent in source images, and Body Part Examined or Anatomic Region Sequence present and consistent in source images, use them to look up code in pre-configured list of procedure codes by modality and body part (which can be built from various sources automatically), else
• if DICOM modality but not body part known try using the Finding Site being used for TID 1500 as the body part, else
• if only DICOM modality known look up a modality-specific procedure code, else
• use (P0-0099A, SRT, "Imaging procedure")

I think that something like this would be a useful part of dcmtk, for example, but I don't known if QIICR really needs it right now.

Obviously a robust body part lookup would probably require an "ontology" (e.g., to know that the hippocampus was part of the brain or head, etc.), if the procedure codes were coarse relative to the supplied body parts, but that too is probably beyond the scope.

So, to get back to reality, do you want to use a short list of modality-specific procedure codes ignoring the body part, or do you just want to always use (P0-0099A, SRT, "Imaging procedure") or equivalent if the caller does not supply something more specific, or a code is not available from the images?

Note that there is a 1:1: correspondence between DICOM Modality (0008,0060) code string values, and a corresponding DCM code, e.g., Modality = "MR" maps to (MR, DCM, "Magnetic Resonance"):

http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_D.html#DCM_MR

so apart from having to look to the code meaning, you could use DCM codes for the modality-specific procedures (rather than say (P5-09000, SRT, "Magnetic resonance imaging") or (LP6406-5, LN, "MRI") or (C0024485, UMLS, "Magnetic resonance imaging") or whatever.

This use of meaningful codes for modality in the DCM scheme is very bad coding practice according to Cimino's desiderata, but since it has been done there is no reason not to take advantage of it (although one day we should probably retire this from DICOM and use SNOMED codes instead).

David

PS. For my work on radiation does report construction from dose screens, as well as earlier work for other projects, I also put some effort into hunting down body part in other attributes like series description, but that too is probably beyond the scope of our needs, but see com/pixelmed/anatproc if you are interested.

PPS. (P0-0099A, SRT, "Imaging procedure") is in the DICOM0 SNOMED subset, so it is free to use in the context of a DICOM implementation, but if you want a non-SNOMED equivalent you can look up C0011923 in UMLS:

https://uts.nlm.nih.gov/metathesaurus.html?cui=C0011923

On 6/30/16 5:47 PM, Andrey Fedorov wrote: ...

Ok. Let me rephrase the practical question I have - let's say Procedure Code Sequence is not populated in the corresponding images (which I am sure will be the most common situation). How do you envision the workflow for a generic TID1500 reporting process? Would you like the application to automatically come up with a code, given the knowledge of the image modality, and prompting the user to choose from the constrained list of anatomical structures? Or let the user choose from the list of procedure options?

My personal opinion is that it is somewhat wasteful - we probably cannot come up with an exhaustive list of codes for various permutations of modalities/body parts/etc, so it almost seems like a unique code would need to be generated on the fly by the application, or the application would need to maintain a growing list of codes based on the situations encountered in the field.

Again, perhaps this is another question to discuss as we talk about QIICR progress at the next meeting.