Integration
This section documents how to integrate with Kastoria Health beyond its REST APIs: the events Kastoria Health publishes as it ingests imaging studies, and what a consumer needs to receive and apply them.
Ingestion Manifest
Each time Kastoria Health processes a DICOM study, it publishes a Notification Event carrying the study's Ingestion Manifest — the DICOM and resource identifiers needed to map the study between systems. Events are delivered to an Azure Storage Queue in your tenant.
| Topic | Event types | Transport | Documentation |
|---|---|---|---|
study |
created, updated |
Azure Storage Queue | Study Notification Events (Ingestion Manifest) |
Common conventions
- JSON — Every event is one UTF-8 JSON object with camelCase keys;
acronyms are upper case (
studyInstanceUID,patientID). - Forward compatibility — Consumers must ignore keys they do not recognize. There is no schema-version field; an added key is not a breaking change.
- At-least-once delivery — Events can be duplicated and can arrive out of
order. Consumers order them by
eventTime, per study. - Protected health information — Every message contains protected health information (patient name, birth date and identifiers). Handle messages, logs and anything built from them accordingly.
Examples in this section
The pages in this section contain worked examples — event bodies, queue setup commands, and how a consumer applies events that arrive out of order.