Viewers: Metadata Provider Overhaul

[JamesAPetts]

Currently the OHIF viewer suffers from the following metadata related issues:

• Cornerstone stores metadata via imageId, which is of the form {loaderTag}:{url}. Where loaderTag tells cornerstone which imageloader to use, and url is the get URL for the resource.

  • This is rather brittle, as depending on the maturity of the dicomweb implementation on the backend, you can get situations where the metadata is fetched via WADO-RS, and the images are fetched via WADO-URI.
  • You can make some band-aid fixes for this, such as rewriting urls if metadata isn't found, but this is also brittle and has been seen to fail in certain cases.

• Not all metadata is always available:

  • WADO-RS headers are currently parsed, some data extracted, and then discarded.
  • This often means we resort to adding tags to appropriate providers in rather bespoke ways
  • However this makes it difficult when you want to fetch some modality specific metadata tags from an extension without touching the core platform. (E.g. extracting the RTROIObservationsSequence from an RTSTRUCT).
  • We can expose the original raw headers and let the extension parse these, but it'd be nice if the whole instance metadata was cached and transformed to naturalized DICOM JSON.

• The viewer is mostly tested against a full WADO-RS DicomWeb implementation. This means unexpected edge cases and difficulties occur when we switch to WADO-URI only platforms. E.g. a WADO-URI only backend called via JSON standalone routing doesn't extract enough metadata, or metadata in the expected form for the isDisplaySetReconstructable function to run, unless the required headers are known, and supplied in the JSON.

• Different capitalisations of standard variables exist everywhere and this is confusing (e.g. SopInstanceUid, SOPInstanceUID, SopInstanceUID, etc).

Solutions:

• WADO-RS headers and WADO-URI retrieved full P10 instances should be parsed to naturalized DICOM JSON (with pixel data removed for the full instances), and this should be the standardised source of truth.

  • The main logic of WADO-RS headers -> naturalized DICOM JSON should probably live in dcmjs.

• Metadata should be indexed internally on StudyInstanceUID, SeriesInstanceUID and SOPInstanceUID. When an imageId is supplied, this information should be extracted and the appropriate metadata searched for. In the worst case scenario it'll fallback to cornerstoneWADOImageLoader's data.

  • You should be able to fetch any top level DICOM tag via the imageId this way. E.g. To resolve an earlier presented issue:
  • const RTROIObservationsSequence = cornerstone.metaData.get('RTROIObservationsSequence', imageId);
  • Which will return a naturalized DICOM JSON object (or just a string if the tag isn't a sequence).
  • We need to retain aliases to the data that cornerstoneWADOImageLoader provides, as this is widely used, e.g. in cornerstoneTools.
  • This should probably live in @ohif/core.

• All variables thoughtout core parts of the application should have all dicom attributes conforming to the DICOM Data Dictionary as source of truth for how these should be capitalised (i.e. SOPInstanceUID is correct).

  • This means having variables which aren't constructors in pascal case, which may make some developers wince, but it should be really obvious what is and isn't a dicom tag, dcmjs has already followed this mindset.

[JamesAPetts]

Please contribute any thoughts to this thread, this is the culmination of a bunch of discussions with @swederik and @dannyrb .

[pieper]

Yes please!