Are custom modes the right way to build workflows that involves listing / exploring several studies together like an alternative to the Study List (Worklist) component? Or are they intended to make custom UIs to work with a single study?
Context
My team is evaluating options to build an app to explore and manipulate the DICOM datasets that we have. After spending some time with the OHIF documentation, it looks like most of our viewing and annotation use cases are already covered. But we’ll need some custom behavior around the UI to explore the data set, advanced search capabilities etc. From the docs, I understand that the recommended way to customize the viewer is to build extensions and modes that consume them. We do not plan to publish the modes or extensions. We just want them to work together for our customized viewer app.
Consider a use case where, instead of the default study list we want to have a custom landing page which lets users provide a list of Study Ids to view. As per the docs, I can achieve this by setting up a specific route using a custom mode and rendering my custom component using the layoutTemplate field.
Questions
In this case, my custom mode is not really a custom UI to visualize a single study. Instead, it is an alternative way to explore a list of studies - a custom study list. But all the existing modes, seem to be specific UIs to work with a single study. For instance, all the registered modes are displayed in the expanded view of a row in the Study List (Worklist). In my scenario, showing up my custom study list as a mode for a single study does not make any sense, even though I could just make sure that it is always disabled for every kind study by always returning false from isValidMode. It feels a bit hacky and out of place to use modes this way. I was wondering if I would run into other issues down the line because of such an assumption. Are there any other constructs in the platform other than custom modes, which is more appropriate for this scenario?
Another question I have is around multiple routes per mode. Currently from the source code, it seems that we only consider the routeName field in a mode and not the routes[x].path field. Is this something that is planned to be worked upon? In my scenario, we’ll eventually have multiple such custom study list alternatives to expose different ways to explore a list / group of studies. In this case they would probably be separate React Components with no real usage of any mode specific functionality. But right now, I see no other option than to create separate modes for each route. Is that correct?
Thanks for your question. However I am having a bit of difficulty understanding your use case and ultimately the question itself. But I will do my best.
I suppose the OHIF worklist only launches a single study per mode, but the viewer can be launched independently of the worklist itself (via URL) with a particular mode.
Regarding multiple routes per mode, currently only one route per mode is handled.
My use case is along the lines of building a UI to browse through a large number of studies. Instead of the example with 2 studies that you provided, what can I do to support a larger number of studies, like 100 studies? Wouldn’t we exceed the URL length limit? Say if I had a pre-computed list of 100 studies, I would like to have a mode which displays those 100 studies in the left panel.
Ideally instead of passing the 100 IDs in the URL, I would like to add some logic in one of the mode initialization hooks to fetch / compute this list and then render those studies in the side panel. Also, I would like to customize the left panel to have more real estate and have a grid of thumbnails rather than a list of them.
I’m not sure if such customizations are possible. To begin with, I was just trying to create a mode that renders a hard coded list of say 100 studies in the left panel. During this exercise, I felt that the app expected each mode to be opened with some StudyIDs in the URL which is not the case for the mode that I’m trying to build. This got me wondering if I’m going against some basic ideas of what a mode is supposed to do.
The first thing I will say is that I am not certain what is the breaking point of the OHIF viewer in terms of the number of studies it can handle, but I will try to find out if those metrics are available. That said, please share your findings once you have tried various numbers of studies. Thanks.
All the customizations you mentioned are possible, but it all depends on the amount of reuse of the existing components/extensions you would like to make.
Let’s start with not specifying the studies from the URL for a DICOMWeb datasource. The initialize method of the default DICOMWeb data source in the default extension is where the study UIDs are parsed from the URL. You could create your own custom extension theat provides a different DICOMWeb data source that has an initialize method that forumlates and returns the study instance UIDs another way.
As for customizing the side panels, that can be done in a custom mode. If we look at the longitudinal mode (which is the default mode for the demo server), it uses the default viewer layout from the default extension and specifies that the left panel contains the tracked measurements panel from the measurement tracking extension. Alternatively, your mode could replace ANY or ALL of those components with your own custom components. For example, you could keep/use the default viewer layout and simply replace what is in the left panel. Find more info for viewer layout template in the OHIF docs.
These are just suggestions. The amount and type of customizations are really up to you.