What a PACS is made ofthe building blocks, in the order a study meets them
A PACS is not one program. It is a handful of parts that each do one job: take in orders, hand out the worklist, receive images, keep them, index them, send them on and show them. Follow one study through them and each part makes sense.
- DICOM
- Internal action
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
The interface brings in patients and orders
Core stepWhat happens
The hospital systems tell the PACS about patients and orders in HL7 messages: registrations and changes of patient data (ADT) and imaging orders (ORM, or OMG and OMI in newer HL7 versions). The PACS stores them, so each study can be matched to a patient and an order when the images arrive.
Why it is needed
Without this link a study arrives with only what the technologist typed. With it, the images are filed under the right patient and accession number from the start.
Technical details
- HL7 v2 over TCP, usually through an interface engine
- ADT: patient registrations, merges and updates
- ORM^O01 (or OMG^O19 and OMI^O23 in newer HL7 versions): the imaging order and the scheduled procedure, with the accession number
- The RIS often sits in between and is the source of the orders
The worklist tells the scanner who to scan
Core stepWhat happens
The scanner asks which patients are scheduled for it, with a DICOM C-FIND on the Modality Worklist. The answer comes from a worklist service. In some sites that is the RIS, in others the PACS or a separate broker.
Why it is needed
The technologist selects the patient from a list instead of typing the name, so the order data lands in the images without typing errors.
Technical details
- Modality Worklist FIND 1.2.840.10008.5.1.4.31
- Matching on station AE title, modality and date
- Returns patient, accession number and Study Instance UID
- See the worklist lesson for the full exchange
The storage service receives the images
Core stepWhat happens
The scanner sends the images to the PACS over DICOM. The part of the PACS that listens for them is the storage service (the Storage SCP). It has an AE title, an IP address and a port, and it only accepts images from the scanners that are configured on it.
Why it is needed
This is the front door. Anything that cannot get through it, such as a wrong AE title, a closed port or an unsupported SOP Class, never reaches the rest of the PACS.
Technical details
- DICOM C-STORE, one request per image
- The storage AE title, IP and port are set on the modality
- The PACS accepts or refuses each SOP Class and transfer syntax
- See the C-STORE lesson for the exchange
The archive keeps the files
Core stepWhat happens
The PACS writes each image to its archive as a DICOM file, with the pixel data and all the header attributes. Recent studies are usually on fast disks, because that is what readers ask for most.
Why it is needed
The archive is the part that must never lose anything. Its size, speed and protection decide how long studies stay quickly available.
Technical details
- Files on disk or in an object store, often in a folder structure by date or study
- Images may be kept as received or compressed to save space
- Capacity planning is mostly about this part
The database makes them findable
Core stepWhat happens
The PACS copies the key header attributes into its database: the patient, the study with its accession number, the series and the image, together with where the file is. When someone searches, the database answers. The pixel data stays in the archive.
Why it is needed
Searching the files directly would be far too slow. The database is why a query for one patient returns in a moment, and why a study that is in the archive but not in the database cannot be found.
Technical details
- Typically PatientID (0010,0020), AccessionNumber (0008,0050), StudyInstanceUID (0020,000D)
- Series and image UIDs, modality, study date, number of images
- A pointer from each record to the file in the archive
- Patient merges and corrections are changes in this part
Routing rules send copies on
Key detailWhat happens
Most PACS have a workflow engine with rules, such as "send every CT of this department to that workstation", "forward cardiology studies to the cardiology system" or "when a study is scheduled, fetch the patient's priors". It sends copies using C-STORE, or asks other systems to do so.
Why it is needed
This is what puts the right images in front of the right reader before they ask. A rule that stops working is a classic reason for "my study never arrived".
Technical details
- Rules on modality, body part, AE title, department or time of day
- Forwarding is a C-STORE from the PACS to another AE
- Prefetch means copying older studies into fast storage
- Tag changes (morphing) can be applied on the way
A copy goes to long-term storage
Key detailWhat happens
The PACS makes at least one more copy: a backup, a second site, or a vendor neutral archive (VNA) that keeps images in standard DICOM for years. Old studies can then leave the fast disks and still be retrieved.
Why it is needed
Studies must be kept for many years, often by law, and a single copy on one disk system is a risk. This part is also what makes migrating to a new PACS possible.
Technical details
- Retention is set by policy: years, until a patient age, or forever
- Storage commitment (N-ACTION) can confirm that a copy is safe
- A VNA keeps images in standard DICOM so a new PACS can use them
- Restores from this tier are slower than from the fast archive
The viewer asks for the study
Core stepWhat happens
A radiologist opens a study from a reading worklist or searches for a patient. The viewer queries the PACS, with a DICOM C-FIND or, in web viewers, with the DICOM web search service (QIDO-RS), and the database answers.
Why it is needed
The reading worklist is the radiologist's to-do list. It is built from this query plus the status of each study, which is why it needs the database to be up to date.
Technical details
- Study Root Q/R FIND 1.2.840.10008.5.1.4.1.2.2.1
- QIDO-RS is the same kind of search over HTTP
- Typical keys: PatientID, accession number, date, modality
- See the C-FIND lesson for the exchange
The images reach the viewer
ConfirmationWhat happens
The viewer retrieves the study. With C-MOVE the PACS sends the images to the viewer's own AE with C-STORE; with C-GET they come back on the same connection; with DICOM web (WADO-RS) the viewer fetches them over HTTP. The PACS reads the files from the archive, or brings them back from long-term storage first.
Why it is needed
This is the point of the whole chain: the reader sees the images. How quickly they appear depends on every part before it: where the study is stored, how it is compressed and how the viewer retrieves.
Technical details
- C-MOVE: the viewer's AE title, IP and port must be known to the PACS
- C-GET: same connection, no inbound port needed
- WADO-RS: HTTP(S), often used by web viewers
- See the C-MOVE lesson for the exchange
All steps at a glance
Glossary
- PACS
- Picture Archiving and Communication System. The set of systems that receives, stores, finds and shows medical images.
- Modality
- A device that makes images, such as a CT scanner, an MRI, an X-ray room or an ultrasound.
- Archive
- The storage where the DICOM files are kept. Often fast disks for recent studies and cheaper storage for older ones.
- PACS database
- The index of what is in the archive: patients, studies, series and images, with a pointer to each file. It is what makes queries fast.
- Viewer
- The application where a radiologist or clinician looks at the images. It can be a workstation program or a web page.
- RIS
- Radiology Information System. It holds the radiology orders and schedule, and often the reports.
- VNA
- Vendor Neutral Archive. A long-term archive that stores images in standard DICOM so that more than one PACS or viewer can use them.
- HL7 v2
- The standard for text messages between hospital systems, such as patient registrations (ADT) and orders (ORM, or OMG and OMI in newer HL7 versions).
Summary
- A PACS is a set of cooperating parts, not one program. The standard defines the services between them, not how they are built inside.
- The usual parts are: an HL7 interface, a worklist service, a DICOM storage service, the archive, the database, a routing engine, long-term storage and a viewer.
- The archive holds the files. The database holds the index. A study that is in the archive but not in the database cannot be found.
- Between the parts, DICOM carries the images and queries (
C-STORE,C-FIND,C-MOVE,C-GET, the Modality Worklist) and HL7 carries patients and orders. - A product's Conformance Statement has a table that maps its services to its Application Entities. It shows which part does what, and with which AE title, in your PACS.
The 9 steps in plain text
The interface brings in patients and orders
The hospital systems tell the PACS about patients and orders in HL7 messages: registrations and changes of patient data (ADT) and imaging orders (ORM, or OMG and OMI in newer HL7 versions). The PACS stores them, so each study can be matched to a patient and an order when the images arrive.
Why: Without this link a study arrives with only what the technologist typed. With it, the images are filed under the right patient and accession number from the start.
The worklist tells the scanner who to scan
The scanner asks which patients are scheduled for it, with a DICOM C-FIND on the Modality Worklist. The answer comes from a worklist service. In some sites that is the RIS, in others the PACS or a separate broker.
Why: The technologist selects the patient from a list instead of typing the name, so the order data lands in the images without typing errors.
The storage service receives the images
The scanner sends the images to the PACS over DICOM. The part of the PACS that listens for them is the storage service (the Storage SCP). It has an AE title, an IP address and a port, and it only accepts images from the scanners that are configured on it.
Why: This is the front door. Anything that cannot get through it, such as a wrong AE title, a closed port or an unsupported SOP Class, never reaches the rest of the PACS.
The archive keeps the files
The PACS writes each image to its archive as a DICOM file, with the pixel data and all the header attributes. Recent studies are usually on fast disks, because that is what readers ask for most.
Why: The archive is the part that must never lose anything. Its size, speed and protection decide how long studies stay quickly available.
The database makes them findable
The PACS copies the key header attributes into its database: the patient, the study with its accession number, the series and the image, together with where the file is. When someone searches, the database answers. The pixel data stays in the archive.
Why: Searching the files directly would be far too slow. The database is why a query for one patient returns in a moment, and why a study that is in the archive but not in the database cannot be found.
Routing rules send copies on
Most PACS have a workflow engine with rules, such as "send every CT of this department to that workstation", "forward cardiology studies to the cardiology system" or "when a study is scheduled, fetch the patient's priors". It sends copies using C-STORE, or asks other systems to do so.
Why: This is what puts the right images in front of the right reader before they ask. A rule that stops working is a classic reason for "my study never arrived".
A copy goes to long-term storage
The PACS makes at least one more copy: a backup, a second site, or a vendor neutral archive (VNA) that keeps images in standard DICOM for years. Old studies can then leave the fast disks and still be retrieved.
Why: Studies must be kept for many years, often by law, and a single copy on one disk system is a risk. This part is also what makes migrating to a new PACS possible.
The viewer asks for the study
A radiologist opens a study from a reading worklist or searches for a patient. The viewer queries the PACS, with a DICOM C-FIND or, in web viewers, with the DICOM web search service (QIDO-RS), and the database answers.
Why: The reading worklist is the radiologist's to-do list. It is built from this query plus the status of each study, which is why it needs the database to be up to date.
The images reach the viewer
The viewer retrieves the study. With C-MOVE the PACS sends the images to the viewer's own AE with C-STORE; with C-GET they come back on the same connection; with DICOM web (WADO-RS) the viewer fetches them over HTTP. The PACS reads the files from the archive, or brings them back from long-term storage first.
Why: This is the point of the whole chain: the reader sees the images. How quickly they appear depends on every part before it: where the study is stored, how it is compressed and how the viewer retrieves.
Common questions
What is a PACS made of?
Usually an HL7 interface for patients and orders, a worklist service for the modalities, a DICOM storage service that receives images, an archive that keeps the files, a database that indexes them, a routing engine, long-term or backup storage, and viewers. Products differ in how they package these parts, but the jobs are the same.
What is the difference between the archive and the database?
The archive stores the DICOM files, including the pixel data. The database stores an index of what is in the archive (patients, studies, series, images) and where each file is. Queries use the database, and retrieval reads the archive. If the two disagree, studies can seem missing or show wrongly.
What is the difference between the modality worklist and the reading worklist?
The modality worklist is a DICOM service that tells a scanner which patients are scheduled, so the technologist can select the patient. The reading worklist is the radiologist's list of studies to report, shown in the viewer or reporting system. They have different jobs and are often provided by different parts.
What is the difference between a PACS, a RIS and an EHR?
The PACS handles images. The RIS handles radiology orders, scheduling and often reports. The EHR holds the patient record for the whole hospital. They exchange HL7 messages (patients, orders, results) and the PACS and modalities exchange DICOM images and queries.
What is a VNA and is it part of a PACS?
A Vendor Neutral Archive is a long-term archive that keeps images in standard DICOM so that several PACS and viewers can use them. It can be part of a PACS setup as its long-term tier, or sit next to several PACS. It is what makes switching PACS vendors much easier.
How do I find out which part does what in my own PACS?
Read the product's DICOM Conformance Statement. Under "Mapping of Services to Application Entities" it lists each Application Entity, the services it provides (Storage, Query/Retrieve, Worklist and so on) and its role. Combine that with the AE titles, IP addresses and ports from the configuration.