Identity and state after the scanner

The scanner can finish an acquisition while the examination is still incomplete as an information-system event. The order may be in one system, the acquired objects in another, the interpretation in a third, and the clinical result in a fourth. A useful first model is therefore not a wiring diagram but a set of functions that must reconcile the same examination.

Functions, not a fixed wiring

An imaging modality produces DICOM objects from an acquisition. A PACS commonly stores, queries, distributes, and presents those objects through a viewer. A vendor-neutral archive may provide a longer-lived or cross-vendor archive role, although a separate VNA is not present in every installation. A radiology information system coordinates scheduling, worklists, reporting, and status. The electronic health record provides the wider clinical context in which an imaging report or discrete measurement may be used. An AI or quantitative service consumes source objects and can produce segmentations, measurements, or findings.

These descriptions name jobs, not mandatory products. PACS and VNA functions may be combined, a RIS may be closely integrated with an EHR, and an AI service may be inside or outside the archive boundary. The practical question is always: which component performs each function, what information does it hold, and how does the next component know that it is handling the same examination?

Identity is not workflow state

The distinction becomes concrete when the examination is followed from order to result. An order establishes a requested procedure and commonly carries an accession number. A modality worklist supplies scheduled patient and procedure information to the modality. The acquired objects then carry patient and study identifiers, including the DICOM UIDs that distinguish a study, its series, and its individual instances. A performed-procedure message can report what was actually done. The archive, report, and clinical record must still reconcile these pieces into one workflow.

The names in that chain are easy to conflate, so use the following as a mental model rather than as a complete account of every implementation:

• PatientID identifies a patient within the relevant issuing domain.
• AccessionNumber identifies the order or procedure context used by the institution’s workflow.
• StudyInstanceUID identifies a DICOM study.
• SeriesInstanceUID identifies a series within that study.
• SOPInstanceUID identifies an individual stored object.

The identifiers do different jobs. A UID can establish which DICOM object is being referenced without proving that the object was associated with the intended order. Conversely, an accession can connect a workflow request to a procedure without being the identity of every object generated by that procedure. Workflow state is also separate from both: ordered, scheduled, acquired, performed, stored, read, reported, and recorded are activities or states that may be represented in different systems. No single value is the entire state machine.

The following figure is a compact teaching model of that distribution. It is not a claim that every site has eight separate products or that every hand-off uses one universal protocol.

Alignment is maintained by service interactions and identifier handling, not guaranteed by the existence of valid pixels. A stale worklist row, a copied value, or a duplicated study can leave an object that is technically well formed but attached to the wrong workflow context. In that conditional failure mode, image quality checks may all pass because the image itself is not corrupted. The error is that the system is asking the image to answer the wrong clinical question, or is about to place its report in the wrong record. A derived measurement inherits the workflow identity of the source study it was given; it cannot repair a mistaken association merely by being numerically accurate.

Crossing the imaging boundary

DICOM is the object vocabulary used by imaging systems, but an examination also participates in the hospital’s broader information fabric. HL7 v2 messages remain important in many integrations, while FHIR provides a structured resource model for a range of clinical workflows and results. A useful conceptual bridge is to think of a request as a ServiceRequest, the content of a DICOM study as an ImagingStudy, an interpretation as a DiagnosticReport, and an atomic finding or measurement as an Observation.

That bridge is deliberately only a mental model. These resources are not a one-to-one translation table for DICOM or HL7 v2. A DICOM Structured Report and a FHIR Observation can both carry measurements while preserving different structures and relationships, and an actual integration follows its applicable profiles and implementation guidance. The durable point is the linkage: an order must be related to the performed study, the report to the study, and a discrete measurement to the result that gives it meaning. A value that remains only in an unlinked object or an interface no clinician reads has not completed the workflow.

This is also where an AI service fits. It may be triggered by a routing rule, retrieve a particular study or series, run an inference, and return a derived object to the imaging environment. That optional path does not replace the ordinary workflow. It adds another set of identity, transport, timing, and provenance hand-offs that must be made explicit.

The next question is how those imaging objects actually travel between the functions. Classic DICOM networking uses DIMSE associations rather than HTTP requests, and its mental model explains many otherwise puzzling failures.