microsoft / dicom-ohif

Deploy OHIF Viewer on Azure and Configure it to work with Azure Health Dicom service

Azure DICOM service with OHIF viewer

OHIF Viewer is a open source non-diagnostic DICOM viewer that uses DICOMweb API's to find and render DICOM images.

This project provides guidence on deployment of OHIF Viewer on Azure and configurations needed to work with Azure Health Data Services DICOM service .

Steps

Create a new Azure Health Data DICOM service

• Create a Azure Health Data services workspace.
• Create a DICOM service. Go to the newly created resource.
• Make a note of the Service URL (the URL to the newly created DICOM service), it will be used in a later step.
• Assign roles to yourself or users accessing OHIF viewer to provide read write access using "DICOM Data Owner" Role.
• Set CORS on DICOM service created in the previous step to allow web URL's that can access the service.

Register an application with Microsoft Identity platform

• Register a new application. Choose Accounts in this organizational directory only for who can access and skip Redirect URI.
• Grant scoped permission to the DICOM service
  • Skip Certificates and secrets, since we will use delegated/on-behalf of workflow
  • Grant admin consent for your org to use the API. Verify the green check in the diagram is checked.
  • 
• Make a note of the Application (client) ID, it will be used in a later step.
• Make a note of the Azure Active Directory Directory (tenant) ID, it will be used in a later step. (It can also be found on the root Overview page of your Azure Active Directory. There it is listed as Tenant ID.)
• Leave this browser tab open, as it will be used to add a redirect URI in a later step.

Deploy OHIF Viewer on Azure Storage Static Website

• Click on the button to deploy a new Storage Account and configure it to host OHIF.
  

  Provide the following inputs:

  Parameter	Value	Description
  Subscription	user provided	Desired subsciption to host the OHIF viewer
  Resource Group	user provided	Desired Resource Group name. May be a new or existing.
  Region	user provided	Desired Azure Region to host the Resource Group and Storage account website.
  Storage Account Name	user provided	Desired name of storage account. This will appear in the OHIF URL.
  Dicom Service Url	Service URL	Existing DICOM service URL (noted above)
  Aad Teanant Id	Directory (tenant) ID	Existing Azure subscription AAD Tenant Id (noted above)
  Application Client ID	Application (client) ID	Existing Application Client ID (noted above)
  CDN Name	user provided	Desired name for the cdn instance

• Make a note of the cdnEndpoint and storageAccountWebEndpoint from the ARM deployment output variable. (You can find the output variables on the left-hand column, once the custom ARM template has successfully completed creating resources.)

Enabling OHIF Viewer on a Private Link enabled workspace

If your Dicom service is in an Azure Health Data Services workspace with private link enabled then you will need to configure a few things in the storage account created in the previous step.

• Navigate to the storage account that was created as part of the deployment of OHIF viewer from the previous step
• Add a new private endpoint (Security + Networking > Networking > Private Endpoint Connections > + Private Endpoint) to the same vnet and subnet as your Dicom service. The target resource should be web.
• Disable public network access (Security + Networking > Networking > Firewalls and virtual networks > Private Endpoint Connections > Public Network Acccess > Disabled)

The OHIF viewer won't be accessible from the cdnEndpoint but instead it will be accessible through storageAccountWebEndpoint (which is the storage account static website endpoint). But accessing from storageAccountWebEndpoint will cause "Cross Origin Isolation is not enabled, read more about it here: https://docs.ohif.org/faq/". To resolve this error, you need to change the \Storageaccount$web\app-config.js file to include useSharedAccessBuffer: 'FALSE' under datasource configuration. The app-config.js file can be found in the storage account created in the previous step. The app-config.js file can be found under the $web container in the storage account. You can edit the file by clicking on the file and then clicking on the view/edit option. Once you have made the change, click on the save button on the top.

Once the remainder of the following steps are completed you will be able to access the OHIF viewer on a device connected to the same virtual network.

Complete the configuration of the application created earlier

• Go back to browser tab with the AAD application created earlier (or reopen if necessary).
• Add a redirect URI to the OHIF viewer callback url to pass the token the web app.
  • Under Configure platforms, select the Web tile.
  • Specify the redirect URI to https://%cdnEndpoint%/callback.
  • Select "Access tokens" and "ID tokens" flow.
  • 

Note: If you receive a Need admin approval (as below), ensure you have green check in the Status column of of the Configured Permissions of your application. (See Register an application with Microsoft Identity platform section above.) In some organizations, this may require a separate, and potentially manual, process for approval.

Test the installation

• Browse to the cdnEndpoint to access OHIF viewer for non-private link DICOM service.
• For private link enabled DICOM service, browse to the storageAccountWebEndpoint to access OHIF viewer with useSharedAccessBuffer: 'FALSE' set in \Storageaccount$web\app-config.js.
• By default, upload is enabled by default. If you want to disable upload, you can do so by setting dicomUploadEnabled: false in \Storageaccount$web\app-config.js.

You can do additional Domain and CDN configurations as need.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

dicom-ohif's Issues

Study not loading properly in viewer

