Re: understanding DICOM workflow
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
Reply to: