UK Imaging Informatics Group
Philips RF DMWL problem PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
 Link to this message Andrew Downie  posted on Tuesday, November 14, 2006 - 08:31 am Edit Post Delete Post Print Post
This thread started in the CRIS Users' Group, but as it is unsolved, and may have wider relevance, I'm posting it again here.

Our HSS CRIS3 RIS provides DMWL to modalities, including a Philips Diagnost RF table, and Fuji CR. We send all RF studies to both, to allow overcouch CR films, etc. However when a patient is selected on the RF, they disappear from the CR list. HSS say this is because Philips sends them a study complete message when the patient is selected, Philips say there is nothing they can change.

It all worked fine on our previous eFilm PACS, when we used the eFilm broker, and when studies disappeared when post processed on RIS. We now have to enter the CR details manually, with the risk of errors, etc.

Had anyone else had a similar problem, do they have a workaround, and how should this be handled in the ideal DICOM/IHE world?
 Link to this message Dave Harvey  posted on Friday, November 17, 2006 - 01:30 am Edit Post Delete Post Print Post

I presume that the "study complete message" you refer to is DICOM "Modality Performed Procedure Step" (MPPS), in which case I am actually delighted to hear that HSS are not only receiving it, but doing something (potentially) useful with it!

In fact, there are normally 2 messages used in MPPS, an initial "IN PROGRESS" message at the start of a procedure step (significance of this obscure term will become clearer below), and a "COMPLETE" message at the end. Clearly it is reasonable to remove a step from MWL at one or other of these two stages, but neither DICOM nor IHE say which it should be, so strictly speaking, HSS cannot be faulted if they choose to do so in response to the "IN PROGRESS" rather than waiting for "COMPLETE" and if this is what they are doing, then this explains your predicament. In effect, you have gained automated "sign-off" (which is what MPPS is supposed to be) but lost (at least for your second system) the automated demographics and you are right that this is important. So what is the solution?

Well, the important thing to remember is that the DICOM/IHE model of radiological practice allows multiple "steps" in one study, and these do not even need to be the same modality, let alone the same piece of equipment. As the study UID is provided via MWL, then this allows multi-modality studies as the same StudyUID can be passed to multiple pieces of equipment, each of which generates their own series of images and corresponding MPPS messages. This then is the answer for where you wish to use >1 piece of imaging equipment per study - the HSS RIS should be asked (as part of the standard protocol for that type of examination) to schedule TWO procedure STEPS, one for each imaging system (which should therefore no longer need to share a list!) This is a basic RIS scheduling requirement in IHE and CRIS claims to be IHE conformant, so it SHOULD be possible, but I do not know CRIS well enough to tell you whether it IS possible in practice - I would certainly be interested to hear the outcome.

If the proper two step solution is NOT viable, then perhaps they could be persuaded to delay removal from the MWL list until the "COMPLETE" message, rather than as soon as they get "IN PROGRESS".
 Link to this message Andrew Downie  posted on Friday, November 17, 2006 - 09:59 pm Edit Post Delete Post Print Post
Thanks Dave, I knew I could count on you for a lucent explanation. I'll let the group know if I make any progress. If HSS can't manage your suggestions, I might investigate turning MPPS off on the Philips unit for the time being. Such is progress.
 Link to this message Chris Bull  posted on Tuesday, November 21, 2006 - 09:02 am Edit Post Delete Post Print Post
Dear Andrew
The use of the 'MPPS' needs to be looked at as a whole profile as not all PACS support the 'Step' procedures generated in the DICOM profile. We were looking at this for CR (the Agfa CRs do) where a single study may have different 'Steps', this then needs to be sent to the archive where 'it' knows how to handle this data and then on to the viewer which also needs to know and support the MPPS. This is also true where a patient is moved in an MR and a further sequence is made, this should be a MPPS but the MR's we were working with did not support it. Many host devices do not. The easiest way was to have a second RIS entry and link the studies on the RIS and then the reports.
 Link to this message Dave Harvey  posted on Tuesday, November 21, 2006 - 09:21 am Edit Post Delete Post Print Post

I agree that RIS may have varying support for "steps", but there is no need to worry about the PACS.....that has no need ever to know about the "scheduled steps". Most should be fine as long as the StudyUID is correct (i.e. no interest in the steps at all), and if it does use any step information at all, then it is only interested in "performed" steps, irrespective of what was scheduled. I would be VERY wary of double scheduling, as this would (on most RIS) result in 2 STUDIES, with different study UIDs, and therefore would appear to subsequent users as 2 entries :-(
 Link to this message Chris Bull  posted on Tuesday, November 21, 2006 - 02:12 pm Edit Post Delete Post Print Post
Hi Dave
This caused a considerable problem when recalling the patient study on viewers if the data is not recorded correctly within the archive i.e. study descriptions and then the steps. In the case of a CR the study could consist of a 'chest', 'spine' etc. This needs to be recorded as a study consisting of the various steps and steps in the DICOM worklist and then 'picked' by the person performing the procedure. If this is not followed, the modality provides different accession numbers for each different body parts and then it is recorded incorrectly through the system. When a search is performed with the viewer it will show as different accession numbers and a search using the study UID will only find the first body part. The common workaround is to accept the first body part with the others behind it and rely on the RIS to show the complete studies.
As I also said that most hosts do not accept the DICOM MPPS this caused considerable problems when a patient is moved and resequenced the only way was to re-enter into the RIS and send another MWL to the host.
 Link to this message Ian Judd  posted on Wednesday, November 22, 2006 - 10:04 am Edit Post Delete Post Print Post
Hi Guys
We are receiving the"studycomponentmanagement" message from the RF modality, not an MPPS. CRIS is currently processing this as the study is complete and removing the entry from the worklist. this makes the barium enema disappear from the worklist on the RF modality and CR reader. The way to fix this is to stop the RF modality from sending this component management message. this will mean that CRIS will keep then entry on the worklist for both modalities until the radiographer uses the post exam module to complete the procedure. The other way around this is for us to modify our worklist server to have a switch in it to ignore this management message. Does this make sense to you all?

 Link to this message Dave Harvey  posted on Wednesday, November 22, 2006 - 11:13 am Edit Post Delete Post Print Post

Do you mean the old "Detachment Study Management" objects - they have been obsolete for years, and I've never seen one "for real" (and use of MPPS instead is mandated by IHE) old is that RF unit?

I'd be interested to see a log of that message if you have one Ian (if only out of historical interest!), but I suspect that the same issues exist for this and MPPS, namely that there are really 2 separate steps in the examination on different equipment.....does CRIS not properly support the concept of a multi-step procedure as per the attached IHE diagram?

IHE Request Diagram
Add Your Message Here
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Options: Automatically activate URLs in message