wlmscpfs question

All other questions regarding DCMTK

Moderator: Moderator Team

Message
Author
amdescombes
Posts: 2
Joined: Tue, 2005-09-20, 12:45
Location: France

wlmscpfs question

#1 Post by amdescombes » Tue, 2005-09-20, 15:13

Hi,

I am using wlmscpfs 3.5.3 as a DICOM worklist SCP and I would like to know what I need to do in order to change the status of the .wl files to DONE when the study has been performed?
I thank you in advance for you answers.

Andre M. Descombes

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#2 Post by Thomas Wilkens » Wed, 2005-09-21, 07:53

It is not quite clear what you are asking for. Two interpretations are possible:

1. You want to know how to determine when a study has been performed/completed at a certain modality.
2. You want to know how to tell wlmscpfs to not use a .wl file any more, because a study has been performed/completed at a certain modality.

The answer to the second question is easy: simple delete the corresponding .wl file or rename it to .done or whatever other extension you can imagine. wlmscpfs will only read information from .wl files.

The answer to the first question is also easy, but unfortunately not easy to implement for you: you need to use the DICOM MPPS service. MPPS stands for Modality Performed Procedure Step. See the DICOM standard part 4 section F.7 for what this service is about.

Additionally for your information, see FAQ #39.

amdescombes
Posts: 2
Joined: Tue, 2005-09-20, 12:45
Location: France

wlmscpfs question

#3 Post by amdescombes » Wed, 2005-09-21, 08:23

Hi Thomas,

thank you for your answer. Is the MPPS SCP part of OFFIS available for licensing?
What I would like to do is for a modality to tell my system when it has performed a study so I can update the DB. MPPS seems to be the way to do it.

Thanks,

Andre

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#4 Post by Thomas Wilkens » Wed, 2005-09-21, 09:18

MPPS is indeed the way how to accomplish this task. Concerning the licensing question: please send an email to dicom /at/ offis /dot/ de in case you want to license the tool.

To tell you some details about the application: the application is called ppsscpfs (MPPS-SCP based on the file system as a container for received MPPS objects). It will simply receive MPPS objects over the network and store them to a certain folder on your hard drive. In detail, each N-Create RQ message will lead to exactly one file on the hard drive, each N-Set RQ message will update the corresponding file which was previously created (provided all messages contain valid information, of course). Aside from creating/updating files, the application will respond over the network with corresponding N-Create RSP and N-Set RSP messages.

In view of the fact that storing MPPS objects on your hard drive is the only thing ppsscpfs does, you (in your scenario) will need to write another tool yourself that collaborates with wlmscpfs and ppsscpfs. This tool has to be able to analyze all MPPS objects ppsscpfs has stored and it has to rename/delete the .wl files that describe the corresponding (now completed) studies from you .wl-file directory. Currently, we do not have such a tool, you will have to write it yourself. In case you have some programming experience, this should be no problem though.

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

wlmscpfs and ppsscpfs

#5 Post by roydobbins » Thu, 2005-11-17, 17:34

I am wondering if it is plausible to make this one program?

Would it be worthwhile trying to add the MPPS handling into the wlmscpfs?

Does anyone know if this would be a difficult project to undertake?

I think this would make wlmscpfs a much more useful tool, and it also seems that this approach would eliminate a lot of the difficulty involved in cooperation between the two independent programs

Any comments or hints would be very much appreciated,

Regards
roy dobbins

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#6 Post by Thomas Wilkens » Fri, 2005-11-18, 07:54

One crucial question that arises here is whether the worklist management SCP and the MPPS SCP are supposed to both listen to the exact same port or to two separate ports.

If - in your scenario - these tools are supposed to listen to two different ports, there would be no need to integrate both tools into one application. If - in your scenario - these tools are supposed to both listen to the exact same port, you practically have to integrate the two tools into one application.

And also let me tell you that for the latter scenario we already have a solution, i.e. we already developed a tool that combines a worklist management SCP and an MPPS SCP in one application. This tool is called "pawscpfs" and it combines the features of "wlmscpfs" and "ppsscpfs". This tool is unfortunately not part of the public DCMTK, but you can obtain a licence for a certain licence fee. Please write an email to dicom/at/offis/dot/de in case you are interested.

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

pawscpfs

#7 Post by roydobbins » Tue, 2005-11-22, 16:59

Thanks for the info regarding the pawscpfs tool. I will inquire as you suggest about licensing.

Being a 'do it yourself' type however, and also wanting to learn more about the DICOM standards, and the DCMTK itself, I would still like to take the investigation further.

So my question still stands, if I were to attempt integrating the additional abstract syntax and MPPS handler into wlmscpfs, would this be a feasible/easy project, or not?

As far as the two ports are concerned, I am looking at wlmscpfs toolkit as a way to do preliminary testing of an interface to a hospital information system, so I guess separating this out into two different executables would be more flexible. However, that does not really change the implementation effort. I would then basically take wlmscpfs, strip out the current handlers, and then add the mpps handler. Does this sound like a reasonable approach for the two port scenario?

