microsoft / dicom-server

OSS Implementation of DICOMweb standard

Medical Imaging Server for DICOM

Important

📢 After more than 3 years, our team is planning to archive the DICOM server project to allow us to focus on delivering customer value to our managed service offering on Azure. We plan to archive the DICOM server project on April 30, 2024

Learn more in our recent discussion post

The Medical Imaging Server for DICOM is an open source DICOM server that is easily deployed on Azure. It allows standards-based communication with any DICOMweb™ enabled systems, and injects DICOM metadata into a FHIR server to create a holistic view of patient data. The Medical Imaging Server for DICOM integrates tightly with the FHIR Server for Azure enabling healthcare professionals, ISVs, and medical device vendors to create new and innovative solutions. FHIR is becoming an important standard for clinical data and provides extensibility to support integration of other types of data directly, or through references. By using the Medical Imaging Server for DICOM, organizations can store references to imaging data in FHIR and enable queries across clinical and imaging datasets.

The Medical Imaging Server for DICOM is a .NET Core implementation of DICOMweb™. DICOMweb™ is the DICOM Standard for web-based medical imaging. Details of our conformance to the standard can be found in our Conformance Statement.

Managed service

Azure Health Data Service DICOM service is a managed service and recommended for production deployment.

Only the Nuget libraries released from this repo are meant to be used in production. Review maintainance guide if you want to manage your own deployment from this repo.

Deploy the Medical Imaging Server for DICOM

The Medical Imaging Server for DICOM is designed to run on Azure. However, for development and test environments it can be deployed locally as a set of Docker containers to speed up development.

Deploy to Azure

If you already have an Azure subscription, deploy the Medical Imaging Server for DICOM directly to Azure:

To sync your Medical Imaging Server for DICOM metadata directly into a FHIR server, deploy DICOM Cast (alongside a FHIR OSS Server and Medical Imaging Server for DICOM) via:

For a complete set of instructions for how to deploy the Medical Imaging Server for DICOM to Azure, refer to the Quickstart Deploy to Azure .

Deploy locally

Follow the Development Setup Instructions to deploy a local copy of the Medical Imaging Server for DICOM. Be aware that this deployment leverages the Azurite container which emulates the Azure Storage API, and should not be used in production.

Note that the webapp library, ARM templates and Web.Zip package are for testing purposes only, they are not recommended for production scenarios. These will not be versioned. You can find the artifact feed generated by the Medical Imaging Server for DICOM at the Azure Devops Public Feed, including the versioned packages.

Quickstarts

• Deploy Medical Imaging Server for DICOM via Azure
• Deploy Medical Imaging Server for DICOM via Docker
• Set up DICOM Cast

Tutorials

• Use the Medical Imaging Server for DICOM APIs
• Use DICOMweb™ Standard APIs with C#
• Use DICOMweb™ Standard APIs with Python
• Use DICOMweb™ Standard APIs with cURL

How-to guides

• Configure Medical Imaging Server for DICOM server settings
• Enable Authentication and retrieve an OAuth token
• Enable Authorization
• Pull Changes from Medical Imaging Server for DICOM with Change Feed
• Sync DICOM metadata to FHIR
• Extended Query Tags

Concepts

• DICOM
• Change Feed
• DICOM Cast

Resources

• FAQ
• Conformance Statement
• Health Check API
• Performance Guidance
• Api Versions

Development

• Setup
• Code Organization
• Naming Guidelines
• Exception handling
• Tests
• Identity Server Authentication
• Roles
• API Versioning (developer)

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.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., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

There are many other ways to contribute to Medical Imaging Server for DICOM.

• Submit bugs and help us verify fixes as they are checked in.
• Review the source code changes.
• Engage with Medical Imaging Server for DICOM users and developers on StackOverflow.
• Join the #dicomonazure discussion on Twitter.
• Contribute bug fixes.

See Contributing to Medical Imaging Server for DICOM for more information.

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.

dicom-server's Issues

OHIF Viewer V3 suppoet

Hi Team,
we are working on the latest OHIF Viewer , looks like frame get call having error 406 (Request type not accepted ) becuase contact type is plain text.

Enhance attribute matching rules to get better and fine grained query results

User story
As a user of DICOMweb, I want to use better attribute matching rules during my queries so that I can get fine grained query results.

Acceptance criteria
Example for such a query match key with wildcard match (*,?):
(0008,1090) ManufacturerModelName = "Device*"

When I do the following example request (value has been url encoded):
https:\\<dicomweb-url>\series?ManufacturerModelName=Device%2A

then I get back results which contains the following values in ManufacturerModelName:
"Device A"
"Device B"

Rationale
DICOMweb standard states the following about attribute matching. source

"The matching semantics for each attribute are determined by the types of matching allowed by C-FIND."

The C-FIND attribute matching rules can be found here.

As a consequence the DICOMweb standard also allows to use these attribute matching rules and could be used to get better query results. These matching rules could at least be supported for default set of searchable attributes where the value representation allows it.

the issue #1369 is reappearing

Describe the bug
Hello @wsugarman , @jovinson-ms
The issue closed in #1369 is reappearing.

To Reproduce
Steps to reproduce the behavior:

1. Install VS2022 preview SxS to VS2022 stable
2. This will install .Net 5, 6.0.302 and 6.0.400 preview as shown in below
3. 
4. Buildng the solution generates the error -
   #0 0.509 Could not execute because the application was not found or a compatible .NET SDK is not installed.
   #0 0.509 Possible reasons for this include:
   #0 0.509 * You intended to execute a .NET program:
   #0 0.509 The application 'build' does not exist.
   #0 0.509 * You intended to execute a .NET SDK command:
   #0 0.509 A compatible installed .NET SDK for global.json version [6.0.302] from [/dicom-server/global.json] was not found.
   #0 0.509 Install the [6.0.302] .NET SDK or update [/dicom-server/global.json] with an installed .NET SDK:
   #0 0.509 6.0.301 [/usr/share/dotnet/sdk]

Expected behavior
Build should finish successfully

Actual behavior
Build fails with error
#0 0.509 Could not execute because the application was not found or a compatible .NET SDK is not installed.
#0 0.509 Possible reasons for this include:
#0 0.509 * You intended to execute a .NET program:
#0 0.509 The application 'build' does not exist.
#0 0.509 * You intended to execute a .NET SDK command:
#0 0.509 A compatible installed .NET SDK for global.json version [6.0.302] from [/dicom-server/global.json] was not found.
#0 0.509 Install the [6.0.302] .NET SDK or update [/dicom-server/global.json] with an installed .NET SDK:
#0 0.509 6.0.301 [/usr/share/dotnet/sdk]

Your help will be appreciated.

Missing StudyInstanceUID in DCM file metadata results in 409

Describe the bug
An unexpected a HTTP response code happens when a DCM file is inserted into DICOM server that doesn't have StudyInstanceUI.

To Reproduce
Steps to reproduce the behavior:

1. Clear out a StudyInstanceUID using pydicom. The code below shows how to remove the metadata.

ds = pydicom.filereader.dcmread("good.dcm")
.StudyInstanceUID = ''
open("bad.dcm", "wb") as fp:
    ds.save_as(fp, write_like_original=False)

2. Now try to upload. The URL body contains the bad.dcm file.

        headers = {
            "Accept": "application/dicom+json",
            "Authorization": "Bearer " + self._oauth_token,
            "Content-Type": content_type,
        }
        url = f"{self._base_url}/studies"
        self._requests_session = self.get_requests_session()
        response = None
        try:
            response = self._requests_session.post(url, body, headers=headers, verify=False)

3. You can see the 409 status code:

Expected behavior

I would expect an HTTP status code in the 400 range, 400-406.

Standard is here:

http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.5.html

Actual behavior

The HTTP code we did get is a 409 which implies a conflict. Not convinced that it should be a 409.

Open Health Imaging Foundation viewer not displaying the file in the list

Describe the bug
I uploaded a dcm file of cardiomelagy (
dicom_00000001_000.zip
).
In the App Server, in Open Health Imaging Foundation viewer, I don't this in the list. Tried changing the dates range to 12/31/9999 as the image Study Date says 12-Dec-99.
But if I add the StudyInstanceUID at the end of the URL, it works.

To Reproduce
Steps to reproduce the behavior:

1. Upload the attached dcm file
2. Open DICOM App Service, check if the file shows in the list
3. Add the StudyInstanceUID to the App Service URL

Expected behavior
Expected the file to show up in the list when I change the end date to 12/31/9999.

Actual behavior
The file did not show up in the list.

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Application cannot start if SqlAdminPassword contains '@' character

When deploying through Azure Portal using the template, the application will fail to start and return an HTTP Error 500.30 if the SQL Admin Password provided during deployment contains the '@' character. This is likely due to the SqlConnectionStringBuilder trying to treat that as a keyword and replace it with the suitable value.

To recreate the bug, I used a password ending with '@' and that generated the aforementioned error.

Please add a comment indicating restricted character usage when typing the SQL Admin Password.

Incorrect conformance statement

dicom-server/docs/resources/conformance-statement.md

The conformance statement linked above states that for Queries (search), the Accept header should be equal to application/dicom+json, however when searching anything under /studies, ie: /studies/0.0.0, the Accept header must actually be set to: multipart/related; type="application/dicom"

Deploying DICOM Cast without AppInsights fails

Describe the bug
When using the parameter to not create app insights, when deploying DICOM-Cast, the deployement fails

To Reproduce
Steps to reproduce the behavior:

1. Try to deploy DICOM Cast thru ARM
2. Set the parameter for Create App Insights to false.

Expected behavior
The solution is deployed.

Actual behavior
Deployment fails with error:

{
"deploymentStatusCode": -1,
"stage": 6,
"expected": true,
"error": {
"message": "Deployment template validation failed: 'The template resource 'Microsoft.ContainerInstance/containerGroups/dicom-cast-xxxxxx' reference to 'Microsoft.Insights/components/AppInsights-dicom-cast-xxxxxx' requires an API version. Please see https://aka.ms/arm-template for usage details.'."
},
"subscriptionId": "xxxxxxxxxxxxxxxx",
"resourceGroupName": "dicom-cast",
"resourceGroupLocation": "eastus",
"deploymentName": "Microsoft.Template-20201113162042",
"details": {
"code": "InvalidTemplate",
"message": "Deployment template validation failed: 'The template resource 'Microsoft.ContainerInstance/containerGroups/dicom-cast-xxxxxx' reference to 'Microsoft.Insights/components/AppInsights-dicom-cast-xxxxxx' requires an API version. Please see https://aka.ms/arm-template for usage details.'.",
"additionalInfo": [
{
"type": "TemplateViolation",
"info": {
"lineNumber": 0,
"linePosition": 0,
"path": ""
}
}
]
}
}

How to add studies to the deployed dicom server and where should be stored?

When I deploy the template, I get an empty worklist. I couldn't find a way to add studies.

Fuzzy matching search (QIDO-RS) with dash in the patient's name

Describe the bug
Query result could be misleading in case of fuzzy matching enabled and the patient's name contains a dash.
It could mislead the user in a sense that the user expects a result, but the query does not return any results.

An example patient name

Atkinson - Lloyd^Alex

To Reproduce
Steps to reproduce the behavior:

1. Store a patient with patient name "Atkinson - Lloyd^Alex" (without the quotes)
2. Issue a query like this: /studies?PatientName=Atkinson - Lloyd&FuzzyMatching=true

Expected behavior
Query should return back the Atkinson - Lloyd^Alex

Actual behavior
Result set is empty.

Extend fuzzy matching capabilities of QIDO-RS

User story
As a user, I want search on specific component of a component group (even in phonetic or ideographic group) of the whole patient's name with fuzzy matching enabled so that get better and a narrowed down result set.

Acceptance criteria
Let's suppose there are two different patients in the database.
They have the "Harrison" string in common, however in their different name component (family name and given name):

1. George^Harrison=dzsordzs^herizon
2. Harrison^Ford

When I do
studies?PatientName=Harris^&FuzzyMatching=true
then
only George Harrison is returned in the result set.

and/or

When I do
studies?PatientName=^Harris&FuzzyMatching=true
then
only Harrison Ford is returned in the result set.

and/or

When I do
studies?PatientName==heri&FuzzyMatching=true
then
only George Harrison is returned in the result set.

