VL Photographic Image: Storing pre-coordinated codes that describe a single instance

[Antonio Magni]

Hi,

Standard ADA-1100 defines what the orthodontists need in order to make use of photographs clinically. It includes a list of 80 or so different types of images, and request that these kinds of images be encoded in some way. 

SNOMED has added these codes as pre-coordinated "record artifacts"

We (industry) also need these codes, as they facilitate the placement of the proper images in the proper place. Currently, i devised a temporary scheme for using them in the ViewCodeSequence and i explained how in DENT-OIP/ADA-1107 (which is a draft Implementation guide for ADA-1100):

https://open-ortho.org/dent-oip/nightly/V3_07_DICOM/04_Module_Definitions/170_VL_Image/0054_0220_ViewCodeSequence.html#storing-orthodontic-image-type-in-dicom-implementation-specification

Then we could put them in DICOM CID 4065 and allow the usage of CID 4065 in ViewCodeSequence instead of the modifier.

If i understood David Clunie's reply below properly:

• the Protocol Context Sequence is child of the Performed Protocol Code Sequence, a child of the General Series module;
• Also the Scheduled Protocol Code Sequence is a child of the Requested Attribute Sequence, a child of the General Series module;
• in the Modality Worklist, we can't use the Performed Protocol Code Sequence, because the procedure hasn't been performed yet;
• Both sequences are part of the General Series Module, and thus cannot be used to describe a single instance of a series.

I don't think his recommendations therefore applies to our case. The issue we have, is that we need to describe each instance, while all of the other domains (mammography, dermatology, cardiology, ) seem to need to describe the entire series in a specific way. Regarding the dental full mouth series, (which would seem to be the most similar situation) i think makes use of post-coordinated codes, in various DICOM attributes (which we also do). But as far as DICOM Modality Worklists, i'm not sure if there is a profile that defines how to request a specific type of intra-oral radiograph of a specific tooth.

On Thu, Jul 10, 2025 at 11:00 AM David Clunie <dclunie.com> wrote:

Hi Toni

AFA DICOM is concerned, no action can be taken until a CP is drafted and completed (or
very near completion without any anticipated changes) and then a SNOMED CRS request for the
additional codes to be included in the DICOM subset (and thence the GPS) can be submitted.

This has nothing to do with SNOMED actually creating concepts and their codes to include
in SNOMED CT (which you suggest below has already been done) - that is up to SNOMED (and
ADA if they come from SNODENT) - only their inclusion in the DICOM subset.

Of course, if SNOMED wants to add these to the GPS independently of the DICOM subset before
that point, that's fine too, but we (DICOM) have no control over that.

And of course DENT-OIP/ADA-1107 can include the new codes rather than private codes for the
same concepts in advance of any DICOM CP being completed, or the codes being included in
the DICOM subset or the GPS, and any SNOMED CT licensee could use them any time.

David

PS. The existing unfinished CP 1571 could be used as a vehicle for this IFF the codes you
want now are within the scope of that CP (entitled "Add Orthodontics and Forensic Odontology
visible light view sets to Structured Display"). The last copy of that I have seen is from
about 7 years ago and doesn't have context groups (value sets) with codes in it (yet).

It sounds though from the comment below:

"using them as Scheduled Protocol Codes which are part of the Scheduled Procedure Step of MWLs and also IODs"

that this may be a new scope of work and thence would require a new DICOM CP.

However, if you plan on sending codes for concepts for "views" as "protocol codes", we may
have a bigger information modelling problem, in that a "view" is not normally used as a
"protocol" per se. E.g., we would normally send pre-coordinated procedure codes in such a
DICOM attribute in a worklist. They might better be sent another way (name-value pairs in
Protocol Context Sequence).

However, I see from the SNOMED CT Browser that SNOMED CT may have modeled your new concepts
as "record artifacts" (pre-coordinated code describing the image itself) rather than as a
"qualifier value" using the pattern that was established for radiographic projections
(views) ... e.g., compare children of:

   http://snomed.info/id/260419006

with

   http://snomed.info/id/260419006

or as procedures if pre-coordinated:

   http://snomed.info/id/241048009

This "Photographic image record (record artifact)" approach seems to have been made up especially
for you guys and it does not seem to be used for any other kind of medical imaging (which is
inconsistent). It would be interesting to see what other specialties that produce medical
photographs (like dermatology or ophthalmology or GI or surgical endoscopy) thought of this.

I see that you have pre-coordinated multiple aspects into one concept (which we do all the
time with "procedures", although not usually to the same level of granularity, e.g.:

   http://snomed.info/id/71651007

So I suppose if you are going to just use single pre-coordinated "record artifacts" codes as
the DICOM MWL "protocol codes" as if they were "procedures" that would probably work, though
that begs the question of why they weren't modeled as "procedures" in the first place.

Note that we are often careless about whether the same code for a "procedure" is used in the
request/order for it, to identify the images from it, or to identify the report about it (or
the bill for it). Or for the steps/protocol/method for a procedure as being distinct from a
parent procedure.

Also, compare with laboratory procedure/methods (that DICOM does not yet use):

   http://snomed.info/id/127789004

that are also modeled as "procedures".

--

Toni Magni, BME

Clinical Instructor

Department of Orthodontics

Case Western Reserve University