Skip to content

Kastoria Health v0.10.0 Release Notes

About this release

Kastoria Health v0.10.0 builds on v0.9.1 with broader DICOMweb support, faster and more memory-efficient image retrieval, and better fidelity for the data customers send us.

These notes summarize what has changed since v0.9.1 and the behavior to be aware of when upgrading. The full technical detail of DICOMweb support is in the DICOM Conformance Statement.

Audience

These notes are intended for CIOs, CTOs, security reviewers, enterprise architects, and senior developers evaluating, deploying, or integrating Kastoria Health.

Highlights

  • Search for individual images. Viewers and integrations can now search for the instances within a study or series, completing QIDO-RS search at the study, series and instance levels.
  • Zoom into a region of an image. Rendered images can now be cropped to a region of interest on the server, rather than the whole image being sent and cropped by the client.
  • Much faster retrieval of large images. Large instances begin downloading in milliseconds rather than seconds, and the service's memory use no longer grows with the size of the image being retrieved.
  • More legacy data accepted. Images from older archives that use Big Endian or Deflated encodings can now be stored and retrieved.
  • Complete images returned. Data that appears after the pixel data in an image file is now kept and returned on retrieval.

What is new

DICOMweb

  • Instance-level search. Two new QIDO-RS searches return the instances in a study, or in a series, filtered by SOP Instance UID, Instance Number or Series Instance UID. Each result carries the standard minimum set of instance attributes, so a viewer can list a series' images without retrieving them.
  • Rendered image cropping. The rendered image endpoints now honor the crop coordinates of the viewport parameter, returning just the requested region of the image, scaled to the requested size.
  • Big Endian and Deflated images. Images sent in the Explicit VR Big Endian or Deflated Explicit VR Little Endian encodings are converted, losslessly, to the standard Explicit VR Little Endian encoding when they are stored. Previously these images were accepted but could not be retrieved correctly.
  • Data after the pixel data is preserved. Some images carry data elements after the pixel data. These were previously dropped on retrieval; they are now stored and returned with the image.

Performance

  • Streaming retrieval. Instances, series and studies are now streamed to the client as they are read, instead of being assembled in memory first. For a 1 GB instance, the first bytes arrive in about 15 milliseconds instead of 1.5 seconds, and peak server memory falls from over 5 GB to under 400 MB.
  • Streaming conversion. When a client asks for compressed images (JPEG-LS, JPEG Lossless, JPEG 2000 or HTJ2K) in uncompressed form, they are now converted and sent one frame at a time. Peak memory for these requests is up to 20 times lower, and the first bytes arrive in milliseconds rather than seconds.

Reliability

  • No silently missed updates. Study processing and Event Notification learn of new data from the change history Kastoria Core keeps. If a change is saved but its entry in that history cannot be recorded, the service now retries, and reports a failure if it cannot recover, rather than reporting success. This prevents a stored change from being missed by processing and notifications.

Security

  • Fix for CVE-2026-101916. This release resolves CVE-2026-101916, a High severity certificate verification vulnerability in the gRPC library used to send telemetry. It affected the kastoria-health, kastoria-studyprocessor, kastoria-eventnotification, kastoria-consoleapi and kastoria-smart-launch-api images. The library is used only to forward metrics to the local OpenTelemetry collector, which is already secured by mutual TLS within the Azure Container Apps environment, so we do not consider the vulnerability exploitable in Kastoria Health deployments.
  • Fix for CVE-2026-93990. This release resolves CVE-2026-93990, a High severity vulnerability in the Expat XML parsing library, which is installed with the NGINX web server. Expat versions before 2.8.5 accept malformed UTF-16 encoded XML. It affected the kastoria-proxy, kastoria-proxy-mtls, kastoria-consoleui and kastoria-ohif images. These images use NGINX only to route requests and serve web application files; they do not parse XML, so we do not consider the vulnerability exploitable in Kastoria Health deployments.
  • Limits on rendered image size. Requests for very large rendered images or thumbnails are now refused, closing a route by which a single request could exhaust the service's memory and affect other users.

Changes to the DICOM Conformance Statement

The DICOM Conformance Statement has been updated for this release:

Area Change
Search (QIDO-RS) Added search for instances in a study and in a series, with their supported search parameters and default response attributes.
Rendered images Viewport crop coordinates are now supported. Removed from the list of current limitations; the remaining limitation is that empty and negative crop values are refused.
Rendered images and thumbnails Documented the maximum viewport area: 16,777,216 pixels (for example 4096 × 4096) for rendered images, and 1,048,576 pixels (for example 1024 × 1024) for thumbnails.
Store (STOW-RS) Documented that Big Endian and Deflated images are converted to Explicit VR Little Endian on ingest, even when ingest-time transcoding is turned off.
Transfer syntaxes Added Deflated Explicit VR Little Endian as accepted on ingest. Big Endian remains available as a retrieval format; Deflated is not offered as one.

Behavior to be aware of

  • Big Endian and Deflated images are stored in a different encoding. Their content, including pixel data, is preserved exactly, but the stored data is Explicit VR Little Endian, so it is not byte-for-byte identical to the file that was sent.
  • Oversized image requests are refused. A rendered image request larger than 16,777,216 pixels, or a thumbnail request larger than 1,048,576 pixels, now returns 400 (Bad Request). Viewers should request images at display size.
  • Reprocessing always produces an update. Reprocessing a study now always creates a new version of it, even when nothing has changed, and Event Notification announces it as updated. Integrations that consume Notification Events should expect these events when reprocessing.