DICOM and DICOMweb — imaging attached to the cycle it belongs to

Imaging is the part of the cycle that usually goes missing

An IVF cycle generates imaging continuously. Follicular and endometrial ultrasound drives every monitoring decision, and the embryology laboratory produces images of its own. In most clinics those images stay where they were made: on the ultrasound machine, on a departmental workstation, or in a hospital PACS that the fertility record cannot reach. The clinical note then says what the clinician saw, but the image that justified it is a separate search away, and often unfindable a year later during audit.

Two ways in, both standards-based

DICOM is the universal standard for medical imaging; DICOMweb is its RESTful face. FertiliCore supports both entry routes. Modern modalities and PACS can push studies with STOW-RS over HTTP. Older equipment that only speaks classic DICOM can push to a C-STORE receiver, which binds only when an application entity port is configured. The connector can also work the other way round, querying an external PACS at a configured DICOMweb base URL rather than acting as the receiver.

• STOW-RS store, over DICOMweb
• QIDO-RS query across studies, series and instances
• WADO-RS retrieve of images and metadata
• C-STORE receive for classic-DICOM-only modalities

Where the pixels actually go

Imaging is large, and putting it in a relational database is a well-known way to make backups impossible. FertiliCore stores pixel data in object storage and keeps only the DICOM metadata and the storage key in the database. Studies, series and instances are reconciled by their Study, Series and SOP Instance unique identifiers through the identifier crosswalk, so a modality that re-sends a study updates the existing record instead of creating a second copy. A study and series browser in the application lets clinical staff find imaging without leaving the record.

Linking a study to the right clinical record

A stored study is of limited use until it is attached to something. The connector reads the modality and patient identifier from the incoming instances and maps them to the relevant clinical target — an ultrasound scan or an embryo image — then calls the clinical application's own imaging-link endpoint. As with every FertiliCore connector, the integration service never writes clinical tables directly, so the link goes through the same validation and audit path as any other clinical record. The default mapping policy is sensible for the common cases; a per-connector override for unusual modality configurations is a documented seam rather than a shipped feature.

The shared backbone

Every store, query and link is recorded with direction, type, external reference, payload and status, so a missing image can be traced to the message that should have carried it. The identifier crosswalk prevents duplicate studies and duplicate patients. Outbound deliveries run through a reliable queue with retry, claim-locking and an operator screen. Everything is tenant-scoped, and connector credentials are stored encrypted and never returned in plaintext by the administration API.