Monday, July 29, 2013

Do You Want a Side With That Procedure Code?

Summary: Communicating laterality via procedure codes is challenging, and varies between coding systems and across interfaces.

Long Version.

There are basically two ways to communicate in a structured manner the laterality of a procedure (i.e., left or right knee, versus both knees, versus an unpaired body part like the pelvis).

One can either send one code that is defined to mean both the procedure and the laterality, so called pre-coordination, or send multiple codes (or elements or attributes) with the meanings kept separate.

SNOMED, for example, does not pre-coordinate the laterality with the procedure. For example, it specifies only P5-09024 (241641004) as the generic code for MR of the knee. There is a SNOMED generic qualifier for right, G-A100 (24028007). This is a somewhat arbitrary limitation, since SNOMED does pre-coordinate the concepts of "MR" and "Knee", however.

LOINC, on the other hand, has pre-coordinated codes for left, right and bilateral procedures. For the MR knee example, these are 26257-6, 26258-4 and 26256-8 respectively.

The UK has a National Interim Clinical Imaging Procedure (NICIP) code set, and it also uses pre-coordinated codes, in this case MKNEL, MKNER and MKNEB, respectively. The NICIP code set has the interesting feature of being mapped to SNOMED, which we will return to later.

So if one has a procedure code with laterality pre-coordinated, one is good to go. These codes can be used in the HL7 V2 ordering messages (Universal Service ID), and passed through the DICOM Modality Worklist and into the images and the MPPS unhindered.

Better still would be to have the modality extract the laterality from the supplied procedure code and populate the DICOM Laterality attribute (or Image Laterality, depending on the IOD) so as to facilitate downstream use (hanging protocols, etc.) and reduce the need for operator entry or selection. This would be easier, of course, if the laterality concept were sent separately, but it isn't. The extraction is not often (ever?) done, and population of Laterality, if populated at all, remains operator-dependent. Nothing prevents a clever downstream PACS or VNA extracting this information on ingestion though, and creating a "better" Laterality value and coercing it in the stored object, if none is already present in the images, or raising an alert if there is a conflict with what is present in the images.

Nor is laterality required, or even mentioned, in the Assisted Acquisition Protocol Setting option of IHE Scheduled Workflow (SWF). There is, however, the possibility of sending laterality information in the protocol codes, as opposed to the procedure codes, but this is not usually done either.

On the other hand, if one is using SNOMED for one's procedure codes, there are several practical problems. SNOMED's contemporary solution would be to create values that could be sent in a single attribute by using post-coordinated expressions using their "compositional syntax". For the MR of the right knee example, that might be "241641004 | Magnetic resonance imaging of knee | : 272741003 | laterality | = 24028007 | right".

This is all very well in theory, and the British and the Canadians (well, the Ontarians anyway) are very excited about using SNOMED for procedure codes, but there is the small practical matter of implementing this in HL7 V2 and DICOM. Code length limits are (probably) not an HL7 V2 issue, but they certainly are in DICOM.

Since both modalities and worklist providers can only encode 16 characters in the Code Value (which has an SH Value Representation), we are out of luck trying to encode arbitrary length compositional expressions. Indeed even switching to the SNOMED-CT style numeric Concept IDs (24028007), rather than using the SNOMED-RT style Snomed ID strings (G-A100) that DICOM has traditionally used for Code Value, is a problem. The Concept ID namespace mechanism allows for up to 18 characters, which is too long for DICOM unless there happen to be enough elided leading zeroes, and this is a special problem for national extensions. Bummer.

Unfortunately, the Code Value length limit cannot be changed since it would invalidate the installed base. There have been various discussions about adding alternative attributes or Base64 encoding to stuff in the longer numeric value, but there is no consensus yet.

For the time being, for practical use, either laterality has to be pre-coordinated in the single procedure code, or it has to be conveyed as a separate attribute in the DICOM Modality Worklist.

