A Modality, by any other name (would smell as sweet ?)

Summary: The use of the term Modality in radiology is old; its definition is vague in various standards, but relatively consistent in terms of both meaning and granularity.

Long version:

I got an email inquiry from Scott N who wrote:

My colleague and I have been discussing the usage of the term "imaging modality" and how it appears (to us) that it is commonly applied ambiguously in the literature. I would roughly define the term to mean "a method involving the employment of a physical agent to produce an image." As MR utilizes electromagnetic waves and PET utilizes positron-emitting isotopes, I would then characterize the two as separate image modalities. However, a quick Google search yields countless examples of statements such as the "DTI and fMRI modalities." By my definition, I would classify DTI and fMRI as the same imaging modality, and I believe the DICOM modality 0008,0060 always gives "MR" for these two types of scans.

I was hoping you mind have a little time to comment on this and on how the DICOM standard defines this?

This prompted me to get a little carried away in researching the matter (this being a quiet Sunday morning, too foggy to fly yet, the dog emptied and my wife absorbed in vacation planning), and I came up with the following.

DICOM defines the Attribute of the Series, Modality, in PS 3.3 C.7.3.1, to mean:

"Type of equipment that originally acquired the data used to
create the images in this Series"

and then proceeds to provide a list of defined terms (the value set) for the attribute in C.7.3.1.1.1.

Also, in PS 3 C.4.15:

"Type of equipment that originally acquired the data used to create the images associated with this Modality Performed Procedure Step."

In HL7 V2.5 Section 4.5.6.5 the Modality field is defined (in a post-DICOM modality worklist addition to HL7) as:

"The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure."

In IHE, the Acquisition Modality Actor is defined in RAD TF Vol 1 Section 2.3 as:

"A system that acquires and creates medical images while a patient is present, e.g. a Computed Tomography scanner or Nuclear Medicine camera. A modality may also create other evidence objects such as Grayscale Softcopy Presentation States for the consistent viewing of images or Evidence Documents containing measurements."

Surprisingly, RadLex doesn't provide a text definition for its Imaging Modality concept (http://www.radlex.org/RID/RID10311), only relationships to parent and child concepts; this is probably an easily rectified oversight.

SNOMED CT has a concept "Imaging Method" (360037004) for which it has a synonym "Imaging Modality", but again, no textual definition; the UMLS maps this to its "Imaging Modality" concept C1275506.

