I would include Breast in your mapping; we use it a great deal.
posted on Wednesday, January 30, 2013 - 09:17 pm
Thanks. Chris Lindop from IHE suggested "Whole Body"---However, I thought "Body" would be better as we could include multiple body areas on CT, alongwith PET-CT/PET-MR. Body parts is predominantly useful with relevant prior so getting PET-CT as a relevant prior of Body CT would be quite useful I think..... Happy for any different views.
Thanks Richard. Breast, Bowel--esp for fluroscopy are good additions.
posted on Thursday, January 31, 2013 - 12:06 am
There is a standard list in DICOM (see the relevant Annex of PS 3.16).
Neelam, our language processing engine can map proc codes to body parts for related priors, normalize exam descriptions to standard exam terminology, and correlate any radiologic list of procedures to any other list. Send me your database of procedures or send me a sample (Proc Code, Description, Modality); I'll show you what we can do!
Having done this recently I've found that being a bit more specific with extremities works better for us, i.e. specifying hand, foot etc. Also, maybe using dental/mandible/jaw for OPG's rather than head (or setting up priors based on modality as well as body part) so OPG's don't display as prior with a CT head!
Neelam, I also agree with Karen, if you have time to get that granular up front, it will save you time in the long run with considerable functionality and patient care benefits. It is also important to include laterality,there are numerous ways to do this depending on the functionality of the application with which you are configuring. Good luck!
Granularity is indeed important for display protocols--you'll also want to differentiate angio procedures from bony procedures, and ensure that immediately adjacent body parts will compare (here I'm referring to bony plain films where you may want an ankle to compare to a tib/fib, or a tib/fib to a knee, but never an ankle to a knee). Hierarchical relationships are important, too, so that bilateral studies compare to lefts and rights (and vice versa) without rights showing with lefts. Similarly you should take care that an entire spine compares to a C, T, or L Spine and vice versa but never a C-Spine to a T or L, etc... To map procedure codes well is highly complex, but improves efficiency remarkably. Also, what you can achieve depends on your PACS.
With respect to Ivan Brown's comment about limited flexibility for body part mapping (vis a vis your fabulous national standard), how your PACS hangs related priors is independent of the procedure code list itself. For most PACS you must tag procedures with body region, laterality, and sometimes functionality. (Fuji PACS 3.x requires the creation of relationships among the procedures themselves.) It pays huge dividends to map procedures carefully and intelligently, but I would think that this would be done on a national level. Create the taggings for the entirety of your procedure code list, and voila!, everyone can load the mappings into their PACS.
posted on Thursday, January 31, 2013 - 09:20 pm
The granularity--laterality, hip, knee etc already exists with national exam codes.
So how does body part mapping help clinical users. 1. Plain xray --relevant prior rules better with exam codes 2.CT/US--relevent prior better with body part mapping .... This is what I was looking at.
Revisiting an old thread. When our PACS went in, I never fully understood the use of body part information. Now we are refreshing the PACS, it seemed like a good idea to try again.
I'm unclear what the correct "flow" of body part information should be. Our HSS RIS has body part info in the exam table, but HSS say they can't send this to PACS as HL7 doesn't cover it.
The modalities are a mess, some sending it, some not, some sending it in the series description field, and no consistency in what terms they use. In concequence the DPs simply can't be made to work as we wish.
The thought of getting vendors to reprogamme every modality in the region (hundreds) to a single standard is just incomprehensible. Is there a better way? Surely it should come from a single exam code table (eg national codes) somehow?
With our recent PACS/RIS implementation, we had the opportunity for all examination codes have to be entered into the PACS system with a specific body part code to be able to utilise DDP's.
In addition to this, extension into the realms of XDS and VNA's will require Body parts to be present to allow filtering. We have utilised a simple set of body parts that we utilise within the trust that are consistent with the RIS/PACS and VNA. In the VNA, they are mapped against the relevant SNOMED CT body part codes which is what we will use going forward.
You should be able to add a body part on RIS and then replicate the same on PACS. In both cases you should be able to get your PACS/RIS vendor to script this, however, it may be chargeable.
I agree that national codes should potentially indicate body part codes, however with most systems only being able to store a single body part, a lot of ones where multiple body parts are set up become "Whole Body" for ease of convenience. (E.g. MRI Post Mortem, XR Skeletal Survey, CT Neck/Chest/Abdo/Pelvis with Contrast)
I have enclosed the codes that we use, it would be interesting to hear about what other users think moving forward?
OBR-44 Procedure Code and Procedure Description should be sufficient to prescribe the body part examined to the PACS. PACS can do the mapping from this field. If desired, OBR-46, Placer Supplemental Service Information could be used. Though desirable that modalities provide this information in the DICOM IOD, it is not practical to expect it.
posted on Wednesday, May 21, 2014 - 04:06 pm
In general, the codes can (and should!) be populated from the NICIP codes - if they are available, then everything else should flow from that, including:
1) RIS should be able (easily!) to populate body part in the MWL response (if of course the modality requests it!).
2) It would be nice if modalities put body part into the image (it is actually mandatory for some newer IODs), but Chris is right that this is unlikely to get 100% coverage, so don't depend on it.
3) It is possible that a PACS could add the body part information based on the NICIP code that it "knows" about from the RIS. This is not the most reliable way of doing things, as scheduled != performed, but it may be better than nothing.
4) For other uses (e.g. XDS-I publication), deriving the body part(s!) directly from NICIP code would almost certainly be the way to go.
Andrew, Thanks for raising this issue. We are looking at the body part mapping issue for VNA.
Our XDS- I sources uses body part as 1 of the event codes. Perceptive/Acuo takes body part information from DICOM header information This DICOM header information comes from modalities. There is no national list of NICIP codes mapped to 1 or more body parts. The result of the behaviour of XDS-I we will have a lot dirty data from DICOM headers populating our VNA XDS metadata. This is setting off alarm bells for me.
Anyone willing to share their NICIP codes mapped to body parts please? I understand you can map 1 exam to multiple body parts for example CT neck and chest with contrast would be mapped to 2 body parts, cT neck chest and abdomen -3 body parts and neck chest abdomen and pelvis to 4 body parts.
Clinically I don't find body part mapping very useful in PACS for clinical work. NICIP codes provide the granularity of Modality Body part(s) Laterality However, XDS-I sources insist on populating it into XDS metadata eventCode