Edit this page

NA-MIC Project Weeks

Back to Projects List

DICOM Meta-Dashboard

Key Investigators

Project channel on Discord: #dicom-meta-dashboard

Project Description

In practice, importing DICOM files into workspaces (e.g., for reader studies, analyses, …) requires some manual filtering, sorting, and selection.

There are probably countless attempts at supporting this workflow (some of which I am aware of), but this project is about checking what the Meta dashboard that comes with Kaapana already supports and could (/should) support in the future.

Having a dashboard summarizing a data collection in a meaningful way is a recurring theme also outside of kaapana. We would like to investigate to which degree the requirements coming with common use cases (such as AI annotation, cohort definition, AI model training, automatic quality assurance) are already met and if they’re not, how extensible the existing dashboard is. Furthermore, it would be interesting to assess whether such a dashboard can be shared with other projects (IDC, Grand-Challenge), and whether that really makes sense in practice. Related to Fast viewing and tagging of DICOM Images (as well as to previous PW endeavors around Chronicle and DICOMweb by Steve Pieper).


  1. Use the Meta Dashboard without kaapana, on data that is not in a PACS.
  2. Understand the limits of the current OpenSearch/Kibana stack, and whether it supports all intended use cases.

Approach and Plan

  1. Find out about the schema / information used by the Meta dashboard.
  2. Try to set up the Meta dashboard outside of kaapana.
  3. Feed OpenSearch with data from a dataset that is not in a PACS.
  4. Document results (code / schema / design / use cases).

Progress and Next Steps

  1. Hans has learned (mostly from Stefan) much about the current process / integration of the Meta dashboard in kaapana, and about its code location(s). Many things have been documented on this page to help others as well.
  2. Hans spent a lot of time reviewing Kaapana code and opened a pull request with a few refactoring steps (https://github.com/kaapana/kaapana/pull/13).
  3. Hans wrote a MeVisLab module “DICOMTree2JSON” that mimicks what dcm2json does and converts in-memory DICOM information into JSON. (The output has been verified to be “mostly identical” except for the pixel data which is not dumped. Other exceptions are integer “1\u0000” -> 1, for instance.)
  4. Kaapana’s dashboard defaults to documents on the series level (but the code would also support SOPInstances / single frames). Hans is using MeVisLab’s / SATORI’s image level, which can be both below or above the series level, depending on the import configuration (e.g., composing DCE-MRI volumes from multiple images). Of course, this needs to be taken into account when configuring the dashboard.
  5. Kibana nicely allows filtering on any level (patient / study / series / image properties), but the dashboard will only list the number of patients that contain an image matching a certain criterion, not the patients that contain only images matching a criterion. A query such as “give me all patients that have at least two timepoints with a T1 and a T2 weighted image” does not seem to be possible. There seem to be more complex aggregation options in OpenSearch, however, so it remains to be investigated if that could be implemented as well.


Screenshot of resulting meta dashboard with data ingested from a MeVisLab-based SATORI workspace:

Kibana dashboard showing information about 18,613 images

Background and References

General information / pointers:

Reviewing LocalDcm2JsonOperator revealed the following functionality (not complete):

Summary of steps I performed in order: