Kastoria Health v0.9.1 Release Notes
About this release
Kastoria Health v0.9.1 is the first release of Kastoria Health, the control plane for medical imaging. It provides DICOMweb ingestion, query and retrieval over versioned, content-addressed storage; scheduled study processing; event notifications carrying each study's Ingestion Manifest; SMART on FHIR launch from an EHR into a web viewer; an Admin Console; and OpenTelemetry-based monitoring.
The architecture and features are described in the Kastoria Health System Overview. These notes summarize what the release contains, the standards and platform it supports, and behavior to be aware of.
Audience
These notes are intended for CIOs, CTOs, security reviewers, enterprise architects, and senior developers evaluating, deploying, or integrating Kastoria Health.
Highlights
- Kastoria Core data plane. All data is stored immutably, content-addressed by SHA-256 and versioned, with a complete, hash-linked history of every study.
- DICOMweb. STOW-RS ingestion with lossless HTJ2K compression, QIDO-RS study and series search, and WADO-RS retrieval of studies, series, instances, frames, metadata, rendered images and thumbnails, with on-the-fly transcoding.
- Study processing. Stored studies are indexed for search and assigned FHIR Patient and ImagingStudy ids, with automatic retry of transient failures and operator-requested reprocessing.
- Event notification. A Notification Event carrying the study's Ingestion Manifest is published to an Azure Storage Queue each time a study is processed, with at-least-once delivery and re-publishing from a point in time.
- SMART on FHIR launch. Clinicians open a study from their EHR in the web viewer using SMART App Launch v2.2, with study-scoped access for the viewer.
- Admin Console. EHR launch configuration, Content Explorer, ingestion error log, processing and event monitoring, reprocessing, and a Changelog browser.
- Telemetry and monitoring. Traces and metrics from every service through OpenTelemetry, with Grafana dashboards.
What is included
Container images
| Image | Description |
|---|---|
| kastoria-proxy | Gateway: the single entry point that routes requests to every service. |
| kastoria-proxy-mtls | Mutual-TLS gateway that grants each client certificate access to specific services. |
| kastoria-health | DICOMweb service: STOW-RS ingestion, QIDO-RS query and WADO-RS retrieval. |
| kastoria-studyprocessor | Scheduled job that processes stored studies for query and retrieval. |
| kastoria-eventnotification | Scheduled job that publishes Notification Events to a queue. |
| kastoria-smart-launch-api | SMART on FHIR EHR launch service. |
| kastoria-ohif | Web viewer, built on the open-source OHIF Viewer. |
| kastoria-consoleapi | Admin Console API. |
| kastoria-consoleui | Admin Console web application. |
Every image is signed and carries SLSA provenance and a software bill of materials (SBOM). Images run as non-privileged users and are released only with no known critical or high severity vulnerabilities.
Deployment modules
Signed OpenTofu modules for deploying Kastoria Health on Azure: networking, secrets, object store, file store, queue, compute, gateway and telemetry, together with a sample deployment configuration.
Grafana dashboards
Services Overview, DICOMweb Performance, Admin Console Performance and Performance Test dashboards.
Supported standards
| Standard | Support |
|---|---|
| DICOMweb (DICOM PS3.18) | STOW-RS, QIDO-RS and WADO-RS, as detailed in the DICOM Conformance Statement. |
| SMART App Launch v2.2 | EHR launch, with PKCE. |
| OpenTelemetry | Traces and metrics exported over OTLP. |
Platform requirements
Kastoria Health v0.9.1 is deployable on Microsoft Azure, in the customer's own environment. It uses:
- Azure Container Apps, for services and scheduled jobs;
- Azure Storage (Blob and Table), for Kastoria Core;
- Azure Storage Queue, for Notification Events;
- Azure Key Vault, for secrets;
- Azure managed identities and Microsoft Entra ID, for access to all of the above; and
- Azure Monitor (Log Analytics), for logs.
Grafana dashboards require a Grafana instance, such as Grafana Cloud.
Behavior to be aware of
- Studies are available once processed. A newly stored study can be searched and retrieved, and its Notification Event is published, only after a scheduled processing run has processed it. The delay depends on the schedule configured for the deployment.
- Images are compressed on ingestion. Images from modalities such as CT, MR, CR, DX and MG are stored in HTJ2K lossless format unless compression is turned off for the request.
- Every store creates a new study version. Each STOW-RS request for a study creates a new version of it and causes it to be processed again.
- One FHIR Patient per Patient ID. Kastoria Health records one FHIR Patient resource for each DICOM Patient ID. When several studies share a Patient ID, the Patient reflects the most recently processed study. A study with no Patient ID has no Patient resource.
- DICOM identifiers are assumed unique. This release assumes Study Instance UIDs and Patient IDs are unique across the data it ingests. Data should be validated before it is migrated to Kastoria Health.