Update the schema to describe DICOM plugins provided by the extension

[fedorov]

Following on the discussion at the dev meeting today, we propose to expand the schema to include something like the following:

"dicom_plugins" : {
      "$id": "#dicom_plugin",
      "type": "array",
      "title": "List of DICOM plugins implemented in the extension",
      "additionalItems": false,
      "modalities": { "type": "string" }
}

This way, later on, we would be able to associate all extensions that handle individual modalities, and at import and examine of a modality that has additional extensions available, notify the user and offer to install those extensions.

[lassoan]

If we want to add a field that lists modalities then it should look something like this:

"dicom_modalities" : {
      "$id": "#dicom_plugin",
      "type": "array",
      "title": "List of DICOM modalities supported in the extension (import, export, analysis)",
      "additionalItems": false,
      "items": { "type": "string" }
}

But I'm wondering if we should be a little bit more specific. We could use SOP class UID, which is similar granularity as modality, but it can be used to distinguish between legacy/enhanced, single/multi-frame, subtypes (e.g., SR can be basic structured report or KOS), and device-specific variants (e.g., can be used to distinguish different ultrasound image types). It could look like this:

"dicom_sop_class_uids" : {
      "$id": "#dicom_sop_class_uids",
      "type": "array",
      "title": "List of DICOM SOP classes supported in the extension (import, export, analysis)",
      "additionalItems": false,
      "items": { "type": "string" }
}

If we want to really make this future-proof, we could specify a single filter expression string property (to be evaluated by Python rule engine). We would not need to predefine what tags we want to check but we could check value of various tags, combined with logical operators. For example: 'CT' in ModalitiesInStudy and TransferSyntaxUID == 'JPEG​Lossless'

[fedorov]

If we want to really make this future-proof

I don't! I am not a believer in future-proofing from the outset in this situation - I don't think this is needed, and sometime these efforts can unnecessarily complicate life for users.

I would prefer to proceed quickly with a flexible, minimal definition, refining it as we go. Even if we allow the extensions to simply declare that they provide DICOM plugins, this would be a huge improvement over what we have right now - which is zero ability to collect any information about plugins.

I don't object to adding SOP class UID in principle - very appropriate and a great idea. The question is whether it should be optional or mandatory. We should also think about the implications of requiring that attribute. Think about generic plugins, such as dcm2niix, which are not modality- or class-specific. How would we expect maintainer of that plugin to populate SOP class UID field? I would argue that we first add very basic support - just modalities - then we collect the inventory of all plugins we have, analyze their specifics, populate those fields for all plugins, and after that review how to update the schema (in addition to class UID, it would probably make sense to be specific about whether plugin supports both import and export).