Of course, there is still the question of implementing the scu aspects of mpps, which is another project? I assume that in a similar way, I would have to take one of the apps, such as storescu and butcher it appropriately? You once mentioned that this had already been done in the mesa tools. Could you be more specific and maybe offer a hint about exactly where one should look, eg a filename?

Thank you very much
Regards,
roy

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#8 Post by Thomas Wilkens » Wed, 2005-11-23, 08:21

if I were to attempt integrating the additional abstract syntax and MPPS handler into wlmscpfs, would this be a feasible/easy project, or not?
Writing an MPPS-SCP application on the basis of the DCMTK is actually not that difficult once you have understood what the MPPS service is about. However, you have to make sure that you indeed have understood how this service works. Look into the DICOM standard part 4 section F.7 to get a glimpse of what you need to do.

In general, the problem is not so much if you are able to implement the service, but that you firstly understand the service's specification and then have the time to implement everything that is needed. Understanding the service might already take an entire day, implementing the service will definitely take 3-4 weeks, including testing.
I would then basically take wlmscpfs, strip out the current handlers, and then add the mpps handler. Does this sound like a reasonable approach for the two port scenario?
Once you have understood the MPPS service, you will find out that it does not have anything in common with worklist management. So dont think that you can reuse most of the things that have been implemented in wlmscpfs. You will be able to reuse some of it, but the most important part (i.e. what is done after MPPS messages are received) has to be implemented from scratch. But in general, the approach you mention is reasonable.
Of course, there is still the question of implementing the scu aspects of mpps, which is another project? I assume that in a similar way, I would have to take one of the apps, such as storescu and butcher it appropriately? You once mentioned that this had already been done in the mesa tools. Could you be more specific and maybe offer a hint about exactly where one should look, eg a filename?
You could use storescu as a starting point for implementing an MPPS-SCU, but I dont recommend doing this. storescu is one of the oldest tools in DCMTK and it is not implemented in an object oriented way. You can definitely reuse some of the code in storescu but you should integrate it into an object oriented environment.

Concerning the MESA tools, these are the keywords for you: IHE, MESA Tools, MPPS, ncreate.exe, nset.exe.

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

MPPS and worklist

#9 Post by roydobbins » Wed, 2005-11-23, 19:20

Thomas:

Thanks very much for the insightful comments about implementing MPPS service. :)

I am wondering though, about your comment that MPPS service has got nothing to do with worklist management. Clearly I dont understand what this is all about... :?:

I had assumed that from the SCU side, you are sending a message which, essentially says "this procedure step has now been performed"
I also assumed that this would correspond to a particular requested procedure step, whose status would be updated. So to me, the two have got a lot to do in common. :shock:

I am however, looking at this from the point of view purely of testing. I dont really care what the HIS or other worklist management system has to do when such a message is received. I only want to know whether I did in fact send the correct message, with required tags, and proper IDs. So in the test implementation, I would probably do what you had once suggested in this forum, about either deleting or renaming the worklist file.

So, correct me if my approach is totally wrong, and I think your answer may help others who are thinking about the worklist problem. To summarize:-

On the SCU side, take something like storescu and add the necessary N_CREATE, N_SET request handlers to make a new MPPSSCU app :idea:


On the SCP side, take something like WLMSCPFS, and add the corresponding N_CREATE, N_SET handlers, which will essentially mirror WLMSCPFS interaction with the file system worklists, ie in response to the MPPS message received, search for and update the worklist file :idea:

Have I got this (more or less) right, or am I totally wrong :?:

Also, since you dont recommend storescu has a starting point, what would be a better place to look, for samples of good object oriented design? I must say that from my initial look at storescu, findscu, and so on, I got the impression that they were all implemented along the same lines, and that one didnt really stand out from any other. Does this mean that if one was really serious about this, one would have to design an OO framework from scratch (possibly reusing code snippets from dcmtk)?

Once more thank you very much for your already submitted comments, and I would like to say that the DCMTK has been a great introduction to DICOM, especially of the networking side. :P


Regards,
roy

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#10 Post by Thomas Wilkens » Thu, 2005-11-24, 08:17

