UK Imaging Informatics Group
Archive through May 25, 2014 PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards > Body part mapping of exam codes >
 Link to this message Herman Oosterwijk  posted on Wednesday, May 21, 2014 - 04:50 pm Edit Post Delete Post Print Post
this is w regard to Chris' comments about using PIR. I would think that PIR is only applicable if you have a RIS-driven system, i.e. all changes are made at the RIS. SWF by itself uses MPPS which is typically used to communicate any PPS to scheduled procedure mapping. In that case, PIR is not needed ad the PACS and RIS are updated based on the MPPS info.
 Link to this message Christopher Lindop  posted on Wednesday, May 21, 2014 - 07:06 pm Edit Post Delete Post Print Post
Regarding PIR - MPPS will only communicate what the modality knows. If the modality does a different procedure than what is scheduled, then the performed procedure code is likely blank, as per SWF. A PACS could also determine what was performed and notify the RIS what was performed. This is not SWF. Most common in practice today is the RIS performing the reconciliation and notifying the PACS as specified in SWF.

Herman - are you proposing a new option to SWF?
 Link to this message Neelam Dugar  posted on Wednesday, May 21, 2014 - 07:46 pm Edit Post Delete Post Print Post
Real world working---
NICIP codes are part of OBR4 Universal ID of HL7 ORM and ORU (this is how ICE Ordercomms communicates)
Ordercomms and RIS communicate with PACS via HL7 messaging in NHS
Status update message from "arrived" to " complete" is communicated by RIS to PACS and Ordercomms this is trigger SC of ORC1
Ordercomms does not have NICIP codes mapped to Body parts.

Simon are u willing to share your NICIP codes mapped to body parts so that we can upload them on PACS, RIS and Ordercomms as all of these have NICIP codes as reference files

HL7 is fairly simple and works well :-)
 Link to this message Christopher Lindop  posted on Wednesday, May 21, 2014 - 08:30 pm Edit Post Delete Post Print Post
OBR-4 Universal Service ID is designed for the Universal Service ID of the Order.

A more appropriate place would be OBR-46 Placer Supplemental Service Information.

Regardless of being standards-compliant or not, I am happy to hear that your RIS does provide the information to the PACS.
 Link to this message Neelam Dugar  posted on Wednesday, May 21, 2014 - 09:41 pm Edit Post Delete Post Print Post
OBR4 is the place where NICIP --NHS National Procedure Codes is put in Ordercomms--used in NHS. we use ICE
ICE send this to our Rogan RIS
RIS sends it to PACS via OBR4
Even IHE suggests this
 Link to this message Christopher Lindop  posted on Wednesday, May 21, 2014 - 09:55 pm Edit Post Delete Post Print Post
Sorry - I thought you were discussing body parts. Of course the ordering procedure code should be placed here. Very IHE compliant!
 Link to this message Joel Lidstrom  posted on Wednesday, May 21, 2014 - 10:30 pm Edit Post Delete Post Print Post
RadMapps is a small American company that correlates radiologic exam lists to any "standard" list. As an example, for the American College of Radiology's Dose Index Registry study we are correlating participants' CT exam descriptions to the RadLex Playbook.

We also create related procedures files for facilities using Fuji Synapse, and to do so our software maps exam descriptions to anatomic foci. Here is a small example of NHS studies, tagged with salient body parts:

CT Upper arm with contrast Rt _________________________ RIGHT HUMERUS
CT Upper leg Both _________________________ FEMUR
CT Upper leg Lt _________________________ LEFT FEMUR
CT Upper leg Rt _________________________ RIGHT FEMUR
CT Upper leg with contrast Both _________________________ FEMUR
CT Upper leg with contrast Lt _________________________ LEFT FEMUR
CT Upper leg with contrast Rt _________________________ RIGHT FEMUR
CT Urinary tract _________________________ BLADDER, URETER, KIDNEY
CT urinary tract with contrast _________________________ BLADDER, URETER, KIDNEY
CT Urogram _________________________ UROGRAPHY, ABDOMEN, PELVIS
CT Venogram _________________________ VENOUS
CT Venogram cerebral _________________________ VENOUS HEAD/NECK, BRAIN
CT Venogram Intracranial _________________________ VENOUS HEAD/NECK, BRAIN
CT venography pulmonary _________________________ VENOUS THORACIC
CT Vertebroplasty cervical _________________________ CERVICAL SPINE
CT Vertebroplasty lumbar _________________________ LUMBAR SPINE
CT Vertebroplasty sacral _________________________ LUMBAR SPINE, PELVIS
CT Vertebroplasty thoracic _________________________ THORACIC SPINE
CT Wrist Both _________________________ WRIST
CT Wrist Lt _________________________ LEFT WRIST
CT Wrist Rt _________________________ RIGHT WRIST
Cardiac Perfusion MRI _________________________ HEART
Cardiac Ventriculogram MRI _________________________ HEART
Thoracic aorta MRA _________________________ CHEST, THORACIC AORTA
Aorta MRA _________________________ ABDOMINAL AORTA / BRANCHES
MRA Coronaries _________________________ HEART
Carotid MRA Both _________________________ CEREBRAL/CAROTID ARTERY

We are currently creating an API that will normalize map exam descriptions, and return RadLex values, SNOMED-CT values, LOINC values, etc., as well as provide "related" body parts for comparison hanging purposes.

Let me know if our body part mapping might be useful to you!


Joel Lidstrom
 Link to this message Simon Hadley  posted on Thursday, May 22, 2014 - 09:26 am Edit Post Delete Post Print Post

Enclosed is GOSH's list of NICIP codes against body parts. Please note that GOSH has decided that each examination will only have 1 body part, therefore in examinations where there are more than one body part (e.g. CT Head/Neck/Chest/Pelvis) this is represented as "Whole Body". It would be interesting to see what others views on this are. We kept the body regions simple to avoid confusion or over complicating things but we are happy to look at changing if needed.

I appreciate that we need to try and make this as workable for users as possible, however, in our RIS we are only able to stipulate 1 body part but with PACS/XDS we are able to map more than one.

Note that the mappings we have in RIS, are the same in PACS/XDS at this stage and that this is only a list of codes that are currently in use at GOSH and not ALL current ACTIVE NICIP codes.

Another thought to add in at this stage is around deprecation/changing of codes at every new release and how this is dealt with in RIS/PACS/XDS in regards to historical data etc. Thoughts?

NICIP_Code_Body_Region_RIS_Mapping_GOSH_20140522_v1.2.xlsx (109.7 k)
 Link to this message David Clunie  posted on Thursday, May 22, 2014 - 10:45 am Edit Post Delete Post Print Post
Neelam wrote "there is no national list of NICIP codes mapped to 1 or more body parts".

If you look at the NICIP tables that included the SNOMED Concept ID (SCT_ID), then that is actually defined in the SNOMED relationship tables with one of the "procedure site" (363704007, 405813007, 405814001) relationships with an anatomical site.

E.g., for CABPE, "CT Abdomen and pelvis", which maps to SCT_ID 419394006, if you look at the "procedure site - direct" relationship in SNOMED you will find both:

419394006 405813007 113345001
419394006 405813007 12921003

and you will find that 113345001 is "abdomen" and 12921003 is "pelvis".

It requires some understanding of both the NICIP and the SNOMED tables to derive this, but the information is there.

Simon wrote "in examinations where there are more than one body part … this is represented as 'Whole Body'"; I don't think that the use of "whole body" is necessary (nor sufficient). We went to a lot of trouble in DICOM to add most combinations of body parts to SNOMED explicitly for this purpose. For example, the aforementioned "abdomen and pelvis" can be combined into one code, 416949008 (R-FAB57) (and "ABDOMENPELVIS" for Body Part Examined). There are one or two weird combinations missing, like head+abdomen+pelvis, which I was surprised to find in the NICIP codes (as opposed to ordering the head separately). I agree that it is important to have only "one body part" though, because we have places for only one string and one code (i.e., combinations need to be pre-coordinated).

