Preserve Study Instance UIDs from Trusted DICOM Sources
Overview
OmegaAI treats a DICOM Station as a trusted source of study identity. When a study receives images from an authoritative station, that station's Study Instance UID (0020,000D) becomes canonical, replacing OmegaAI's placeholder UID. Superseded UIDs are retained for backward compatibility.
The Problem
When an HL7 order arrives before imaging, OmegaAI generates a placeholder Study Instance UID. Later, the imaging source sends objects with its own UID. During ingestion, OmegaAI matches by accession number and stores images under the placeholder UID, discarding the source's identifier silently.
Result: Annotations and reports sent back carry an unfamiliar UID
the source cannot match. Example: CSH sends UID
1.2.826.0.1.3680043... but OmegaAI stores as 1.2.124.113540....
Return annotations don't reconcile at CSH.
How It Works
Authoritative OFF (Old Behavior):
-
HL7 order creates study with placeholder UID
-
Imaging sources send objects with their own UID
-
OmegaAI matches by accession number
-
Source UID is discarded silently, no warning
Authoritative ON (New Behavior):
-
HL7 order creates study with placeholder UID
-
Imaging sources send objects with their own UID
-
OmegaAI matches by accession number
-
Source UID is adopted as canonical identifier.
-
Placeholder UID is recorded in merged -UID reference table
-
C-STORE Warning (0xB000) is returned to sender.
-
Object records Original Attributes Sequence (0400,0561) with original UID, modification datetime, modifying system, and COERCE reason code
-
Study remains discoverable by any historical UID through QIDO-RS, WADO-RS, C-FIND, C-MOVE
When This Setting Takes Effect
This Setting only takes effect when a study was created by an HL7 order (placeholder UID) and the DICOM object then matches it by accession. Where studies are created by the DICOM object itself, it never comes into play.
Where to Find the Setting
Location in the Application
Navigate to:
Organization
└─ Device
└─ [Select DICOM Station Device]
└─ Device Details Form
└─ DICOM Station Features
└─ Authoritative ← Toggle here
Availability and Defaults
-
Available on: DICOM Station devices only (not on OmegaAI Link or API devices)
-
Default state: OFF for all stations, including newly created ones
-
Permission: Read-only when the Device form is in view mode; editable in edit mode, the same as every other field in the DICOM Station Features group. No separate permission applies to this field.
-
Additional notes:
-
This is a DICOM Station setting, not a connection setting. Ingest reads the receiving station by AE Title, so each station is ticked separately.
-
The UI is not a safety boundary — a FHIR PUT /Device sets the value whether or not the switch is visible.
-
-
Programmatic access: Can be queried and set through the FHIR Device API (device.extension[where(url='authoritative')].valueBoolean)
DICOM Compliance
- C-STORE Warning (0xB000): Returned when Study Instance UID is coerced (per DICOM PS3.4 §B.4)
- Original Attributes Sequence (0400,0561): Object records original UID, modification datetime, modifying system, and COERCE reason (per DICOM PS3.3 §C.12.1.1.9)
Configuration Example
CSH Compass PACS (bidirectional): Organization > Device > CSH Compass PACS > DICOM Station Features > Toggle Authoritative ON. Compass UIDs now canonical; returned annotations carry original UID.
Ultrasound Modality (unidirectional): Leave Authoritative OFF. OmegaAI uses order-generated UID; no conflicts on re-sends.
| Enable For | Disable For |
|---|---|
| DICOM Gateways, enterprise PACS with stable UIDs | |
| Bidirectional workflows (annotations/reports sent back) | Sources with unstable or ad-hoc identifiers |
| Sources with reliable, never-regenerated UIDs | Sources with UIDs that aren't globally unique.(Reusing one UID across different Studies mis-identifies studies) |
Not Needed For
| Scenario | Details |
|---|---|
| Unidirectional workflows (studies flow only into OmegaAI) | There's no risk, just no benefit. |
Recommendation
The setting defaults to OFF for all new stations. Enable it explicitly only for sources you have tested and validated as stable and authoritative.
Benefits
1. Bidirectional Reconciliation -- Annotations match at source automatically.
2. No Information Loss -- All superseded UIDs remain resolvable
3. Transparency and Auditability -- C-STORE Warning and Original Attributes Sequence audit changes
4. Per-Station -- One gateway can be authoritative without affecting others
5. Safe by Default -- OFF by default; no behavior changes on upgrade.
Troubleshooting
Annotations don't match at source - Verify Authoritative enabled. Check OmegaAI Link logs. Query source UID in Global Search.
C-STORE Warning not received - Verify Authoritative is enabled - Check source PACS supports warning responses (legacy systems may suppress) - Verify warning in OmegaAI ingestion logs
Historical UIDs not searchable - Verify Authoritative is enabled on device - Query historical UID in Global Search - Contact RamSoft Support if unresolved