wlmscpfs: change worklist files to database query

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Posts: 15
Joined: Wed, 2005-02-02, 10:36

wlmscpfs: change worklist files to database query

#1 Post by jmartens » Fri, 2005-03-11, 11:42

I'm familiar with the DICOM Toolkit but unfortunately (not really) experienced with changing/editing source code and recompiling.

In our institue we make use of a MySQL based Electronic Patient File. We would like to provide worklists to our DICOM modalities based on the information in this database.

Therefore I would like to rewrite the wlmscpfs tool (or let it be rewritten by our inhouse software engineer) not to take it's worklists from the .wl files but build the results based on queries returning information from our Electronic Patient File database.

I have been looking through the source code and am wondering where the reading/searching of the .wl files is done as I'm thinking that would be the place to start implementing the interaction between wlmscpfs and our system. Am I correct there? Can someone provide me with some hints pointers where to look/find some startpoint?

Thanks in advance!

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

#2 Post by Thomas Wilkens » Mon, 2005-03-14, 09:10

Look at WlmDataSourceFileSystem::StartFindRequest(...) and WlmDataSourceFileSystem::NextFindResponse(...). These are the two important methods in WlmDataSourceFileSystem. (The first actually reads information from the .wl files through the call to fileSystemInteractionManager->DetermineMatchingRecords(...).)

You will need to implement 2 classes, one class analogous to WlmDataSourceFileSystem, something like WlmDataSourceDatabase, and one class ananlogous to WlmFileSystemInteractionManager, something like WlmDatabaseInteractionManager.

Another important function is FindCallback(...) in wlmactmg.cc, this function calls dataSource->StartFindRequest(...) and dataSource->NextFindResponse(...).

In general, it should not be a problem for you to implement the 2 classes you need. Take the existing classes (WlmDataSourceFileSystem and WlmFileSystemInteractionManager) as an example an go from there.

Posts: 18
Joined: Thu, 2005-04-21, 04:23
Location: China


#3 Post by jayition » Mon, 2005-05-23, 02:20

I will do the work like this! and I found this message, it helps me ! thanks!
Love programming!
My Blog is:

Posts: 11
Joined: Thu, 2004-11-18, 08:16

I have finished the wlmscp for database

#4 Post by joyli » Fri, 2005-09-09, 06:55

I have finished the wlmscp for database( access/sql/ora),if anyone need some help ,send email to me.


Posts: 9
Joined: Sun, 2005-11-20, 08:06

Need help on wlmscpfs..

#5 Post by cool_head » Sun, 2005-11-20, 08:11

Hi ,

I need some information regarding wlmscpfs: of DCMTK .
We have sucessfully implemented imagectn . It uses mysql as
its database .
Now , we want to integrate (wlmscp) into our server which too
should use mysql .
I am not clear how to and from where to start this task as I
dont have any idea about what this worklists really are ..

Plz, give ur valuble sugessions and ideas on this regard .

Thanking U,


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

#6 Post by Thomas Wilkens » Mon, 2005-11-21, 07:55

If you need to find out what the DICOM worklist management service is about in detail, look in the DICOM standard part 4 annex K or pose a corresponding question in the comp.protocols.dicom newsgroup.

To give you a rough description of the Worklist Management Service: it is a service between a modality (SCU/Client) and usually a RIS (SCP/server). The modality sends a (C-Find Request) message to the RIS asking a question like "what patients am I supposed to examine today?" and the RIS sends one or more (C-Find Response) messages back to the modality, each containing one patient who is supposed to be examined. The set of all response messages together makes up the so-called work-list, i.e. the list of patients who are supposed to be examined. Response messages contain information about the patient (name, birthday, gender, allergies, ...) as well as information about the procedure that is supposed to be performed (start date/time, performing physician, requestion physician, modality, ...) and other information (study instance uid which is supposed to be used for the examination, ...). The reason for this service is a) workflow support (no need to insert patient information manually at the modality) and b) reduction of inconsistencies in different systems (manual input of patient data at the modality often lead to misspelled names, wrong birthdates etc.).

Post Reply

Who is online

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