One can use these tables (and a knowledge of the combination body parts in SNOMED as used in DICOM) to produce another table that maps each NICIP code to a (ideally, a single) SNOMED (RT style) code as DICOM (and XDS-I eventCodeList and/or a Code String value for Body Part Examined (when there is one in DICOM), i.e., like Simon's table but automatically generated (and hence not requiring manual maintenance as the NICIP and SNOMED and DICOM tables are updated/extended/corrected).

Note that these tables are as precise in terms of anatomical localization as the procedure that is defined, so, for example, a CFLMO "CT floor of mouth" would map to anatomy of "Floor of mouth", and this may be too specific for some applications (and would not have a DICOM Code String for Body Part Examined). One might want this "lumped" as "HEAD" for some purposes.

The appropriate "lumping" of these into larger groups can also be performed mechanically against whatever criteria are required, by using the SNOMED anatomical hierarchal relationships to find the nearest parent concept that is wanted, for example, in DICOM PS3.16 Annex L, with or without a standard Body Part Examined string.

I see that in Simon's GOSH table he has already performed a lot of that "lumping".


PS. Simon, I notice in your GOSH table that you are not using the standard DICOM (PS3.16 Annex L) string values for some of the body parts, e.g. "WBODY" should be "WHOLEBODY", extremities are described a bit differently, we don't lump all cardiovascular sites into "CARDIO" but rather use "HEART" for cardiac, etc. We should probably iterate on this a little.
 Link to this message Neelam Dugar  posted on Saturday, May 24, 2014 - 11:15 am Edit Post Delete Post Print Post
I have not been able to open Simon's spreadsheet. However, I will email Simon and see if he can send it to me. David, can open it, so it must be my lack of IT skills :-)

"If you look at the NICIP tables that included the SNOMED Concept ID (SCT_ID), then that is actually defined in the SNOMED relationship tables with one of the "procedure site" (363704007, 405813007, 405814001) relationships with an anatomical site.

E.g., for CABPE, "CT Abdomen and pelvis", which maps to SCT_ID 419394006, if you look at the "procedure site - direct" relationship in SNOMED you will find both:

419394006 405813007 113345001
419394006 405813007 12921003

and you will find that 113345001 is "abdomen" and 12921003 is "pelvis". "

Let me turn it around and see the clinical utility of this data. I can see 2 clinical utilities:
1. RELEVANT PRIOR Display on PACS: Body part mapping on PACSis predominantly useful in calling up the relevant prior. If radiologist is reporting a CT of Chest abdomen and Pelvis (Whole Body--body part) and the previous CT was of the chest (Thorax body part) is important. However, CT Chest would not come up as the relevant body part. However, if instead of single body part, we could have multiple body parts for combined codes--like CT, PET-CT, MRI etc it would be more useful.
E.g. CT Chest,Abdomen,Pelvis was mapped to 3 body parts--Thorax, Abdomen and Pelvis.
2. Filtering and SORTing of Imaging History of the particular patient. Again on PACS, one would be able to sort and filter studies in imaging history of the patient
a. Date
b. Modality
c. Body parts
d. NICIP codes and description (this provides the granularity of exact organ--heart, mastoid, knee etc and also laterality--right or left.

What I would suggest is use simple body part list
1. Head
2. Neck
3. Thorax (include heart, lungs, ribs etc)
4. Abdomen
5. Pelvis
6. Spine
7. Upper limb
7. Lower limb
However the ability to include multiple body parts where appropriate --CT, PET-CT are the common ones.

However, the question is
1. Does DICOM support inclusion of multiple body parts? David, can you answer this?
2. Does HL7 OBR 46 support inclusion of multiple body parts? Chris can you answer this.

The purpose of this discussion is that if we are all going to put a lot of effort in tidying up the body-part data information, are patients and doctors (working for the patients) really going to benefit from this exercise.
 Link to this message Simon Hadley  posted on Saturday, May 24, 2014 - 11:34 am Edit Post Delete Post Print Post

I can see the logic in allocating more than one body part to an examination if possible and certainly, our PACS can achieve that for the purposes of DDP's however I am not sure that many RIS products can do this and it will be interesting to see what Dave comes up with as far as the dicom side is concerned

How would this same logic apply to more generic codes such as US guided biopsy or CT forensic which could be any part of the body and may still need to be included in the radiologists relevant priors for reporting?

Would there be a place for a more generic term such as "whole body" or would there be an expectation of allocating every body part in these instances (of course if possible).

 Link to this message Neelam Dugar  posted on Saturday, May 24, 2014 - 01:42 pm Edit Post Delete Post Print Post
Upper Limb
Lower Limb

Hi Simon,
I looked at my original post on this and subsequent comments and I think the above seems a more comprehensive list.

Where we need body- parts to be available in PACS and XDS/VNA so RIS and HL7 is less important.

What do you think of the above small list of body parts which we could get mapped to SNOMED?
 Link to this message Neelam Dugar  posted on Saturday, May 24, 2014 - 01:48 pm Edit Post Delete Post Print Post
Hi Simon,
Where body- part cannot be allocated I would prefer to use Misc.
Modalities have "other" when a particular modality cannot be used.
However, let us see what David thinks about using Misc and our also smaller list of body parts.
 Link to this message Neelam Dugar  posted on Saturday, May 24, 2014 - 01:54 pm Edit Post Delete Post Print Post
I was also looking at Joel's list and mapping.
Thanks Joel.

I think multiple body parts would indeed be useful
Cerebral angiogram--brain and vessels
CT colonoscopy-abdo, pelvis, bowel
This kind of mapping would be useful clinically.
 Link to this message David Clunie  posted on Saturday, May 24, 2014 - 03:37 pm Edit Post Delete Post Print Post
Hi Neelam

DICOM requires that there be a single code (in Anatomic Region Sequence, or a single string in its counterpart in older IODs, Body Part Examined).

For this reason, we produced codes that represent combinations of body parts, and these have made their way into SNOMED (e.g., in the example discussed, there is (R-FAB57,SRT,"Abdomen and pelvis") = "ABDOMENPELVIS"); a more complex one is (R-FAB54,SRT,"Neck, Chest, Abdomen and Pelvis") = "NECKCHESTABDPELV").

Since procedure codes (such as those in NICIP and SNOMED) and anatomic codes (like those used in DICOM) "pre-coordinate" combinations of anatomic regions into single codes, it behooves the recipient to perform more complex matching for various use cases.

So, for the use case of relevant prior decisions, the recipient may have a simple predefined "list" of all those pre-coordinated (procedure or anatomy) codes that are potentially relevant, or it may have a (much) more sophisticated "understanding" of the "ontology" (relationships) behind those codes.

E.g., it may be configured to know that whenever it has a (T-D4000,SRT,"Abdomen"), that (R-FAB57,SRT,"Abdomen and pelvis"), (R-FAB55,SRT,"Chest and abdomen"), (R-FAB56,SRT,"Chest, abdomen and pelvis") are also "relevant". Or it may explore the relationships of the various single and combined codes, e.g., to detect that a (T-65000,SRT,"Pancreas") is relevant to a (T-D4000,SRT,"Abdomen"), or vice versa, without having to permute this in advance, or encode anything ordered as a "CT Pancreas" as having an anatomic region or body part of "Abdomen" rather than "Pancreas".

As I mentioned previously, this "knowledge" is available in the SNOMED relationships between procedure concepts and their procedure sites, and between the anatomical concepts that are those sites . As a recent example of the "ontological" approach, Helen Chen's SIIM abstract at " -enhanced-search-anatomic-location" might be of interest, though her work focuses not on procedure codes per se but other DICOM attributes and includes text matching. There has been a lot of work over the years on the "relevant priors" problem, and I can point you to further references if you like.

In my previous response I also forgot to mention the NICIP mapping to OPCS-4, which contains the Z codes (and in some cases O codes) for many (though not all) procedures, which are anatomically specific and perhaps more tractable than the SNOMED tables.

Archived posts in this thread also mention the importance of preserving fine grained anatomical detail (e.g., for sub-specialty applications like dental radiology), and one might consider the comments in the other thread related to XDS metadata for "other" specialties too. And as Simon points out, there is more to a procedure code than just anatomy that may be relevant (and indeed SNOMED, as well as other procedure coding schemes like LOINC and RadLex, recognize that there are many "attributes" involved in a procedure definition, and in practice "pre-coordinated" into each single code).

The choice of whether to use anatomic information or procedure code information (or both) for a particular use case depends a lot on the deployment environment, and in particular whether or not various fields in various objects (or their out-of-band metadata) from various devices are reliably populated with standard values, both routinely and in the face of exceptions (like group cases and not doing what was requested).

To the extent that in the UK NICIP codes are used internally (are they?) and can be reliably conveyed into the DICOM image "headers", then you may have the luxury of more consistency than in other regions. But you still may find it a struggle to get all (any?) modalities to populate Anatomic Region Sequence or Body Part Examined), or even to propagate the procedure codes properly, though this can theoretically be "filled in" later (e.g., during PACS ingestion, based on the (performed) procedure code, perhaps with information from the RIS or its equivalent). Have you evaluated which of your modalities map what attributes in this respect, and if so, to what extent they are configurable?