Hello,
We have deployed ohifv3 on Azure Storage and the nginx server using Kubernetes. We deployed on nginx to resolve COEP headers requirements concerning ohif.

Images are not loading in the left pane which shows all studies. Has any encountered this issue for Azure DICOM service.

Error in console : 204 No Content for following request

empty response for request: XMLHttpRequest {url: 'https://XYZ.dicom.azurehealthcareapis.com/v1/studies?00100020=*MRNID*&limit=101&offset=0&fuzzymatching=true&includefield=00081030%2C00080060', readyState: 4, timeout: 0, withCredentials: false, onreadystatechange:

Request does not match the redirect URIs

Hello,

I followed the step by step tutorial in the README.md and I keep getting the following error. I added the callback URL to the app Authentication but it did not work.

I also followed this article and added the /silent.html callback but no success.

Any suggestion on how to solve this?

Kind regards,
Luís

error in openid connector / e.profile is undefined

For some reason I cant get the ohif to work using the instructions given here. My console output is attached. It seems to hang on the code where some e.profile isnt defined.

Thanks in advance for suggestions or comments!

Deploy to Azure script not working

There are few issues encountered when using Deploy To azure script

• relative path in JS files do not account for ohif path where deployment script uploads all files in storage account
• all the variables in app_config.js that need replacing like wado_root, %tenant_id% or %client_id% are not replaced by script and load fails
  @smithago

I can get automaticaly to the first page, i always get the callback url

When I browse the storage web endpoint, my browser show the call back with the token in the URL, I then have to change the url to the endpoint so I can access the viewer.

Getting "The requested content does not exist"

After following the deployment instructions, when I go to the storageAccountWebEndpoint I get the following error message:

The requested content does not exist.
HttpStatusCode: 404
ErrorCode: WebContentNotFound
RequestId : df3d7499-801e-001f-580c-60d1f0000000
TimeStamp : 2023-03-26T17:56:56.9824319Z

I'd appreciate any help into what I might be doing wrong during the deployment.

Has anyone been able to fix the callback URI issue?

OHIF viewer issue with cornerstoneWADOImageLoader v4.1.0 and above

Synopsis

OHIF viewer doesn't accept responses from Azure Dicom Service for WADO GET requests. As per spec, the main response should be multipart.

multipart/related; type=application/dicom; boundary={MessageBoundary}
(ref: https://dicom.nema.org/dicom/2013/output/chtml/part18/sect_6.5.html)

Powershell code snippet

$session = New-Object Microsoft.PowerShell.Commands.WebRequestSession $session.UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 Edg/109.0.1518.61" Invoke-WebRequest -UseBasicParsing -Uri "https://ohifintegration-xx.dicom.azurehealthcareapis.com/v1/studies/1.2.826.0.1.3680043.8.498.13230779778012324449356534479549187420/series/1.2.826.0.1.3680043.8.498.77033797676425927098669402985243398207/instances/1.2.826.0.1.3680043.8.498.13273713909719068980354078852867170114/frames/1"
-WebSession $session -Headers @{ "authority"="ohifintegration-xx.dicom.azurehealthcareapis.com" "method"="GET" "path"="/v1/studies/1.2.826.0.1.3680043.8.498.13230779778012324449356534479549187420/series/1.2.826.0.1.3680043.8.498.77033797676425927098669402985243398207/instances/1.2.826.0.1.3680043.8.498.13273713909719068980354078852867170114/frames/1" "scheme"="https" "accept"="multipart/related; type="application/octet-stream"; transfer-syntax=*" "accept-encoding"="gzip, deflate, br" "accept-language"="en-US,en;q=0.9" "authorization"="Bearer xx" "origin"="https://mlioihfintegration01.z19.web.core.windows.net" "referer"="https://mlioihfintegration01.z19.web.core.windows.net/" "sec-ch-ua"=""Not_A Brand";v="99", "Microsoft Edge";v="109", "Chromium";v="109"" "sec-ch-ua-mobile"="?0" "sec-ch-ua-platform"=""Windows"" "sec-fetch-dest"="empty" "sec-fetch-mode"="cors" "sec-fetch-site"="cross-site" } | Select -ExpandProperty Headers

Analysis

The above snipet with "accept"="multipart/related; type="application/octet-stream"; transfer-syntax=*" will return,
Content-Type: multipart/related; boundary=38426a24-c3ad-471a-8c89-c5d9210e3eaa

This is acceptable by OHIF since the loader looks for the multipart/related in the header of the response.

However with "accept"="multipart/related; type=application/octet-stream; transfer-syntax=*" will return,
Content-Type: application/dicom; transfer-syntax=1.2.840.10008.1.2.1

This is not acceptable by OHIF since the loader looks for the multipart/related in the header of the response.

The acceptable request is generated by cornerstoneWADOImageLoader v4.1.0 in OHIF and v4.1.1 or above will produce the unaccepted header format.

Note

• cornerstonejs/cornerstoneWADOImageLoader@37b076d, is the change log of cornerstoneWADOImageLoader between v4.1.0 and v4.1.1
• Any "xx" in the snippet was part of the obfuscation of private content.