The UMLS Metathesaurus (https://uts.nlm.nih.gov//metathesaurus.html) also contains a more general concept "Modality" (C0695347).

These map to the NCI Thesaurus (http://ncit.nci.nih.gov/ncitbrowser/) concept of "Modality" (C41147) defined variously as:

"NCIt Definition: A specific manner, characteristic, pattern of application or the employment of, any therapeutic agent or method of treatment, especially involving the physical treatment of a condition.

DICOM Definition: Type of data acquisition device.

NCI-GLOSS Definition: A method of treatment. For example, surgery and chemotherapy are treatment modalities."

Wikipedia says ("http://en.wikipedia.org/wiki/Modality"):

"In medical imaging, any of the various types of equipment or probes used to acquire images of the body, such as radiography, ultrasound and magnetic resonance imaging."

I don't know what the history of the use of the word "modality" in a medical imaging context is, but it would be fascinating to research it. A quick look at the earliest reference in Radiology shows a mention in 1923 of a "therapeutic quartz lamp", which "enables all patients, because of its low cost, to be benefited by the use of this modality" (http://radiology.rsna.org/content/1/4/245.full.pdf). A therapeutic rather than diagnostic radiology use perhaps, but an early similar use all the same (and I found other mention of the term in a similar vein from the same year).

Given the DICOM precedent, I think it is more practical to consider fMRI and DTI as being "sub types" of a single modality MR.

Likewise MR Angiography is also a "sub type" of MR in DICOM, as are other borderline cases, such as MR Spectroscopy, even though there is not always imaging involved (it was once separate, but not any more, in recognition that one can produce spectroscopy-based (chemical shift, metabolite map) images, for example).

We had a big fight years ago in DICOM about introducing an explicit "modality sub-type" attribute, when we were doing visible light "modalities" and ended up with a generic VL from which we carved out specific modalities like ES (endoscopy) and slide microscopy (SL) as specific needs for different information or encoding for those application areas arose. In otherwords, though the technology may remain the same (a digital camera), the different "accessory" if you will (e.g., the endoscope or microscope) and the application area (e.g., gut, slide, retina, cornea) lead to refinements of what a single attribute Modality would refer to, weighed against what was generally done "together" by the equipment. The compounding of these different dimensions leads to some confusion, but, for example, one generally performs MRI, MRA, DWI, DTI, fMRI, DCE-MRI, MRS and CSI all in the same study on the same device (an MR scanner), whereas one would not perform endoscopy (ES) with a slide microscope (SM) even though they are both visible light (VL). Nor for that matter would one general mix upper and lower GI endoscopy in practice, but it has not proven necessary to separate these by a different DICOM Modality value. Similarly, for time-based waveforms, DICOM has relatively specific modality values like ECG, HD, RESP, etc. (even though those waveforms may emerge from the same "device" as that producing accompanying images and certainly be part of the same procedure).

The reason for the fight, by the way, was that some of us wanted the single Modality attribute that is widely implemented in browsers and databases to remain a single, useful, value, and not to require implementation changes to support multiple values for the same attribute or multiple attributes. As always in DICOM, purity is sacrificed in favor of pragmatic and incremental extension of installed base functionality rather than disruptive revolutionary change.

Hybrid modalities like PET-CT (and now MR-PET) lead to some concern about conflating the "equipment" with the "modality", as well as some cardinality issues in models and queries (hence attributes like "Modalities in Study). For DICOM aficionados, one needs to remember that Modality and SOP Class are not synonymous (hence the addition of "SOP Classes in Study", etc.). Theoretically we could have introduced a new single combined modality value for these cases, but in practice the equipment was two distinct modalities "bolted together" (and still is for many vendors) and the downstream applications (e.g. to perform fusion) were novel anyway, and they evolved to cope with the "two" modalities involved in the one procedure.

However, in general conversation (or the scientific literature) where the context is more "granular", I can see why folks use the term "modality" to distinguish such things as fMRI and DTI, but we should probably try and come up with a better term for that "lower level". RadLex, for example, just makes fMRI and MRA "Is a" children of MRI, which is in turn an "Is a" child of Imaging Modality, without providing a definition of what entity those children are; which actually raises an interesting question about whether traditional hierarchical entity-relationship models such as DICOM uses are sufficient for descriptive purposes, or whether "tagging" anything with concepts that depend on an ontology of relationships, semantic web style, adds more value. E.g., should one tag (semantically annotate) a series of images as being an fMRI, without explicitly saying that it is an MR too, such that if (and only if) the recipient had access to the ontology, it would "know" that relationship. Or should one just anticipate that use case and explicitly define that it is an MR and an fMRI in a model that is explicitly encoded? Of course the current state of the art is that one gets an MR modality value and figuring out that it is an fMRI (or any other highly specific "flavor" of MR) is a challenge, but the enhanced family of DICOM objects (with much more detailed attributes and value sets, but still traditional ER models) are intended to help with that.

Anyway, thanks Scott, for the interesting conversation starter.

David

IHE Radiology Planning Committee rejects Image Manager/Archive Content Migration Profile

Summary: Other proposals were judged to have higher priority than the Image Manager/Archive Content Migration Profile.

Long version:

Last week I wrote about a proposal that I had drafted for an Image Manager/Archive Content Migration Profile, to use a an offline archive of standard DICOM objects on an external transportable disk array as an approach to the PACS migration problem.

Unfortunately, as you can see from the minutes of the IHE Radiology Planning Committee t/con, other proposals received higher priority for evaluation by the technical committee, which is the next step before shortening the list further.

Irritatingly, I had let my voting rights on the planning committee lapse, since I hadn't participated in the last few t/cons, and the t/con ran over time and I had to leave before the vote, so I am not sure if any else voted for it anyway.

So, not this year, at least in IHE anyway. That said, the lack of an IHE profile does not mean the one cannot implement the idea (though it does mean that one does not have the IHE Connectathon as a venue for testing it).

David

PACS Migration Using A Standard-format Intermediate Offline Archive

Summary: Creation of an offline disposable archive of standard DICOM objects on an external transportable disk array is proposed as an approach to the PACS migration problem; an IHE profile has been proposed.

Long version:

This isn't actually going to be very long, since most of the content is elsewhere.

On the RCR Imaging Informatics Group there was a recent discussion of PACS migration that arose in the context of the existing contracts expiring some time soon (see "http://www.pacsgroup.org.uk/cgi-bin/forum/show.cgi?2/58490"). During the course of that there was discussion of DICOM "Part 10" format objects, that ultimately lead to a proposal for all PACS to be able to create a a new archive copy on an externally supplied filesystem (directly or network-attached) of standard DICOM files with a standard (lossless) compressed transfer syntax and all the "headers" up to date.

So, since it is that time of year once again, I put together an IHE brief proposal to define an Image Manager/Archive Content Migration Profile for this. Just swap "PACS" for "IM/IA" if you are not familiar with IHE-speak.

This is not a particularly new idea. I recall that many years ago Peter Kuzmak of the VA put forth some suggestions related to an interchangeable archive format for migration with some file system organization and naming as well as potential DICOMDIR-related changes in that context, but using DVD-R; I dug out his old presentation that was referenced from the minutes of the WG 5 meeting in Feb 2000.

Nowadays studies are so large and multitudinous that migrating them on thousands of CDs or DVDs would seem to be infeasible, but the low cost of consumer price-point hard drives and RAID boxes seem to suggest that making what is essentially a "throw away" copy of an entire PACS archive is nowadays realistic. It only needs to last long enough to be populated, reattached to the new PACS and its content imported. The DICOM standard already supports the notion of USB-attached media (physical media unspecified) to allow for flash drives and hard drives, although there may be details that need to be worked through for the sheer size of an entire PACS archive.

Anyway, it remains to be seen how the IHE Radiology Planning Committee receives this, and if they (well, we, since I am a member) don't reject it out of hand, and prioritizes it relative to other profile proposals (since the Technical Committee has limited bandwidth and each year only works on a small number of proposals).

So if any of you out there have any thoughts about whether this is a good idea or a terrible one, or suggestions for improvement of the proposal, please let me know.