I.e., to use your expression, who (which device) is going to actually do the "tidying up"?


PS. For detail on which HL7 and DICOM fields handle such things, see our recent IHE Code Mapping White Paper " ev2.0_2014-03-07.pdf". Though it uses RadLex examples, these could easily be swapped out to use NICIP and/or SNOMED codes.

PPS. By the way, OBR-46 is a bit of a "wastebasket", and yes it theoretically can contain multiple values, but is specialized in IHE SWF for laterality (ONLY). In HL7 it is defined as "supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID". It is called out in HL7 as having some relevance to imaging orders, specifically "can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions)." In IHE SWF in the 2.5.1 option (SWF.b), it is described as being used for laterality if necessary, i.e. "This element shall be used for the L/R (laterality) indicator, if applicable … This element shall only be used if the coding scheme that is employed does not contain laterality within the coding scheme itself. If laterality is inherent in the coding scheme, this element shall not be sent".

In other words, it would violate SWF to send other stuff than laterality here (e.g., to tack on anatomy codes), unless we were to do a CP to SWF(.b) that generalized OBR-46 (and probably OBR-47 too, on the filler rather than placer end).

The bottom line is that HL7 (and SWF) have up until now envisaged that anatomy is implicit in the order code, and do not anticipate sending it separately. If it is needed "downstream" it can be extracted from the order code.

