Design doc

[Sjoerd Kerkstra]

Problem

The research bureau and DIAG data team are currently using versions of the wado connector repo to download medical images from our existing AGFA VNA.
AGFA VNA will be replaced by a new vitrea VNA. This means the existing module will need to be rewritten. In addition, the existing module is not of good quality, being an extract from older anonymization server code.

Appetite

How much time we want to spend and how that constrains the solution

Having a re-usable, well documented module for interfacing with our VNA is important. Getting this right now will solve problems in the future. Big appetite: 3 weeks

Solution

The core elements we came up with, presented in a form that’s easy for people to immediately understand

For IDIS The following functions will have to be supported (in pseudocode):

get_study_info(StudyInstanceUID) -> PatientID
get_instance_uids(StudyInstanceUID) -> List[SOPInstanceUID]
download_wado_image(StudyInstanceUID, SOPInstanceUID, basedir) -> writes slice to base dir 

These functions will be implemented in two steps: First, a clean internal connector module that works with pydicom Dataset objects wherever possible. Second a legacy layer the uses this module to offer methods matching the methods above.

Part 1: The connector module

• This module interfaces with the vitrea VNA on one end, and offers high-level functions on the other.
• User-facing functions such as 'give me all data for study X' or 'give me all SeriesUIDs for study X'
• To do this it will employ standard connection mechanisms such as WADO, DICOM QR and MINT.
• Wherever possible, the module will use pydicom Dataset objects to represent DICOM datasets.

Part 2: Legacy functions for existing applications

Existing applications are using several functions in the [https://github.com/sjoerdk/wado](wado module) at the moment. To make migration to the new module easier, a legacy module will be included

This will have functions with the same signature as the most-used current functions so that moving to the new module can be as changing in import statement.

usage in anonymization server all comes down to this function:
https://github.com/DIAGNijmegen/anonymization_server/blob/master/anonserver/databaserelated/wrappers.py#L483

Rabbit holes

Details about the solution worth calling out to avoid problems

No rewrite of existing module. Rewriting the existing wado connector will not be done because the code quality is too low. For instance, the library uses an old custom library for modeling DICOM elements and tags that is inferior to pydicom Dataset in every way and makes it hard to integrate. In addition, the existing module's name is 'WADO' which is a misnomer as it also uses DICOM QR and possibly mint. Lastly, the login mechanism that the library was built for is convoluted. This is due to both the AGFA packs actually having a strange mechanism, and the coding being sub-par.

MINT or DICOM QR, not both. To replace existing functionality, we need a method te retrieve all SOPClassInstanceUIDs for a given study or series. This can be done either with MINT or DICOM QR. If one of these methods is implemented, the other can be left as a stub and not implemented in this iteration

Legacy functions are not essential. If discrepancies in internal workings of the old WADO and new module make legacy functions difficult to implement, we will provide a migration guide instead of a legacy functions

No-gos

Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

Only implement existing functionality We will implement the ability to retrieve the DICOM images for studies from the VNA, and any queries related to that (e.g. find all slice IDs for a given study). No new functionality will be added.

[Sjoerd Kerkstra]

This is now done. In retrospect the 3 weeks set for this was more then enough. As a result I went into one of the rabbit holes and implemented DICOM-QR as a search method in addition to MINT.