Hello Karsten,
> > I have got two questions regarding this plugin:
> >
> > 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)."
So, to feed Orthanc with worklists that are generated by GNUmed, the best way
would be to develop a custom plugin that relies on the Orthanc Plugin SDK for
worklists [2]. Using this Orthanc Plugin SDK, you could quite easily implement
your requirement in a few lines of code. There are actually 2 possible
approaches:
(a) The "pull from GNUmed approach". Your plugin would first register a
worklist callback with "OrthancPluginRegisterWorklistCallback()". Your callback
function would use the function "OrthancPluginHttpGet()" to retrieve the
worklists through the REST API of GNUmed, and would filter the retrieved
worklists with "OrthancPluginWorklistIsMatch()" to only keep the worklists that
match the user's query. The matching worklists would be returned to the caller
with "OrthancPluginWorklistAddAnswer()". This approach would have my favor, as
the plugin would not need to store the worklists in a dedicated database.
(b) The "push to Orthanc approach" (which is what you proposed in your
question). The idea is to replace the loop over the directory in the official
sample plugin [3], by a loop over a set of worklists that are contained in
memory. This set of worklists can be modified by implementing a custom REST
callback (over the PUT, GET, and DELETE HTTP methods) with the function
"OrthancPluginRegisterRestCallback()". In this case, the plugin needs to manage
a local database if you want persistence.
I hope this clarifies things.
Regards,
Sébastien-
[1] http://www.orthanc-server.com/static.php?page=blog#stable
[2] https://orthanc.chu.ulg.ac.be/sdk/group__Worklists.html
[3] https://goo.gl/rQiSK6