PPPS. With regard to short lists, I have expressed my opinion about these separately at "", and I have not really changed my opinion since then (that "lumping" is in the eye of the beholder, and different specialties require different categories, so it should be done on the receiving, not sending end, and ""miscellaneous" categories are undesirable), and we have another thread in this forum about the subject at "".
 Link to this message Andrew Downie  posted on Saturday, May 24, 2014 - 07:18 pm Edit Post Delete Post Print Post
What have I started here?!

David's posting sums it up quite well. As it happens, during this week's debate, our PACS vendor has coincidentally asked to trIal a body part look up system using a copy of the national code table held in PACS. It can replace body part info from the modalities with that from the look up table, perhaps using the codes David suggests.

The DPs can do part searches within body part codes, so could find exams containing "abdomen" within a code of "chest, abdomen, pelvis". This may be the answer to my initial problem at least.
 Link to this message Joel Lidstrom  posted on Saturday, May 24, 2014 - 08:17 pm Edit Post Delete Post Print Post
It is interesting what David said, "…it is important to have only "one body part" though, because we have places for only one string and one code...", and hence “We went to a lot of trouble in DICOM to add most combinations of body parts to SNOMED explicitly for this purpose.” But beyond obvious C/A/P or H/N/C/A/P, etc., studies, what are the combinations? There are simply too many, subject to too many opinions about what they should be. One of RadMapps' solutions is to programmatically identify unique body part combinations for all combinations as evident in procedure codes in use, and tag procedure codes with this identifier.

David is prescient when he says "…combinations need to be pre-coordinated". It is not difficult to create a single, unique identifier for every body part combination that exists, particularly within a rigorously defined set of procedure codes such as the NHS is using. Not only would there be a useful and absolute identifier for each study performed, but it would exactly establish each exam code's relationship to other exam codes for the purposes of comparison hanging. And if it's a question of "lumpers" vs. "splitters", I propose that we can "lump and split" according to need and preference. I wrote some software a few years ago that creates two identifying integers that define an exam code in this way, based entirely on the exam description. Those integers represent:

IsA = code-identifier for the actual anatomic mapping at a “standard” granularity (“finger”, yes; “metacarpophalangeal”, no; “upper extremity”, no).
HasRelated (code-identifier for the combination composed of the IsA mapping and all congruent body part mappings).

For example, our software would map a CT LEFT SHOULDER to Left Shoulder. For that exact combination of body parts (two IsA IDs representing LEFT and SHOULDER), I’ll arbitrarily assign CombinationID of 27.

Our software knows, however, that any CT LEFT SHOULDER should bring up comparisons not only to LEFT and BILATERAL/NON-SIDED SHOULDER, but AC JOINT, CLAVICLE, GLENOID CAVITY, HUMERUS, and any non-specific LEFT AND BILAT/NS EXTREMITY and LOWER EXTREMITY. To that exact combination of body parts I’ll arbitrarily assign a CombinationID of 178.

Now CT LEFT SHOULDER can be defined simply with a 27|178. If you or your PACS has the key, you’ll know that this is a LEFT SHOULDER procedure, and at the same time your PACS can immediately find all appropriate priors (or pre-fetch exams) by looking at the second number. (The second number represents multiple individual IsA identifiers, and hence locates the priors.)
 Link to this message Neelam Dugar  posted on Sunday, May 25, 2014 - 03:53 pm Edit Post Delete Post Print Post
Thanks David for confirming that only a single body part is allowed in DICOM tag. This is a shame indeed.

Sorting and Filtering Imaging history data on PACS for a single patient should include:
a. Date
b. Modality
c. Body parts
d. NICIP codes and description
e. Exam status
f. Referring Specialty
This is important from a clinical perspective. No single element is perfect.

Thanks Simon for sharing your body part mapping to NICIP codes. This is very helpful. I will simply use the GOSH version for our local implementation of VNA and XDS (as there is no national set available). This is a good start but could be refined as stated by David as well. I do hope whoever is looking after NICIP codes in HSCIC, can do some work towards a national body part mapping.

You mapping will allow us to populate PACS/VNA with the appropriate Body part mapping which will then go to events code metadata from the XDS-I source within the VNA.

Andrew I would suggest using the GOSH version of Body part mapping with a thanks to Simon.
 Link to this message David Clunie  posted on Sunday, May 25, 2014 - 04:10 pm Edit Post Delete Post Print Post
Hi Joel

Is there any particular reason you made up your own codes for this sort of mapping, when SNOMED, LOINC Parts, FMA, UMLS etc. all have codes and anatomical hierarchical and compositional relationships to re-use?

For example, in UMLS, "Shoulder" is C0037004, and is mapped to LOINC Part LP7584-8, SNOMED 16982005 (T-D2220), FMA 25202, etc. And one can use the relationships in UMLS, SNOMED, LOINC Parts and/or FMA to detect children and parents and left and right and bilateral variants. Not to mention that the anatomical concepts are already used as the target sites for the procedure codes (in SNOMED and LOINC, the former already being mapped to NICIP codes).

Using one of your examples, one can follow "glenoid" to "shoulder" in SNOMED as follows (where 116680003 means "is a"):

46385009 0 Glenoid structure (body structure) XaFnE T-1228A 1
85537004 0 Glenohumeral joint structure (body structure) Xa1Q7 T-15411 1
31398001 0 Joint structure of shoulder region (body structure) XUBZP T-15410 1
16982005 0 Shoulder region structure (body structure) Xa9Yc T-D2220 1

via the relations:

223579029 46385009 116680003 85537004 0 0 0
4779246026 85537004 116680003 31398001 0 0 0
199074028 31398001 116680003 16982005 0 0 0

Not to suggest that SNOMED is perfect, or that one does not under some circumstances have to augment its concepts or relationships for specific purposes, but I am not sure it is necessary to start from first principles without reusing the vast amount of work that has already been done.

In my own work, for example, I always try and use the UMLS CUI as the "primary key" for a concept, unless there is a very good reason not too (such as UMLS has "incorrectly" merged two distinct concepts, or UMLS has not merged two identical concepts (common with LOINC and SNOMED procedures, which are not yet mapped), or the concept does not yet exist in UMLS.

I have also found it useful, rather than to reproduce the relationships in the various coding schemes by hand, to automate the extraction of them, with appropriate "editing" rules to overcome specific inadequacies (e.g., to reject "incorrect" "is a" relationships, or to add missing ones); my hope is that as the source terminologies are maintained (corrected/extended) my mapping of them can remain automated. Likewise, where the source terminologies are missing sufficient "combination" relationships, I just add rules to detect those (and hopefully if I feedback my findings to the maintainers of those source terminologies, they will be improved). And as noted, we can contribute new combination anatomic region concepts to these systems as necessary (though I have found that the notion of "combinations" is not as mature/rigorous in these schemes as that of parent/child containment, and I have done many combinations like chest/abdomen/pelvis or arch/carotid etc., by hand).

Certainly there are also some "relevant" decisions that are not strictly anatomically hierarchical that need to be used to augment existing relationships (such as determining that the "clavicle" may be relevant to the "shoulder" since it is "connected to it", perhaps).

Chen describes a threshold "distance" score based on the number of relationship hops required as a generalized means of determining "relevance", which I am not sure would hold up in practice since it is affected by the granularity of encoding for a particular region.


PS. You may find this article on "Comparing the Representation of Anatomy in the FMA and SNOMED CT" at "" helpful, though their choice of mapping to "entire" rather than "structure of" is not a great one in my opinion, and conflicts with the pattern that we use in DICOM (and which UMLS seems to use too).

PPS. See also this discussion of areas and containment and its references: ""
 Link to this message David Clunie  posted on Sunday, May 25, 2014 - 08:55 pm Edit Post Delete Post Print Post
By the way Neelam, to be strictly accurate, the DICOM Body Part Examined and Anatomic Region Sequence attributes permit only one value, BUT they are encoded at the Series/Instance/Frame level, depending on the IOD, and NOT the Study level.

So, there may indeed be, for example, multiple series, images or even frames within an image that have different anatomy defined ... this is more common in projection x-ray (CR/DX), where for a skeletal survey one might have a chest in one series or image, and a pelvis or a skull or a spine in another, than in cross-sectional modalities (CT/MR, etc.) where it is not always easy to define the transition from, say, the chest to the abdomen (though can arbitrarily deem one series to be CHEST and another ABDOMEN if the protocol on the modality works that way); you will encounter both patterns in the real world (or often nothing at all).

At a "study" level, there is no attribute at all, so one has to perform the query at the series (or lower level). There is no "Anatomic Regions in Study" attribute analogous to Modalities in Study or SOP Classes in study.

So if one were to "roll up" all the series/image/frame values into one metadata attribute, one would need to consider this factor; as opposed to figuring it out from the Procedure Code Sequence (which is at the study level, but, by the way, can have multiple values; e.g., to satisfy the IHE "append" case).

"Life wasn't meant to be easy," as a former Australian Prime Minister used to say.