What Are DICOM and PACS? Clinic Imaging Workflow

Every clinic with an imaging device meets two abbreviations sooner or later: DICOM and PACS. Both sound technical, but they answer very concrete questions of the clinical workflow: where does the image leaving the device go, how does the physician see it, which record is the report linked to, how many years is the image stored and how is it transferred to another institution? This article explains DICOM and PACS in the language of the clinic manager and the physician, and describes how an imaging flow is built and what to check when choosing software.

What is DICOM?

DICOM (Digital Imaging and Communications in Medicine) is the international standard defining the format and communication of medical images and the information associated with them. It provides two things:

A file format. An X-ray, CT scan or ultrasound image is not made of pixels alone; it also carries information such as the patient's name, ID, acquisition date, device information, acquisition parameters and a study identifier. DICOM allows this information to be packaged with the image in a standard way.
Rules of communication. Devices, archive systems and viewers talk to each other by set rules: a device sends a study to the archive, a viewer requests a study from the archive, a device learns from a list which patient is to be scanned.

Thanks to this standard, devices and software from different manufacturers can understand the same image. In practice, though, "DICOM supported" does not guarantee every kind of compatibility; the device's conformance statement, which shows which functions it supports, should be reviewed.

What is PACS?

PACS (Picture Archiving and Communication System) is the archive and distribution system where images are stored, managed and viewed. A PACS usually combines three components:

Archive: the repository where studies are stored for the long term.
Distribution: delivering studies to the relevant physician and the reporting screen.
Viewer: the screen where the physician examines images and takes measurements.

The relationship between clinic software and PACS can be set up in two ways: the clinic software can contain its own image archive, or it can connect to an existing PACS the clinic uses. In both cases it is critical that patient identity is consistent across the two systems; an identity mismatch carries the risk of opening the wrong patient's image.

The imaging workflow

An imaging study is a chain from order to report:

Portal10End

Timeline and portal

The report, key image and study are added to the patient timeline and, with an authorized user's approval, published in the patient portal.

The process is complete here.

10 / 20

Clinical / reference viewerPublished

Study 0007
Series 2

Published

Names, times and records on the screen are examples.

All steps

01 Imaging order (Clinic) The physician opens the order: clinical reason, body site, exam type and priority. Contrast and allergy checks are made if needed.
02 Accession and worklist (Planning) The order receives an accession number, is tied to an appointment and room, and appears on the device worklist.
03 Arrived and started (Modality) The patient has arrived, the device selects the patient from the list and the exam begins.
04 Exam completed (Modality) The device reports the exam is finished; a technical quality check is made. If inadequate, a repeat exposure.
05 Transfer and technical check (Archive) The image is transferred to the archive; count, integrity and format are checked.
06 Patient and order matching (Archive) The image header is compared with the patient and order identity. If it matches it enters the reading queue.
07 Reading queue (Reporting) The study waits in the reading queue by specialist assignment and priority.
08 Draft and final report (Reporting) The report is written from a template, kept as a draft, signed and made final. The system on which the primary interpretation was made is recorded.
09 Critical-finding notification (Reporting) If there is a critical finding, the ordering physician is notified; an acknowledgement is awaited and escalated if absent.
10 Timeline and portal (Portal) The report, key image and study are added to the patient timeline and, with an authorized user's approval, published in the patient portal.

Alternative path from 04 Exam completed; it returns to the main flow at 03 Arrived and started.

04a Repeat exposure (Modality) If quality is inadequate or there was movement, the exam is repeated; the rejection reason is recorded and the exam starts again.

Alternative path from 06 Patient and order matching; it returns to the main flow at 07 Reading queue.

06a Quarantine: header did not match (Archive) The patient or order identity does not match, or the image is a duplicate or late. The image goes to quarantine; no automatic matching is made.
06b Human review (Archive) An authorized user matches the image to the right patient and order or rejects it; the decision is recorded and the image enters the reading queue.

Alternative path from 08 Draft and final report; it returns to the main flow at 10 Timeline and portal.

08a Addendum / correction (Reporting) If information must be added to a final report, an addendum is opened; if there is an error, a correction. The previous version is kept and the current version reaches the patient timeline.

Order. The physician creates an imaging order with its rationale, body region, scan type (modality) and urgency.
Acceptance and scheduling. The order gets an accession number; the scan is scheduled. Patient information is sent to the device as a "modality worklist": the technologist selects the patient from the list instead of typing it. This reduces identity mix-ups from typing errors.
The scan. When the patient arrives the scan starts; the device reports when the scan starts and ends.
Transfer. Images are sent to the archive and technically verified: do the patient, the study and the image count match what was expected?
Reporting. The reporting physician examines the images and writes a report. The report is linked to the study and the order.
Physician review and publication. The ordering physician sees the result. The result is published to the patient portal after physician review.

The most frequent problem in this chain is the patient's identity being written differently in different places. Using a worklist largely reduces this problem.

Patient identity and the risk of mismatch

Imaging is one of the areas where an identity error is most expensive. Linking an ultrasound image to another patient's file creates a serious clinical and legal problem. To reduce this risk:

Patient information should come with the worklist rather than being typed into the device.
The accession number should be used as the single identifier of a study.
Automatic verification after transfer should compare the expected study with the arriving study.
In case of a mismatch, the study should drop into a review queue instead of automatically linking to a patient.
Correcting a patient-image match later should be a traceable operation.

The bridge between the clinic network and the cloud

Imaging devices are generally on the clinic's local network. If you use cloud-based clinic software, a secure bridge is needed between the device and the cloud. This bridge runs inside the clinic; it talks to the device over DICOM, places images in an encrypted local queue and, when the internet connection allows, forwards them to the cloud in order. If the connection drops, images are not lost; they wait. The connection is made only from the clinic outward; no new entrance into the clinic network is opened from outside. In HekimBis this role is taken by the Edge Connector; see the Edge Connector and DICOM and PACS integration pages.

Storage, deletion and transfer

Images are large files and storage has a cost. The retention period depends on the type of the facility and the relevant legislation; guessing or generalizing it would not be right. In a good system each data class has a versioned retention policy: at the end of the period approved archiving or destruction applies and these operations are recorded with evidence. If there is a legal retention requirement or a dispute under way, deletion is suspended (legal hold). When images need to be transferred to another institution, export in a standard format and patient consent or a legal basis are needed. For the general principle of the data life cycle see our KVKK and health data guide.

Beyond DICOM: laboratory is a different world

While DICOM is used for imaging, laboratory devices and information systems mostly work with another messaging standard. Order, specimen, result and validation steps build a separate workflow, and for critical values the physician's acknowledgement is awaited. If the same clinic has both imaging and laboratory, bringing the two flows together on a single timeline in the patient record shortens the physician's decision time. For the laboratory side see the laboratory and LIS feature; this article's focus is only imaging.

The viewer: reference or diagnostic?

It helps to know which use a viewer is offered for. A physician seeing an image next to them during an examination, taking measurements or showing it to the patient is "clinical and reference" use. A viewer that a radiologist will use as the primary reporting workstation may require much higher requirements (display quality, advanced processing, calibration). A software should state clearly which of these two uses it offers its viewer for. HekimBis offers its viewer for clinical and reference use: seeing an image during an examination, measuring it and showing it to the patient.

Getting started: practical steps

If you are a new organization in DICOM and PACS, a practical order is:

Device inventory. Which devices are there, what are their brands and models, which support DICOM? Collect the conformance statement for each device.
Network plan. Decide which network the devices are on, where a bridge computer will run and how internet access will be provided.
Identity rule. Set a single rule for how patient identity will be written in the device, the archive and the clinic software.
Trial study. Without a real patient, run a study with test data from order to report; try error cases too (wrong identity, dropped connection).
Retention policy. Put in writing how long images will be kept, under what condition, and the conditions for deletion.
Training. Give technologists a short training on worklist use and physicians on the viewer and report screen.

The most commonly skipped step in this order is the identity rule in number three. In systems installed without an identity rule, problems like "an image dropped onto another patient" and "a study that cannot be found" are frequent in the first months.

What does "integrated" mean for a device?

For a device to count as integrated with software, three things must be verified: the device's manufacturer and model, the communication protocol used and its version. Unless these (manufacturer, model, protocol, version) are verified together, the word "supported" is not reliable. For unverified devices manual import (uploading images as files) is one route, but it should be clearly labeled "not integrated." The list of supported devices in HekimBis consists of verified devices, and this distinction is kept on the device connections page.

Questions to ask when choosing software

Was the conformance statement of my devices reviewed? Which functions (worklist, storage, status reporting) are supported?
Can patient information be passed to the device by worklist?
How is patient identity matched across the two systems, and what happens on a mismatch?
Where is the archive, and who controls the images?
Is image loss experienced when the internet is cut?
Is the image retention and destruction policy versioned and evidenced?
For what use is the viewer offered?
If I have an existing PACS, can it be connected?
Are the report, image and order linked together?
Who can access the images and under what condition; is access logged?

Which setup for which organization?

In a small practice with a single ultrasound device, the DICOM connection is often no more than adding the device's image to the patient record. In a diagnostic center with many modalities (X-ray, ultrasound, CT, MRI) and a reporting workflow, the worklist, accession number and reporting queue become indispensable. In multi-branch structures, connecting the branches' devices to a central archive and shared reporting comes up. For the clinical side of the workflow see the imaging and PACS feature, for business scale the diagnostic center solution, and for the specialty side the radiology page.

Conclusion

The DICOM standard determines how an image and its information are packaged, and PACS how they are stored and distributed. What matters most clinically is that the chain from order to report is protected against identity errors, resilient to outages and tied to a recorded retention policy. For the general approach to device connection, you can also look at the device connections page.

What Are DICOM and PACS? An Introduction to Clinic Imaging Workflow