With respect to the possibility of a separate attribute, a forthcoming white paper from the IHE Radiology Technical Committee, Code Mapping in IHE Radiology Profiles, discusses the flow of codes throughout the system. It mentions the matter of laterality, and what features of IHE Scheduled Workflow can be used if laterality is conveyed separately from the procedure code. In short, there are specific HL7 V2 attributes (OBR-15 in v2.3.1 and OBR-46 in v2.5.1), whose modified use is defined by IHE to convey laterality. And there is an accompanying requirement to append the value to Requested Procedure Description (0032,1060) for humans to read, but that is better than nothing (or depending on a piece of paper or the RIS terminal). But there is no standard way to convey laterality separately and in a structured manner in the DICOM Modality Worklist, which means there is no (automated) way to get it into the images.

Another effort to standardize procedure codes, the RadLex Playbook, also currently defines pre-coordinated codes for left (RPID708) and right (RPID709) MR of the knee. A minor and remediable issue is that it does not currently have a concept for a bilateral procedure, unless one gets more specific and additionally pre-coordinates the use of intravenous contrast. This does highlight that the RadLex PlayBook is a bit patchy at the moment, since it grows over time as new concepts are required when encountered during mapping of local coding schemes. Earlier attempts to include every permutation of the attributes of a procedure resulted in an explosion of largely meaningless concepts and was abandoned, so the current approach is a good one, but these are early days yet.

On the subject of contrast media, one does not usually use intravenous contrast for MR of joints, unless there is a specific reason (infection, tumor, rheumatoid arthritis). On those occasions when it is required, it is desirable to be able to specify it during ordering or protocolling, and it certainly affects mapping to billing codes. There is also the possibility of intra-articular contrast (MR arthrography) to consider.

Each of these concepts needs to be pre-coordinated with the side to come up with one code. It can be difficult to determine, unless separate concepts are defined, whether the more general code (contrast not mentioned) is intended to mean the absence of contrast, or if it is just not specified and is a "parent" concept for more specific child concepts that make it explicit. SNOMED, for example, does indeed have concepts for knee MR with IV contrast, P5-09078 (432719005), and knee MR arthrography, P5-09031 (241654006). These are both children of 241641004, implying that the later is agnostic about contrast. There are no contrast-specific SNOMED concepts that have laterality pre-coordinated, though, as expected.

So, for codes specific to the MR of the right knee, in LOINC, NICIP and RadLex one finds:

26258-4MKNERRPID709contrast unspecified
36510-6noneRPID1610without IV contrast
36228-5MKNERCRPID1611with contrast IV
26201-4noneRPID1606with and without contrast IV
43453-0nonenonedynamic IV contrast
36127-9MJKNRnonewith intra-articular contrast

So LOINC is the only scheme currently that is sufficiently comprehensive in this respect. There is talk of a RadLex-LOINC harmonization effort, which, when underway should address that gap in RadLex. There is also a new LOINC-SNOMED agreement that has recently been announced, which will hopefully result in pre-coordinated LOINC codes being those used "on the wire" (encoded in messages and objects), but with the advantage of the availability of a mapping to their equivalent SNOMED concepts. It will be interesting to see how those who have hitched their wagon to encoding SNOMED on the wire are affected by this new agreement, or whether they switch to using LOINC codes.

By the way, NICIP has an MRI Knee dynamic code too, MKDYS, but it is not side-specific, so there is some patchiness therein as well.

NICIP is also interesting because mapping issues related to laterality are explicitly described in Guidance for the National Interim Clinical Imaging Procedure (NICIP) Mapping Table to OPCS-4. I gather that OPCS-4 is the UK equivalent of a billing code set, but used for operational and resource management purposes. Specifically, the issue of mapping side-specific NICIP codes to SNOMED's non-specific code is addressed, in the context of a body region multiplier that is needed. To use their example, an MR of the left knee would map from MKNEL to SNOMED 241641004, and thence to U13.3 (MR of bone) and Z84.6 (knee joint) but would need to have laterality post-coordinated with the SNOMED code to translate to Y98.1 (radiology of one body area). Whereas an MKNEB would translate to Y98.2 (radiology of two body areas) (and interestingly a different primary code (U21.1 MR), though that may just be an error in their mapping table).

Most folks, in the US at least, don't use standard procedure codes for ordering and instead rely on those codes internally developed for use in their "charge master", which may or may not bear some resemblance to billing codes or something that a vendor has supplied. This may change as more robust and well accepted standard schemes are developed and harmonized, or integration is required with other systems for handling appropriateness of ordering and utilization, and reporting of quality measures.

