Configure epad to use another DICOMWeb server?

[jcosgrovehoppr]

Hello,

I am trying to integrate epad with an existing DICOMWeb server. I have three questions.

1. Is this possible by simply changing the WADO URL in the configuration file?
2. How difficult would it be to specify custom headers when querying this server? For authentication purposes.
3. Does epad save annotations as DICOM structured reports to the DICOMWeb server it is configured against?

[emelalkim]

Hi Jack, Thanks for your interest

1. It is definitely possible to use a different DICOMweb server. You should be able to generate proper configuration files with giving a uri under dicomweb in the yml file (instead of image, dockerfiledir, loc). It has been a while since I implemented this so let me know if you experience any issues.
2. This may be trickier. I have implemented support for basic authentication and openid with keycloak but honestly we didn't test it with something else. the connection code is in the epadlite-dicomweb connection plugin. I'd appreciate any contribution, both testing and prs. Depending on which configuration you are using (environment or config files) you may need to add some extra configuration to set up the authentication
3. it is saving DICOM segmentation objects for the brush annotations but we are not currently saving DICOM SR, the geometric coordinates and answers to the template questions are saved as AIM json files. It is definitely something that is on our agenda. We have already worked on AIM-DICOMSR compatibility and conversio; and old epad already had the DICOM-SR export capability, it is just taking time to port all functionalities to epadlite. Hope I was able to reply your questions, feel free to follow up Emel

[jcosgrovehoppr]

Hi Emel,

Thank you for the response.

It's good that the DICOMweb server can be configured.

My authorization scenario is that the user will be prompted to load epad after clicking a link in another application. That other application contains the authorization token for the DICOMweb server. The most straightforward solution I can think of is for the link to epad to embed the authorization token as a query string parameter. In fact to make it more general it would be nice if the epad application could read a set of headers from the query string and use those for every DICOMweb request. For example:

https://host/epad?header:Authorization=base64HeaderValue&header:Other-Header=base64headerValue

Is the code within the DICOMweb connection plugin able to read from the query string at the time the connection is set up?

It would really help if annotations could be stored as DICOM SRs via the DICOMweb STOW API. Do you have any idea how much work would be involved in that or when it could be completed?

[emelalkim]

Hi, we haven't had a request like that till now. I mean to forward the headers. It is a little tricky because epad has a frontend and backend. you launch the application from the frontend, it would have to add headers to wado calls and also send with API request to the backend, as backend also uses qido calls to get data about the studies. And then there is the problem with refreshing the token. Can you tell us a little bit about your scenario? Do you want to use epad just as an annotation tool? Do you want to tell epad to open specific study/series? should epad be able to read everything in the dicomwebserver in the search view? Do you need projects? When we have a clearer idea we can discuss about how to implement it with the team.

DICOM SR is definitely on our plate, we are planning to work on it as soon as we finish reimplementing functionalities of old epad. my estimate is in a month or two.

I can definitely point you in the right direction if you are interested in contributing in either Thanks,

On Fri, Jul 24, 2020, 9:31 AM Jack Cosgrove notifications@github.com wrote:

Hi Emel,

Thank you for the response.

It's good that the DICOMweb server can be configured.

My authorization scenario is that the user will be prompted to load epad after clicking a link in another application. That other application contains the authorization token for the DICOMweb server. The most straightforward solution I can think of is for the link to epad to embed the authorization token as a query string parameter. In fact to make it more general it would be nice if the epad application could read a set of headers from the query string and use those for every DICOMweb request. For example:

https://host/epad?header:Authorization=base64HeaderValue&header:Other-Header=base64headerValue

Is the code within the DICOMweb connection plugin able to read from the query string at the time the connection is set up?

It would really help if annotations could be stored as DICOM SRs via the DICOMweb STOW API. Do you have any idea how much work would be involved in that or when it could be completed?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RubinLab/epad-dist/issues/13#issuecomment-663624120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXQXTRYUAWGAZERUUKTKZ3R5GZOHANCNFSM4PFBID2A .

[jcosgrovehoppr]

I see about the frontend and backend.

Our scenario is that we have a web application within which we would like to embed a link to a separate epad instance for annotation purposes. And yes, would like to be able to narrow down the link to specific studies. Using the searchview is not so important since our own web application has search capabilities and we would simply need to locate a study by its study ID through the URL path.

We shouldn't have to worry about projects now since we intend to build our own orchestration logic in our web app. For now we only need the annotation capabilities of epad.

Our backend is ready to ingest DICOM SR annotations through the DICOMweb STOW API. That would be necessary to close the loop with the annotation workflow.

I agree passing and refreshing the token is not straightforward given that epad has a frontend and backend. We use Auth0 for authentication, so there is an OIDC endpoint.

Here are the relevant settings which I have been able to figure out regarding authentication.

epadlite:
  mode: image
  image: latest
  port: 8080
  dbname: epadlite
  log: true
  https: false
  auth: auth
  authuserinfourl: "https:\/\/[subdomain].auth0.com\/userinfo"
  loc: "api"

However I'm unsure where the settings should go for the Auth0 authentication endpoint, including the URI, client ID, and client secret. I found this https://github.com/RubinLab/epadlite/blob/master/plugins/DICOMwebServer.js#L13, but am unable to have these settings added to the generated docker-compose.yml file. Here is my current dicomweb section.

dicomweb:
  mode: external
  port: 8090
  uri: "[DICOMweb uri]"
  log: true
  auth: none

Could you guide me on where in the epad.yml file I should place the authentication URI, client ID, and client secret?