Re: understanding DICOM workflow

[Karsten Hilbert <Karsten.Hilbert@gmx.net>]

Hello Sébastien,

On Thu, Jan 14, 2016 at 12:00:55PM +0100, Sébastien Jodogne wrote:

> > > 1) Are you planning to provide something like this (pseudocode):
> > > 
> > > 	curl PUT SERVER:worklist/WORLIST_NAME/worklist_file?data=data_of_worklist_file.wl
> > > 
> > > 	That way, external software (like GNUmed) can submit worklist entries.
> > > 
> > > or even
> > > 
> > > 2) Is there any chance to support (pseudocode)
> > > 
> > > 	curl PUT SERVER:server/create-worklist_entry?data={name=..., gender=...,
> > > 	modality:..., worklist=..., ...}
> > > 
> > > 	In other words hiding the creation of a worklist file
> > > 	behind a REST API call.
> 
> To answer your questions, it is important to understand the philosophy of Orthanc wrt. worklists that is described on our blog [1] :
> 
> "Serving worklists is done through the plugin
> infrastructure of Orthanc. The rationale for using plugins is
> that worklists are generated by mechanisms that live outside
> the DICOM world (e.g. HL7 or FHIR messages), and that are
> specific to each clinical workflow. Creating plugins allow to
> make the Orthanc core independent of these mechanisms. Note
> that for basic uses, we provide a sample worklist plugin,
> that reads its worklists from some directory on the
> filesystem (which mimics the "dcmwlm" tool from DCMTK)."

I support the rationale and the reasoning behind it. That
will rule out the 2) approach I listed above.

Let's see:

When the ModalityWorkList plugin is loaded the Orthanc server
gains the following capabilities:

	- watch a given path for files (which represent worklist entries in DICOM format)
	- when queried appropriately, return answers based on those files

Is that correct ?

If so I was wondering whether the ModalityWorkList plugin
could be extended with one REST API call which would allow
external applications to add *.wl worklist item files over
the network rather than having to store them into the watched
path directly. All the ModalityWorkList plugin would do is to
accept such files and store them into the watched path.

Sound reasonable ?

This would enable the following scenario (related to the OPs
inquiry):

- user activates patient in GNUmed
- user invokes "schedule ultrasound exam"
- GNUmed creates appropriate *.wl DICOM file
- GNUmed sends said worklist item file to
  ModalityWorkList plugin over the REST API
  which stores it in the watched path on the
  Orthanc server

- user has pointed their ultrasound device at the Orthanc
  server with the ModalityWorkList plugin
- user selects "choose job from worklist" on the US device
- US device queries Orthanc for jobs and displays a list
- user selects GNUmed supplied job on US device from list

The latter part should already work, to my understanding ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346