Regardless, whether one uses standard or local codes, the question of communicating laterality in a structured electronic manner remains a challenging one. It is best addressed by looking at all the systems as an integrated whole, to take advantage of as much automation as possible, without manual re-entry, to improve quality and operational efficiency. Hopefully as many standard attributes and mappings can be leveraged as possible, without local customization.



Fidario said...

Hello: I am a Radiologist in Buenos Aires, Argentina. We are planning to add the RPID code of each CT study to the DICOM header through the RIS after mapping with the Radlex Playbook (the RPID will be attached to the study name within the procedure list in the RIS, but as an extra code). I would be very pleased to know your opinion about which DICOM tag should I use to insert the RPID. Should I use the CodeValue tag?
Thanks for your help,
Dario F., MD

David Clunie said...

Hi Dario

In DICOM, codes encoded as three attributes, a triplet of:

Code Value (0008,0100) (e.g. "RPID246")
Coding Scheme Designator (0008,0102) (e.g., "RADLEX")
Code Meaning (0008,0104) (e.g. "CT Chest")

within a single item of an enclosing code sequence attribute that specifies what the code is for, which in this case would be Procedure Code Sequence (0008,1032).

All three attributes must be sent, since the Code Value is meaningless without the Coding Scheme Designator, and Code Meaning is required for the recipient to understand the meaning of the code if it doesn't recognize it (have the dictionary to look it up in).

Also, the Code Meaning does not have to be in English, e.g., it could be "CT Tórax" rather than "CT Chest".

That would describe the performed procedure. If you also wanted to encode the requested procedure (which might be different from that performed), you would encode that as a similar triplet in Requested Procedure Code Sequence (0032,1064) nested within an item of Request Attributes Sequence (0040,0275). IHE Scheduled Workflow Requires this.


Pablo Pazos said...

Hi David,

I'm an engineer from Uruguay doing some work integrating RIS and PACS using HL7. Trying to understand the HL7-DICOM mappings from IHE-RAD-TF, I can't find a clear difference between Requested Procedure Id and Universal Service ID.

Any pointers are very welcome!

Kind regards,
Pablo Pazos

David Clunie said...

Hi Pablo

These are different things; one is which (instance) and the other is what (type).

I.e., the Requested Procedure ID is an identifier that is specific to the instance of the study for a particular patient (like Study ID or Accession Number), and is different for every requested procedure.

Whereas the Universal Service ID is a code for what is (requested to be) done, i.e., it is a code for the procedure type, and is the same for all patients undergoing the same procedure.

That said, in IHE SWF, for the HL7 messages, the Procedure Code (OBR-44) is emphasized over Universal Service ID (OBR-4), as the source of the code to populate the worklist.

The IHE white paper at "" may help, wrt. the codes, and you should consult the current RAD TF for the other stuff (like the handling of IDs rather than codes).


Jacques Fauquex said...

Since edition 2014c, DICOM added the attribute "long value value" (0008,0119), which may help for post-coordinated SNOMED CT codes. How should we write this kind of codes into DICOM syntax? Should we put the complete SNOMED CT sentence of your example "241641004 | Magnetic resonance imaging of knee | : 272741003 | laterality | = 24028007 | right" into the DICOM atribute (0008,0119)?

David Clunie said...

We talked about the possibility of post-coordinated expressions when we added these long values, but it is not likely to be very interoperable given the unbounded complexity possible. DICOM does not actually forbid them though.

One day there may be a complete enough pre-coordinated set; I have been looking at specific gaps in the mappings between the various schemes. See

David Clunie said...

FYI, to update the matter of handling "longer" codes in DICOM, see the most recent standard at:

and in particular discussion and examples of Long Code Value (0008,0119).

I don't know if anyone has implemented or used this yet though.

This change was add in CP 1031 ("").

David Clunie said...

The LOINC-RadLex harmonization of imaging procedure codes has significantly progressed since I wrote this. See the LOINC/RSNA Radiology Playbook file available at the LOINC Downloads site "" and the most recent version of the RadLex Playbook User's Guide ("").