I am wondering though, about your comment that MPPS service has got nothing to do with worklist management.
I am sorry that I did not state my point clearly. Of course, from a hospital perspective, worklist management and MPPS relate to each other, just like you said:
I had assumed that from the SCU side, you are sending a message which, essentially says "this procedure step has now been performed"
I also assumed that this would correspond to a particular requested procedure step, whose status would be updated. So to me, the two have got a lot to do in common.
You are totally right here. I was actually referring to the fact that from a DICOM networking perspective, these two services do not have anything in common, since worklist management uses C-Find messages and MPPS uses N-Create and N-Set messages. So when it comes to dealing with the actual messages which were received, your new MPPS implementation will be very different from my worklist management implementation. That's all I wanted to say.
On the SCU side, take something like storescu and add the necessary N_CREATE, N_SET request handlers to make a new MPPSSCU app
Sounds like a good plan!
On the SCP side, take something like WLMSCPFS, and add the corresponding N_CREATE, N_SET handlers, which will essentially mirror WLMSCPFS interaction with the file system worklists, ie in response to the MPPS message received, search for and update the worklist file
I did it the same way when I implemented ppsscpfs! But please make sure you have understood the MPPS service correctly: it is not possible to update a worklist file each time you receive an MPPS message (N-Create or N-Set); for each worklist entry that was initially sent to the modality, the modality sends one N-Create message and one or more N-Set messages back to the RIS. And only after the last N-Set message (with a Performed Procedure Step Status of COMPLETED or DISCONTINUED) has been sent (and the final state conditions from the DICOM standard are met for all attributes in the MPPS object) you can update the worklist file. MPPS is, unfortunately, a little more complicated than worklist management.
since you dont recommend storescu has a starting point, what would be a better place to look, for samples of good object oriented design?
Ok, I think storescu is probably a good starting point, since all SCUs that are contained in DCMTK are implemented in a functional (not object oriented) way. But one thing you could do is look at the object-oriented implementation of wlmscpfs and try to imitate this design (by creating a main() function which has only a couple of lines, by creating a Console Engine class which contains all the command line options, by creating an Activity Manager class which deals with handling the messages that you have to send etc.). storescu has all this functionality in one large source file, with lots of functions. Wouldn't it be better to have all these functions organized depending on their purpose? I think so.

In any case, good luck with your implementation. If you have more questions, please dont hesitate to ask. And if you would like to share your MPPS-SCU implementation with the world, we would be very happy to integrate your source code into a new version of DCMTK. :wink:

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

MPPS and worklist

#11 Post by roydobbins » Tue, 2005-11-29, 20:39

Thomas:
Thanks for the comments and clarification about possible implementations of mpps-scu

I will keep you posted about progress on any of these tools, and thanks for offering to answer any further questions, which, as I start getting deeper into this, I am sure will arise!

Regards
roy

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

wlmscpfs implementation

#12 Post by roydobbins » Tue, 2005-12-20, 17:53

As part of testing mpps scu, I want to use the existing wlmscpfs code. In order to do this I need to make some changes to the wldsfs.cxx (data source), in particular the way matching data sets are returned in StartFindRequest...NextFindResponse.

I am concerned here about the lifetime of the returned dataset. The dataset instances are I believe created by the datasource, then returned on each invocation of NextFindResponse().

The reference is then deleted (in an array), however I am not sure from reading the code, where the dataset itself is ever deleted??? I presume this must be done by the caller (such as FindCallBack), but I just dont get it.

Im not sure I understand how this is done. And the code I want to change would want to not delete the dataset, but keep it around till later.

Can anyone give me a hint how the lifetime of the matching datasets is managed?

Thank you very much for any help on this
--Roy

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

Re: wlmscpfs

#13 Post by roydobbins » Tue, 2005-12-20, 19:08

Ok, I think I understand,...

The response matching dataset is passed back to the DIMSE find provider,
(dimfind.cxx) which processes the response, then deletes the dataset.

Thomas Wilkens
DCMTK Developer
Posts: 117
Joined: Tue, 2004-11-02, 17:21
Location: Oldenburg, Germany
Contact:

#14 Post by Thomas Wilkens » Thu, 2005-12-22, 08:11

:wink:

roydobbins
Posts: 25
Joined: Wed, 2005-07-20, 22:42
Location: Payson, Arizona

Another object lifetime question in wlmscpfs

#15 Post by roydobbins » Thu, 2005-12-22, 16:54

Well, I now have another question, Im afraid, also today with lifetime of passed objects.

The problem I am dealing with now is I want to copy some elements from one data set into another.

I am trying to do something like the following:

[code]
//merge the request dataset and the selected response dataset
DcmDataset *dataset = new DcmDataset(**responseIdentifiers);
unsigned long num = requestIdentifiers->card();
for (unsigned long i = 0; i < num; i++ )
{
DcmElement *obj = requestIdentifiers->getElement( i );
// roy TODO: must make copy of obj!!!
dataset->insert(obj, OFTrue, OFTrue);
}
[/code]

Now I found out the hard way that this is illegal! (crashes when later deleting the container dataset, since both source and destination containers have potentially the same pointers to contained objects, which are then deleted twice)

So, my question is, how to replace:-

DcmElement *obj = requestIdentifiers->getElement( i );

with (something like):-
DcmElement *obj = requestIdentifiers->copyElement( i );

Is this already implemented somewhere, or should I be looking to providing some such method, or is my approach here altogether wacky?

Anyone have any ideas about the correct approach here?
Thanks
--roy

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest