Microsoft.Health.Dicom.Client fails to parse DICOM service metadata when an FL/FD value is Infinity

Question

Microsoft.Health.Dicom.Client fails to parse DICOM service metadata when an FL/FD value is Infinity

Haywood Phillips 0

We use the Azure Health Data Services DICOM service (WADO-RS metadata) with the documented C# client: Microsoft.Health.Dicom.Client 10.0.535 (and Microsoft.Health.FellowOakDicom 10.0.535).

What we are doing

Store a study that includes a Siemens secondary-capture instance with a private FL element whose IEEE value is −Infinity.
Call RetrieveStudyMetadataAsync (GET …/studies/{study}/metadata, application/dicom+json).

What the service returns

The DICOM service itself is fine. The study is present. Metadata HTTP 200. For that FL tag it emits a JSON string because JSON has no numeric infinity:

"00232018": { "vr": "FL", "Value": ["-Infinity", -1] }

Sibling FL values in the same object are normal numbers (for example 100, 64, 48).

What the client does

DicomWebClient throws:

System.Text.Json.JsonException: Malformed DICOM json, number expected

That exception aborts the entire study enumerate. Callers then see instance count 0 even though the service has hundreds of instances.

Why this is valid

FL/FD are binary floats. DICOM JSON normally uses a JSON number. IEEE NaN / +Infinity / −Infinity cannot be a JSON number, so the service correctly writes the strings "NaN", "Infinity", and "-Infinity".

The client’s number parser still requires a JSON number (it already special-cases "NaN" only). A string "-Infinity" is treated as malformed and the whole payload fails.

Minimal repro (no PHI)

Deserialize this as application/dicom+json with DicomWebClient / the client’s DicomJsonConverter:

{

"00720076": {

"vr": "FL",

"Value": ["-Infinity", -1]

}

Expected: two FL values, NegativeInfinity and -1.

Actual: JsonException, number expected.

Same payload with a finite number in place of "-Infinity" parses. Same payload also parses with fo-dicom 5.2.6’s DicomJsonConverter, which accepts "NaN" / "Infinity" / "-Infinity" for FL and FD.

Ask

Please make Microsoft.Health.Dicom.Client accept those three strings for FL/FD on metadata retrieve, matching how the DICOM service already serializes them. A published package that does this (or that uses fo-dicom ≥ 5.2.0 for JSON) would unblock WADO-RS metadata for any study that contains a non-finite float.

Happy to provide a sanitized metadata snippet or a stub HttpMessageHandler repro if useful. No patient identifiers in this report.

0 comments

1 answer

Your answer

Answer 1

Hello @Haywood Phillips

Thanks for the detailed reproduction. Based on the behavior you've documented, this appears to be an issue in Microsoft.Health.Dicom.Client's DICOM JSON deserialization path, rather than with WADO-RS retrieval itself.

The key distinction is that the DICOM service returns the metadata successfully with HTTP 200, but Microsoft.Health.Dicom.Client 10.0.535 subsequently fails while deserializing the FL value:

"Value": ["-Infinity", -1]

The fact that:

replacing "-Infinity" with a finite value succeeds;
the same payload parses successfully with fo-dicom 5.2.6;
and the exception occurs specifically inside the client's JSON parsing;

strongly suggests the client isn't handling all non-finite FL/FD representations the service returns.

Azure Health Data Services exposes DICOM data through the DICOMweb standard APIs, including WADO-RS retrieval, and Microsoft's documented C# approach uses both the DICOM Client and fo-dicom packages.

As a temporary workaround, if feasible in your application, retrieve the metadata using the DICOMweb REST endpoint/HttpClient and deserialize the application/dicom+json payload with a version of fo-dicom whose DicomJsonConverter correctly handles NaN, Infinity, and -Infinity, rather than letting RetrieveStudyMetadataAsync deserialize the response internally.

I don't recommend modifying the source DICOM object just to replace the non-finite value, especially since the service accepts the object and successfully returns its metadata.

Given your minimal repro, I think this is also appropriate to raise as a Microsoft.Health.Dicom.Client bug. When opening the support/engineering issue, include:

Microsoft.Health.Dicom.Client version 10.0.535
Microsoft.Health.FellowOakDicom version 10.0.535
The minimal FL/FD JSON example
The exact JsonException
Confirmation that finite values work
Confirmation that fo-dicom 5.2.6 parses the same payload

Your sanitized HttpMessageHandler reproduction would also be useful because it removes the Azure service from the test path and shows the failure occurs entirely during client-side deserialization.

So, based on the evidence you've provided, I don't see a configuration change on the Azure DICOM service side that would address this. The proper fix is for the Microsoft client to accept the non-finite FL/FD representations the service can return.

References:

Use C# and DICOMweb Standard APIs in Azure Health Data Services

Access DICOMweb APIs to manage DICOM data

Azure Health Data Services DICOM service FAQ

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.

Haywood Phillips 0 Reputation points

2026-09-04T19:24:57.01+00:00

Thanks for the info, it's appreciated.

Where should I open the Microsoft.Health.Dicom.Client support/engineering issue so it actually reaches the team that publishes the package? Azure support ticket on the DICOM service subscription, or a different form?

microsoft/dicom-server looks archived for customer work — they said they no longer take product updates there, and recent PRs on main are not being merged. I do not want to file this in a place nobody ships from.
Allan Solomon Mejia 8,170 Reputation points

2026-09-04T20:04:35.93+00:00

That's a fair question. Given the current state of the microsoft/dicom-server repository, don't rely on filing a GitHub issue there as the primary escalation path.

For this case, I recommend opening an Azure Support request against your Azure Health Data Services/DICOM service resource and asking Support to route/escalate it to the Azure DICOM engineering team responsible for Microsoft.Health.Dicom.Client.

The client is part of the Microsoft DICOM implementation. The Microsoft documentation has pointed to the Microsoft.Health.Dicom.Client source within the DICOM server project. So an Azure support case gives you a supported path to get the problem in front of the owning engineering team, rather than depending on activity in the public repository.

In the support request, make the issue very explicit:

Problem: Microsoft.Health.Dicom.Client 10.0.535 fails to deserialize valid DICOM JSON containing non-finite FL/FD values such as "-Infinity".

Include the details I mentioned above.

Specifically ask Support to escalate this as a client SDK/package defect rather than troubleshoot the DICOM service resource itself, since your isolated reproduction demonstrates that the exception occurs locally during Microsoft.Health.Dicom.Client deserialization.

You can open the request from the Azure portal > Help + support > Create a support request, selecting your Azure Health Data Services/DICOM resource where possible.

Reference: Create an Azure support request

If Support provides a newer package with a fix or identifies a different public engineering tracker for this client, please add that information to this thread as well; it would help others hitting the same parsing issue.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.