Me and my team have a need to manage DICOM based on user. We would like to use Orthanc as the pillar of our application because we truly believe in it’s resilience and amazing community. We already use it in our current platform PARADIM. We would like to contribute to add new functionalities.
Context
Right now, we use Kheops to wrap Orthanc and provide user based access with an intuitive interface to manage DICOM. What we like about it, is that it’s possible to fine grain the access for the user and provide an album abstraction. It’s a necessary use case for our non technical imagery specialist to be able to organize them in a visible matter and offload the responsibility of the IT team.
It did it’s job for the short term, but one of the issues is that this legacy platform does not receive enough support nowadays and suffers critical problems such as frequent crashes and consumes a lot of server power to run the micro-services architecture. One of the main reason behind these issues, is that he architecture of the project is not adapted to the context. By that I mean it introduces unnecessary complexity by introducing micro-services were all parts of the applications are tied together making it difficult to maintain. Furthermore, it does not have sufficient tests so it makes the refactoring/debugging processes a nightmare.
We would like to transition from the platform and contribute to Orthanc to bring the best of both worlds together.
Base ground
Right now, we have tried some of the features of Orthanc-Auth-Service and we really like the fact that the user interface is tightly coupled to Orthanc from a maintenance perspective as our needs do not require horizontal scaling for the small amount of users we have. Also the fact that the Orthanc-Explorer-2 leverages the Advanced Auth Plugin to perform permissions based access is amazing. We Think it makes sense to integrate them as plugins. Keycloak as a micro-service along side the Orthanc-Auth-Service as a middleware for authentication makes sense for us as they can integrate together gracefully.
Feature request and contribution offer
We would like to implement the Orthanc-Auth-Service (or the Orthanc-Explorer-2) with bonus functionalities like album management and the POST of DICOM instances using DICOM-Web, what are your plans for the future of auth-service and Orthanc=Explorer-2 in that regard? How could we contribute together, and what do you think is the best approach?
We would be glad to work together and offer back to the community. If anyone else would be interested in such features, let us know!
Using DICOMWeb to upload studies in OE2 should not be a big issue - although I’m not sure to understand the benefit.
Concerning the Album management feature request, could you first explain what is an Album in your view ? I’m not sure there is a well agreed definition of a DICOM Album so it’s best to clarify it before discussing any further.
As you might now, our authorization logic is mainly label based right now so one good question to start with is probably “can we implement Album via labels ?”
Let me add some context, an Album is not defined in the DICOM standard. It’s a metaphor that we use to group DICOM in a collection that is accessible to only the user (or the users) who owns the collection. Depending on it’s role, a given user will have some permissions such as creating a new album, sharing an album, deleting studies, etc. Let’s assume for simplicity that it’s only managed at the study level like auth-service, a given album could contain multiple studies. So an album could be managed by some users and at the same time be readonly for other users. An album is given a distinctive name to be able to recognize it among the other ones. If we put ourselves at the place of the image specialist, the use case is to manage some collections of DICOM by organizing them and adding annotations on them.
You are right, labels can represent albums if we organize them carefully. Indeed, a given study would have a label for an album manager and another one for a guest user. We would need to prevent name collision with an hash and make sure that both tags for admin and guest are mapped together. We could add a significant name at the beginning of the album to identify it’s name. To make sure it’s based only on certain users, we would need a way to relate the hash to a group of users. Essentially, we would like to build on top of labels an album abstraction layer.
Labels are not practical for a non-technical user because it’s not common knowledge, nor in the interest of the image specialist to understand name collision and change tags dynamically for a given group of studies. It introduces a lot of complexity that would in many circumstances be offloaded to the IT team to manage all of it. It’s also error prone from a security perspective. The UX is important in this case to save time for both the IT team and the image specialist.
Upload DICOM and annotated DICOM through albums using authenticated access rights
On another note, ideally we would use OHIF integrated in Orthanc. The problem, is that the tools for annotating are very limited with their functionalities in OHIF 2 and especially in the last version with OHIF 3 where we were unable to configure the platform do to it’s architectural changes for config management. We found that 3D Slicer is best adapted for what we need even though it’s not perfect, because it’s a desktop application that needs to be accessed through a virtual desktop.
In the meantime we are looking for a way to abstract the technology of the viewer with a token access. We need a way to authorize the user for a given period of time to upload DICOM in their album. The vision is to generate a token that would be stored safely for a given user. That user would then decide in which album the DICOM collection would be stored using DICOM protocol or DICOM-Web to store the given collection. We assume here that the auth plugin gave access using the auth-service. In the Orthanc-Explorer 2, it’s possible to upload DICOM, but we would need to add some scripting to make sure it’s given the right labels on upload with a python script event like onStableStudy to correspond with the albums concept which is part of the solution previously mentioned to abstract complexity.
We could organize a discussion to talk about it, if you have any questions let me know! Our team would be glad to collaborate and deliver an adapted solution for the community.
We need a way to authorize the user for a given period of time to upload DICOM in their album.
I assume you’ve read about the Advanced authorization plugin : you can perhaps also encrypt the name of the currently “active” album where the DICOM will be added.
but we would need to add some scripting to make sure it’s given the right labels on upload with a python script event like onStableStudy to correspond with the albums concept which is part of the solution previously mentioned to abstract complexity.
I am not sure I understand the bigger picture but, if you generate labels for all such albums, you could maybe intercept the POST on instances/ in a Python plugin, extract the user from the headers, perform the POST then add a suitable label on the resource? So that every instance in the study gets “added” to the album right away? That sounds more robust than doing it on stable age to me (but I certainly lack some context)