Pay attention to the equal sign which could mean that the search need to be performed in the ideographic group.
If there were two equal signs it would mean that the search need to be performed in the phonetic group. However these could be combined together.

Question: Plans for standalone packages?

While this project is mainly for Azure deployments, I can see that the code is structured in such a way that there are parts that are completely Azure agnostic. Are there any plans of releasing such parts, for example, the Dicom.Core or Dicom.Client as official standalone NuGet packages?

I think that a stable and well functioning DICOMweb client library for .NET would be valuable for many that are not yet considering using the full blown project for example.

Publish the DicomWebClient package in Nuget

User story
As a DICOM Developer, I want to be able do use the DicomWebClient library to access the server so that I don't have to write the code for that.

Acceptance criteria

1. When I do dotnet package add Microsoft.Health.Dicom.Client, then the package is downloaded.

Sample ARM template uses a deploy package from CI output instead of a versioned artifact

Describe the bug
The provided sample ARM template to deploy the DICOMweb server is currently using a URL for the deployment package which is not versioned and seems to be the output of the build result of the "master" branch pipeline.

File location:
https://github.com/microsoft/dicom-server/blob/master/samples/templates/default-azuredeploy.json

(Current) line number: 180

Content:
"defaultDeployPackageUrl": "https://dcmcistorage.blob.core.windows.net/cibuild/Microsoft.Health.Dicom.Web.zip",

If you do not want to build the project from source this make the DICOMweb server currently an unpinned dependency (essentialy a "snapshot" or "latest" type dependency). This means that we can not be sure what will be the content of our deployments depending on this product at any time, revert back or update in a controlled manner.

To Reproduce
Steps to reproduce the behavior:

1. Deploy using ARM template
2. Wait for DICOMweb server master pipeline to run or run it manually
3. Deployment contents of DICOMweb server will now change if you deploy again

Expected behavior

• I expect a versioned deploy package to be available under a well known URL. (Github artifact would be my preference, other options: Azure DevOps artifact, blob storage would be ok too).

Examples for current latest tag; Microsoft.Health.Dicom.Web-1.0.0-master-20201015-1.zip

Also expected behavior: The content of zip file is immutable - will never change again.

Actual behavior

• The content of https://dcmcistorage.blob.core.windows.net/cibuild/Microsoft.Health.Dicom.Web.zip changes with every build of the ci pipeline run for the DICOMweb server

No Javascript sample documentation

User story
We should add sample documentation that is cross platform (frontend & node) on how to call DicomWeb Apis and handle login.

Add SOP Class UID to ChangeFeedEntry

User story
As a consumer of the change feed, I would like to process or discard a received instance according to its SOP Class.

Currently, this can be done by retrieving all the meta-data and extracting the SOP Class from it. However, adding SOP Class to the ChargeFeedEntry itself would mean that the feed could then be used without the meta-data fetch, leading to improved performance.

Although extension of ChangeFeedEntry should not be done lightly, I think processing decisions based upon SOP Class UID would be a common usage scenario.

In our scenario, for example, we want to ignore all CT Image instances (or any other image), and process only RT Structure Set, RT Plan, and RT Dose instances (so just 2 or 3 instances per 200-or-so instance study in this case).

Acceptance criteria

1. SopClassUid is available as a string attribute in each returned ChangeFeedEntry.

Support more date formats in QIDO-RS range matches

User story
Support more dates in QIDO-RS range matches

We attempted to query the studies prior 2021-01-15 with the following:
'/studies?limit=200&fuzzymatching=true&00080020=-20210115'

However it was rejected with the following error:
'Invalid QIDO-RS query. Specified Date value '' is invalid for parameter 'StudyDate'. Date should be valid and formatted as yyyyMMdd.'

However the notation - is actually valid: DICOM standard on QIDO matching (part 18 section 6.7.1..2.1:
The matching semantics for each attribute are determined by the types of matching allowed by C-FIND (see Section C.2.2.2 in PS3.4 ).

And part 4, section C.2.2.2.4 (Range Matching) :

In the absence of extended negotiation, if the Attribute is a date, then:

• A string of the form " - ", where is less or equal to , shall match all occurrences of dates that fall between and inclusive
• A string of the form "- " shall match all occurrences of dates prior to and including
• A string of the form " -" shall match all occurrences of and subsequent dates

Acceptance criteria
Support below scenarios
• A string of the form "- " shall match all occurrences of dates prior to and including
• A string of the form " -" shall match all occurrences of and subsequent dates

Client-side encryption capabilities with KeyVault integration

User story
Reading through the currently available documentation, it is not clear if there is any encryption mechanism provided that is suitable for handling PHI. In order to use this promising backend service we would need some client-side encryption mechanisms for the AzureBlobStorage as well as for the SQL Server.

For the Blob-Storage the Standard encryption with KeyVault integration that is available within the dotnet-stack would be sufficient
https://docs.microsoft.com/en-us/azure/storage/common/storage-client-side-encryption?tabs=dotnet

For the database-side using SQL Always Encrypted would be the preferred way of handling PHI.
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15

Are there any plans to integrate this into this project?

Wrong media type for Retrieve Instance transaction

Describe the bug
The Retrieve Instance transaction of the DICOMweb service uses the wrong media type. It should be multipart/related; type="application/dicom" instead of application/dicom. See DICOM Correction Proposal 2040 for clarification.

Build fails with the update as of Mar 8th commit in main

Describe the bug
local build of the OSS repo is failing with the following errors -

Severity Code Description Project File Line Suppression State Detail Description
Error CA1802 Field 'DicomServerBlobConfigurationSectionName' is declared as 'readonly' but is initialized with a constant value. Mark this field as 'const' instead. Microsoft.Health.Dicom.Blob {local path|\dicom-server\src\Microsoft.Health.Dicom.Blob\Registration\DicomServerBuilderBlobRegistrationExtensions.cs 23 Active A field is declared static and read-only (Shared and ReadOnly in Visual Basic), and is initialized by using a value that is computable at compile time. Because the value that is assigned to the targeted field is computable at compile time, change the declaration to a const (Const in Visual Basic) field so that the value is computed at compile time instead of at run?time.

Your help will be appreciated. Thank you.

To Reproduce
Steps to reproduce the behavior:

1. Update the repo the commit point - bd33cf2 - Refactor Project Files (#606)
2. Build the solution using VS 16.9.0
3. Observer all the errors as outlined in the first screenshot

Expected behavior
Solution Build resulting in no errors

Actual behavior
See the attached screenshot above.

Link to DICOM Web is broken; Deploy to Azure button logos broken

Describe the bug
The link to DICOM Web is outdated in the README.md file

To Reproduce
Steps to reproduce the behavior:

1. Clicking on the DICOMWeb link results in 404

Expected behavior
Link should work

Actual behavior
Results in 404

VS Build fails with the error - Cannot launch container because the following port(s) are already in use: 63839

Describe the bug
Local docker image building via docker compose is failing within VS 2022 (VS 17.1.2) | Win 11 Pro 64 OS Build 22581.1.0

To Reproduce
Steps to reproduce the behavior:

1. Update repot to the commit point - f2389fc - Bump AspNetPackageVersion from 5.0.14 to 5.0.15
2. Open Dicom API solution in VS 2022 17.1.2
3. Run and validate the output of dotnet --list-sdks in the package manager console
   PM> dotnet --list-sdks
   5.0.406 [C:\Program Files\dotnet\sdk]
   6.0.201 [C:\Program Files\dotnet\sdk]
   6.0.300-preview.22154.4 [C:\Program Files\dotnet\sdk]
   PM>
4. Rebuild all solution

Expected behavior
Build to be successful with Docker images and containers created in the Docker for Desktop v4.6.1

Actual behavior
Attached below is the console output. Docker images didn't get build and corresponding containers are not running.
This error persisted in both scenarios -

1. when the Docker Desktop was running and
2. when it was shut down and then it was started when I opened the solution in Visual Studio

========== Pulling Images ==========
Pulling missing Docker images. To cancel this download, close the command prompt window. To disable image auto-pull, see Tools > Options > Container Tools.
docker pull mcr.microsoft.com/dotnet/aspnet:6.0.3-alpine3.14@sha256:f37ba7086c2ee0a71db3f7a51130b81602767611c190365df8c5c370d449346a
docker pull completed
========== Preparing Containers ==========
Getting Docker containers ready...
docker-compose -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.dependencies.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.vs.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\obj\Docker\docker-compose.vs.debug.g.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.vs.debug.yml" -p Dicom --ansi never build
#1 [dicom_sql internal] load build definition from Dockerfile
#1 transferring dockerfile: 32B done
#1 DONE 0.0s
#2 [microsofthealthdicomweb:dev internal] load build definition from Dockerfile
#2 transferring dockerfile: 1.59kB done
#2 DONE 0.0s
#3 [microsofthealthdicomfunctions internal] load build definition from Dockerfile
#3 transferring dockerfile: 1.77kB done
#3 DONE 0.1s
#6 [microsofthealthdicomweb:dev internal] load .dockerignore
#6 transferring context: 35B done
#6 DONE 0.1s
#5 [microsofthealthdicomfunctions internal] load .dockerignore
#5 transferring context: 35B done
#5 DONE 0.1s
#4 [dicom_sql internal] load .dockerignore
#4 transferring context: 35B done
#4 DONE 0.1s
#7 [dicom_sql internal] load metadata for docker.io/library/ubuntu:20.04@sha256:bea6d19168bbfd6af8d77c2cc3c572114eb5d113e6f422573c93cb605a0e2ffb
#7 DONE 0.0s
#13 [microsofthealthdicomweb:dev internal] load metadata for mcr.microsoft.com/dotnet/aspnet:6.0.3-alpine3.14@sha256:f37ba7086c2ee0a71db3f7a51130b81602767611c190365df8c5c370d449346a
#13 DONE 0.0s
#14 [microsofthealthdicomweb:dev runtime 1/2] FROM mcr.microsoft.com/dotnet/aspnet:6.0.3-alpine3.14@sha256:f37ba7086c2ee0a71db3f7a51130b81602767611c190365df8c5c370d449346a
#14 DONE 0.0s
#8 [dicom_sql 1/2] FROM docker.io/library/ubuntu:20.04@sha256:bea6d19168bbfd6af8d77c2cc3c572114eb5d113e6f422573c93cb605a0e2ffb
#8 DONE 0.0s
#9 [dicom_sql 2/2] RUN export DEBIAN_FRONTEND=noninteractive && apt-get update && apt-get install -yq curl apt-transport-https gnupg && curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - && curl https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list | tee /etc/apt/sources.list.d/mssql-server.list && apt-get update && apt-get install -y mssql-server && apt-get install -y mssql-server-fts && apt-get clean && rm -rf /var/lib/apt/lists
#9 CACHED
#15 [microsofthealthdicomweb:dev runtime 2/2] RUN set -x && apk add --no-cache icu-libs && addgroup nonroot && adduser -S -D -H -s /sbin/nologin -G nonroot -g nonroot nonroot
#15 CACHED
#10 [microsofthealthdicomweb:dev] exporting to image
#10 exporting layers done
#10 writing image sha256:91288bba9a74f1bb321a010032d8eb04bf6e3e87d2a84e28d3f94163581faa1e 0.0s done
#10 naming to docker.io/library/dicom_sql done
#10 writing image sha256:69d8e57d0e52f526248ff4ac87546e790c2bfe08ff8aa530841598256e51f390 done
#10 naming to docker.io/library/microsofthealthdicomweb:dev done
#10 DONE 0.0s
#11 [microsofthealthdicomfunctions internal] load metadata for mcr.microsoft.com/dotnet/sdk:6.0.201-alpine3.14@sha256:c1a73b72c02e7b837e9a93030d545bc4181193e1bab1033364ed2d00986d78ff
#11 DONE 0.2s
#12 [microsofthealthdicomfunctions internal] load metadata for mcr.microsoft.com/azure-functions/dotnet:4-slim@sha256:8adc35bc166c711e0cb945aecce2776c7884f7c7a903b16b219b6b2df6aadce9
#12 DONE 0.2s
#20 [microsofthealthdicomfunctions build 1/5] FROM mcr.microsoft.com/dotnet/sdk:6.0.201-alpine3.14@sha256:c1a73b72c02e7b837e9a93030d545bc4181193e1bab1033364ed2d00986d78ff
#20 DONE 0.0s
#16 [microsofthealthdicomfunctions az-func-runtime 1/3] FROM mcr.microsoft.com/azure-functions/dotnet:4-slim@sha256:8adc35bc166c711e0cb945aecce2776c7884f7c7a903b16b219b6b2df6aadce9
#16 DONE 0.0s
#22 [microsofthealthdicomfunctions internal] load build context
#22 transferring context: 1.47MB 0.1s done
#22 DONE 0.1s
#23 [microsofthealthdicomfunctions build 3/5] COPY . .
#23 CACHED
#19 [microsofthealthdicomfunctions dicom-az-func 1/2] WORKDIR /home/site/wwwroot
#19 CACHED
#17 [microsofthealthdicomfunctions az-func-runtime 2/3] RUN groupadd nonroot && useradd -r -M -s /sbin/nologin -g nonroot -c nonroot nonroot
#17 CACHED
#18 [microsofthealthdicomfunctions az-func-runtime 3/3] RUN chown -R nonroot:nonroot /azure-functions-host
#18 CACHED
#25 [microsofthealthdicomfunctions build 5/5] RUN dotnet build "Microsoft.Health.Dicom.Functions.App.csproj" -c Debug
#25 CACHED
#26 [microsofthealthdicomfunctions publish 1/1] RUN dotnet publish "Microsoft.Health.Dicom.Functions.App.csproj" -c Debug --no-build -o /home/site/wwwroot
#26 CACHED
#21 [microsofthealthdicomfunctions build 2/5] WORKDIR /dicom-server
#21 CACHED
#24 [microsofthealthdicomfunctions build 4/5] WORKDIR /dicom-server/src/Microsoft.Health.Dicom.Functions.App
#24 CACHED
#27 [microsofthealthdicomfunctions dicom-az-func 2/2] COPY --from=publish /home/site/wwwroot .
#27 CACHED
#10 [microsofthealthdicomfunctions] exporting to image
#10 exporting layers done
#10 writing image sha256:23c522e18765b96553b25f8a1d19a29cfd1ec76137864a83d104cbe92cff6b8f done
#10 naming to docker.io/library/microsofthealthdicomfunctions done
#10 DONE 0.0s
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --format {{.ID}};{{.Names}}
docker-compose -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.dependencies.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.vs.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\obj\Docker\docker-compose.vs.debug.g.yml" -f "D:\Dev\GitHub\Microsoft\dicom-server\docker\docker-compose.vs.debug.yml" -p Dicom --ansi never up -d --no-build
invalid service "sql". Must specify either image or build
A non-critical error occurred while getting containers ready. Your project will continue to function normally. The error was: Cannot launch container because the following port(s) are already in use: 63839

OHIF Azure Active Directory

I've setup the dicom-server with azure active directory to authenticate requests but... I haven't found any documentation on how to configure OHIF to authenticate with azure active directory. I know this is more of an issue with OHIF, but it's a key piece to getting this up and running with my org. This is my current config.

            oidc: [
            {
              // ~ REQUIRED
              // Authorization Server URL
              authority: 'https://login.microsoftonline.com/<tenant>',
              client_id: '<clientId,
              redirect_uri: 'https://<site>.azurewebsites.net',
              response_type: 'code', // "Authorization Code Flow"
              scope: 'openid profile <custom scope>', // email profile openid
              // ~ OPTIONAL
              automaticSilentRenew: true,
            }
          ]

Existing deployment breaking with latest deployment with asp.net core 5.0.2

Describe the bug
If I deploy the diacom-server to an existing instance using the latest ARM Template , that upgrades the asp.net core runtime to 5.0.2 and processor to 64bit, I am getting error "HTTP Error 503. The service is unavailable.".
If I manually remove the exiting asp.net core runtime 3.1.X, it works.
How to make it touchless deployment?

To Reproduce
Steps to reproduce the behavior:

1. Use the latest ARM Template
2. Access the site : https://dicom-websitename.azurewebsites.net.

Expected behavior
Default Page Or HTTP ERROR 404 - If Authentication/Authorization configured.
When I access the health API /api/dicom/health - should get response as {"Status" : "Healthy"}

Actual behavior
When I access the health API /api/dicom/health - getting the following error

QIDO-RS. Required matching attributes

DICOMweb standard has a statement for the required matching attributes:
"The origin server shall support the matching Attributes specified in Table 10.6.1-5 for each supported IE Level."

In contrast the conformance statement contains this searchable attributes table, and it seems there are some deficiencies:

• Study Time
• Modalities In Study
• Study ID
• Series Number
• Performed Procedure Step Start Time
• Request Attributes Sequence
  • >Scheduled Procedure Step ID
  • >Requested Procedure ID
• SOP Class UID
• Instance Number

Based on the above some of the mandatory search attributes aren't supported by the server and as a consequence the solution doesn't conform with the standard. Is this assumption right?

Error deleting a dicom study or retrieving a study using REST API

Describe the bug
The application does not respect the HTTP 'Accept' headers in the request. When we provide -H 'accept:multipart/related; type=application/dicom' The application only receives. application/dicom and not the multipart/related part of the header which causes some checks later in the request to fail (the checks enforce both application/dicom as the only supported media type and also expect the multipart/related section.

• The headers are conformat to the spec as specified here
• After debugging, it seems there is a bug with ASP.NET Typed headers as used in \dicom-server\src\Microsoft.Health.Dicom.Api\Extensions\HttpRequestExtensions.cs The call to the method httpRequest.GetTypedHeaders().Accept returns a list of MediaTypeHeaderValue which seems strange, As per the class doc on Microsoft, the class is used for content type and not accept headers. The call to httpRequest.GetTypedHeaders().Accept only returns application/dicom and not the multipart/related section. However, a call to httpRequest.Headers.GetCommaSeparatedValues(HeaderNames.Accept) returns the correct headers.
• Ideally there should be a bug request for ASP.NET to fix how accept headers are handled. or in the meantime, the dicom code can change from the MediaTypeHeaderValue for accept header to a custom implemnted header handler.
• I tried forcing the MediaTypeHeaderValue to accept the correct headler by calling new MediaTypeHeaderValue(new StringSegment(x, 0, x.Length)) where x = "multipart/related; type=application/dicom", but that threw a formatting exception confirming it is not the correct abstraction.

To Reproduce
Steps to reproduce the behavior:

1. Enable the openAPI Spec (optional).
2. Follow the instructions in the README to upload a dicom file using fiddler or postman
3. Try to delete or get that study using the swagger button which correpsonds to
   curl -X 'GET' 'https://localhost:63838/v1/studies/1.2.826.0.1.3680043.8.498.13230779778012324449356534479549187420' -H 'accept:multipart/related; type=application/dicom' -H 'content-type: application/dicom' substitue the study instace id with the apporpiate study instance if of the file you uploaded in step 2.
   You will get an exception:
   "Headers are not supported"

Expected behavior
Successful Response with the study file or an empoty response when deleting the study

Actual behavior
Headers not supported exxeption

Rename master branch to main

Rename master branch to main.
Creating this issue to help notify people that may be taking a dependency on the default branch being named master. Or may be using submodules to reference the master branch.

DICOM Cast URL not working

In this URL: https://github.com/microsoft/dicom-server/blob/master/docs/quickstarts/deploy-dicom-cast.md, this URL for DICOM Cast Concept doesn't work: https://github.com/microsoft/dicom-server/blob/master/docs/docs/concepts/dicom-cast.md

Deploy on privacy environment (VNet) not publish on internet

Hi,
I am trying to deploy this service on Azure with maximum privacy but I don´t know if it is possible to deploy the Dicom-server without use the arm template , because I would like to deploy the resources on Azure with privacy. For example, I would like to configure the security on SQL Azure to allow only connections by private endpoint not public endpoint as now ; I want to deploy the app service (DICOMWEB) with vnet integration and private endpoint, because the actual ARM template creates the app service with one IP in internet. The same with the rest of resources. . Please , anyone could help me with it? thanks.

DICOM cast concept mappings

On the mappings page, you ask if ImagingStudy.modality should be derived from Modality (0008,0060) or Modalities in Study (0008,0061). ImagingStudy.modality is designed to be the equivalent of Modalities in Study. However, (0008,0061) will never appear in an instance; it is generated on-the-fly in a C-FIND response based on the union of the Modality (0008,0060) of the study's series. See C.3.4. Additional Query/Retrieve Attributes . Based on your use of dicom, your mapping is correct.

The comment below the tables about timestamps is slightly misleading. I would suggest the issue isn't storing the information in multiple elements, but in making those elements optional. This is similar to how FHIR allows dates and datetimes to omit less significant digits.

You may find the (incomplete and informative) mappings found in FHIR STU3 ImagingStudy mappings useful.

Connect to existing storage account

Discussed in #1229

^{Originally posted by kenviku December 8, 2021}
Is there a way to connect the DICOM server to an existing storage account where all the DCM files are stored?

Integration of DICOM server with Horos/Osirix or other desktop viewing applications

User story
This product looks like it has a lot of potential. As a imaging scientist wanting to test this in various workflows, I want to be able to test the dicom server with DICOM viewing software such as Horos/Osirix.

Acceptance criteria

1. Would it be possible to provide documentation on this integration in the docs?

Support multiple audiences

Problem

Today, the security configuration allows a single audience for verification of JWT tokens. This audience is expected to be available in the aud claim of the JWT token. The aud claim per the RFC is of the type StringOrUri.

Using AAD v1 endpoints, the audience is passed as a resource parameter and returned in the aud claim. Generally speaking, these often are in the form of a URI that contain a trailing / but can also be a guid.

Using AAD v2 endpoints, the audience is passed as part of a scopes parameter. A default scope is available such that you can pass a scope of https://example.com/.default and the resulting aud claim will be https://example.com. The behavior of AAD is to return everything before the final / as the aud.

User story

As an administrator, I want to support multiple Security.Authentication.Audience so that I can use AAD v1 and v2 easily.

Proposals

Ideally, this change would not result in a breaking change to the service. I currently see three different ways this can be accomplished.

• Update the Security.Authentication.Audience to allow a delimited list of audiences that will be allowed.
• Add a property Security.Authentication.Audiences that will be an array and will take precedence over the Audience property.
• Add a property Security.Authentication.AdditionalAudiences that when present will add additional audiences in addition tot he Audience specified.

Acceptance criteria

1. When I make a request with the aud claim of http://example.com, then the request is allowed.
2. When I make a request with the aud claim of http://example.com/, then the request is allowed.
3. When I make a request with the aud claim of 12345, then the request is allowed.
4. A user can specific 1 or more audiences that will be acceptable to the service.

Support single DICOM file upload

User story
As a user exploring DICOM, I want to easily upload a DICOM file without messing with multipart/related so that I can get started earlier, leverage Postman to experiment with the API, and simplify coding.

Acceptance criteria

1. An API endpoint is available that would support uploading a single DICOM file to the service.
2. The endpoint should not require the use of multipart/related.
3. I should be able to pass the DICOM file as bytes in a POST body.

Azure DICOM Server Template Won't deploy to CanadaCentral

Hi,

I took a stab at deploying the DICOM server using the Azure Portal as per
https://github.com/microsoft/dicom-server/blob/main/docs/quickstarts/deploy-via-azure.md

But I got an error
Deployment template validation failed: ‘The provided value 'canadacentral' for the template parameter 'applicationlnsightsLocation' at line '84' and column ‘30’ is not valid. The parameter value is not part of the allowed value(s): 'southeastasia,northeurope,westeurope,eastus,southcentralus,westus2',', (Code: InvalidTemplate)

Can the template paramter be adjusted to include 'canadacentral' please?

"Bad request" when accessing the dicom server through the deployed OHIF viewer

Describe the bug
We have deployed the project in Azure using the template and we encountered a "Bad request" error when accessing the viewer.

To Reproduce
Steps to reproduce the behavior:

1. Deploy dicom-server in Azure using the provided template with default settings
2. Access to the deployed OHIF viewer using Chrome or Firefox browser.

Expected behavior
The OHIF viewer should display the list of studies

Actual behavior
JS crashes due to a bad request error.

401 error while accessing DICOM API

Hi Team,

I have deployed DICOM imaging server by following the instructions provided in the github. When I access below URL from postman then I am getting 401 unauthorized error. Can you please help me to resolve this issue.

https://test-dicomserver.azurewebsites.net/studies

Assistance with setting up Azure DevOps for DICOM

microsoft/fhir-server#1409

A user had some questions about how to setup running a Azure DevOps server 2020 locally to build few OSS Repos that include Azure FHIR Server & Azure DICOM Server. We gave details on the FHIR OSS in the issue mentioned above but the user has questions about DICOM as well. I'm going to close out the issue on the FHIR Server and let the DICOM items be tracked here.

Thanks!

DICOM web standard in Python Notebook broken

Hi All,

I was just taking a squiz at this repo and as I was "driving by" I saw a few issues, figured I'd flag them so that you can be aware 🙂 .

---

The following notebook:

https://github.com/microsoft/dicom-server/blob/main/docs/resources/use-dicom-web-standard-apis-with-python.ipynb

Gives the following error message:

File Load Error for use-dicom-web-standard-apis-with-python.ipynb
Unreadable Notebook: /home/simon/Downloads/use-dicom-web-standard-apis-with-python.ipynb NotJSONError('Notebook does not appear to be JSON: \'{\\n "cells": [\\n {\\n "cell_type": "m...')

Potentially it might be worth including the notebook examples within the testing suite with something like https://github.com/nteract/testbook?

---

Also, the link to the notebook from the markdown file gives a 404:

https://github.com/microsoft/dicom-server/blame/main/docs/tutorials/use-dicom-web-standard-apis-with-python.md#L3

Cheers 🙂,
Simon

'Writer' role in RBAC roles to limit data exfiltration risk for on-premises uploading applications

We have an on-premises component that uploads DICOM instance to the Azure (and would like to use the DICOM service instead).

In this scenario, we need that component to have the minimum rights possible (certainly not the ability to query, retrieve, or delete any instances, for example). Any of these rights increases the risk that an on-premises breach of escape of the application secret will lead to exfiltration of the customer's data with fully-laden PHI. One the data is in Azure, all our other applications that need to access it are also in Azure and can use RBAC, subnets, etc.

Presumably, the best way to achieve this would be with a 'Writer" role in the RBAC options.

User story
As a user in a lower-security environment, I want my application to only be able to store instances.

Acceptance criteria

1. Application can use STORE route
2. Application cannot query
3. Application cannot delete
4. Application cannot retrieve
5. Application cannot observe changed feed

Response `Content-Type` header should include `transfer-syntax`

Currently, the transfer syntax is missing from the response Content-Type header. If multiple Accept headers are supplied, without transfer syntax in the response Content-Type, the caller wouldn't know which transfer syntax was used. More detail can be found here: http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.7.9.

We'll need to add the transfer syntax to the RetrieveResourceResponse being returned in the core layer.

To Reproduce
Steps to reproduce the behavior:

1. Store an image following these instructions
2. Retrieve the image
3. Inspect the Content-Type header of the response

Expected behavior
The header should include a portion that reads transfer-syntax={value} where {value} is either a valid Transfer Syntax UID or the token *. This value should match the Accept header in the request.

Actual behavior
This portion is not included.

HTTP Error 500.30 - ASP.NET Core app failed to start

Describe the bug
I can not deploy to non-production slot from Azure DevOps to Azure App Service. The deployment was successful in Azure DevOps but when I browser the non-production slot, error message shows that:

HTTP Error 500.30 - ASP.NET Core app failed to start Common solutions to this issue:
The app failed to start
The app started but then stopped
The app started but threw an exception during startup

Here is the error message in the eventlog.xml:

Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.6' was not found.
  - The following frameworks were found:
      2.1.26 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
      2.2.14 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
      3.0.3 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
      3.1.13 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
      5.0.4 at [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

However, when I deploy to production slot it worked fine.
I also installed the extension: ASP.NET Core 5.0 (x64) Runtime version:5.0.6 but still have this issue.
Please help me resolve this issue.

To Reproduce
Steps to reproduce the behavior:

1. Click the "Deploy to Azure" button in github.
2. Create testslot and copy the settings.
3. Deploy to test slot from Azure DevOps with the yaml file in Build folder.
4. Browse test slot in App Service and the receive error message.

Expected behavior
We can deploy this source code to non-production slot.

Actual behavior
Error message shows that: HTTP Error 500.30 - ASP.NET Core app failed to start.

Query Studies with "ModalitiesInStudy" parameter not supported.

Describe the bug
In OHIF viewer when we apply Modality filter /studies API is failing with 400 status code.

To Reproduce
Steps to reproduce the behavior:

1. Enter another modality code in Modality filter of all studies view
2. GET /studies API will fail

Expected behavior
It should show all studies of entered modality

Actual behavior
API fails and Viewer UI crashes.

Support ideographic and phonetic parts in json response

I created a DICOM file and uploaded it to my DICOM Service. I then did a QIDO query at the /studies endpoint

In my DICOM file I set the Patient Name (0010,0010) to "Two^Jimmy^^Mr.^Phd=ideographic=phonetic"

And what came back from the query was:

{
00100010: {
vr: 'PN',
Value: [ {
Alphabetic: 'Two^Jimmy^^Mr.^Phd=ideographic=phonetic'
}
]
}
}

But what I was expecting was:

{
00100010: {
vr: 'PN',
Value: [ {
Alphabetic: 'Two^Jimmy^^Mr.^Phd',
Ideographic: 'ideographic',
Phonetic: 'phonetic'
}
]
}
}

I base this on the DICOM spec part 18, section F.2.2

Each attribute object contains the following named child objects:
• vr: A string encoding the DICOM Value Representation. The mapping between DICOM Value Representations and JSON Value Representations is described in Section F.2.3.
• At most one of:
o Value: An array containing one of:
 The Value Field elements of a DICOM attribute with a VR other than PN, SQ, OB, OD, OF, OL, OV, OW, or UN (described in Section F.2.4)
The encoding of empty Value Field elements is described in Section F.2.5
 The Value Field elements of a DICOM attribute with a VR of PN. The non-empty name components of each element are encoded as a JSON strings with the following names:
• Alphabetic
• Ideographic
• Phonetic


And from part 5, Table 6.2-1

PN:
For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annex H, Annex I and Annex J) may be used. The delimiter for component groups shall be the equals character "=" (3DH).

Docker build on local PC fails against commit d6cf35f - Bump HealthcareSharedPackageVersion

Describe the bug
Local docker image building via docker compose is failing within VS 2022 (VS 17.1.0) | Win 11 Pro 64 OS Build 22557.1

To Reproduce
Steps to reproduce the behavior:

1. Update repot to the commit point - d6cf35f - Bump HealthcareSharedPackageVersion from 4.0.25 to 4.0.26 (#1365)
2. Open Dicom API solution in VS 2022 17.0.1
3. Update sdk version to 6.0.200 in global.json | sdk 6.2.00 was installed during VS 2022 17.0.1 upgrade
4. In terminal run "docker build -f src/microsoft.health.dicom.web/Dockerfile -t microsoft.health.dicom.web ."

Expected behavior
Docker images to be built, deployed in the local docker desktop for windows; after than relevant containers up and running

Actual behavior
Docker compose fails to build the solution.
See below the terminal output

docker build -f src/microsoft.health.dicom.web/Dockerfile -t microsoft.health.dicom.web .
[+] Building 6.1s (13/15)
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 1.59kB 0.0s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 483B 0.0s
=> [internal] load metadata for mcr.microsoft.com/dotnet/sdk:6.0.102-alpine3.14@sha256:8d15f73dcd72485cc89e59cf0fa2e97ef016c4500164dd26b71cea6d532b8134 0.0s
=> [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:6.0.2-alpine3.14@sha256:7f9385ad945d06b35bc93b3d91a2be3e65a921ff0c872f6982b01b27088c4149 0.0s
=> [runtime 1/2] FROM mcr.microsoft.com/dotnet/aspnet:6.0.2-alpine3.14@sha256:7f9385ad945d06b35bc93b3d91a2be3e65a921ff0c872f6982b01b27088c4149 0.0s
=> [internal] load build context 5.4s
=> => transferring context: 33.32MB 5.4s
=> [build 1/5] FROM mcr.microsoft.com/dotnet/sdk:6.0.102-alpine3.14@sha256:8d15f73dcd72485cc89e59cf0fa2e97ef016c4500164dd26b71cea6d532b8134 0.0s
=> CACHED [runtime 2/2] RUN set -x && apk add --no-cache icu-libs && addgroup nonroot && adduser -S -D -H -s /sbin/nologin -G nonroot -g nonroot nonroot 0.0s
=> [dicom-server 1/2] WORKDIR /app 0.1s
=> CACHED [build 2/5] WORKDIR /dicom-server 0.0s
=> CACHED [build 3/5] COPY . . 0.0s
=> [build 4/5] WORKDIR /dicom-server/src/Microsoft.Health.Dicom.Web 0.1s
=> ERROR [build 5/5] RUN dotnet build "Microsoft.Health.Dicom.Web.csproj" -c Release -p:ContinuousIntegrationBuild=false -warnaserror 0.4s => ERROR [build 5/5] RUN dotnet build "Microsoft.Health.Dicom.Web.csproj" -c Release -p:ContinuousIntegrationBuild=false -warnaserror 0.4s

[build 5/5] RUN dotnet build "Microsoft.Health.Dicom.Web.csproj" -c Release -p:ContinuousIntegrationBuild=false -warnaserror:
#13 0.336 Could not execute because the application was not found or a compatible .NET SDK is not installed.
#13 0.336 Possible reasons for this include:
#13 0.336 * You intended to execute a .NET program:
#13 0.336 The application 'build' does not exist.
#13 0.336 * You intended to execute a .NET SDK command:
#13 0.336 A compatible installed .NET SDK for global.json version [6.0.200] from [/dicom-server/global.json] was not found.
#13 0.336 Install the [6.0.200] .NET SDK or update [/dicom-server/global.json] with an installed .NET SDK:
#13 0.336 6.0.102 [/usr/share/dotnet/sdk]

---

executor failed running [/bin/sh -c dotnet build "Microsoft.Health.Dicom.Web.csproj" -c $BUILD_CONFIGURATION -p:ContinuousIntegrationBuild=$CONTINUOUS_INTEGRATION_BUILD -warnaserror]: exit code: 145

Possible to connect Azure DICOM directly to imaging devices?

I would like to set up my own dicom server in Azure and be able to connect directly to my in-office ultrasound for storage of studies. But I cannot identify how that connection will take place. Does it happen through DICOMWeb or other intermediate software? The devices need information such as AT Title and those are not available directly from the Azure Diocom server itself. Please help point me in the right direction to create the connection bridge.

.

HTTP Error 500.30 - ASP.NET Core app failed to start

Describe the bug
I have deployed the last ARM template and I have this error. I deployed the ARM template on January on other azure resources and I didn´t have errors. I am thinking that there is a change on actual code or template that gives this error.

To Reproduce
Steps to reproduce the behavior:

1. Deploy the ARM tempalte on Azure
2. If you run the executable on the console on the web app , you see that the problem is because the framework version doesn´t exist.

** The diffence:
On the before app web service the extension is ASP NT core 3.1
On the last app web service, the extension is ASP NET core 5.0.5

Display half image

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. We have uploaded some Dicom files and it display half image

Expected behavior
A clear and concise description of what you expected to happen.

Actual behavior

A clear and concise description of what actually happened.

Unable to access DICOM Api server after setting up with Docker Compose

Describe the bug
I setup local DICOM server and other components by following instructions from here, every thing starts fine but I can't access the API server. When I go to http://localhost:8080 I get HTTP 404 error(shown below in image)

To Reproduce
Steps to reproduce the behavior:

1. Clone the repo
2. Start the applications using the command env SAPASSWORD='Test@12345' docker-compose -f samples/docker/docker-compose.yaml -p dicom-server up -d
3. Go to http://localhost:8080 to see the web page

Expected behavior
Application supposed to start and accessible from http://localhost:8080

Actual behavior
Webpage is not accessible and shows HTTP 404 error as shown below. However I do see API started in container logs

Hosting environment: Production

Content root path: /app

Now listening on: http://[::]:8080

Application started. Press Ctrl+C to shut down.

Screenshot: