Imaging informatics is the discipline that manages medical images and their metadata across the systems that create, store, share and display them: modalities, PACS, vendor neutral archives, viewers and the EHR. It rests on DICOM for the images themselves and on IHE integration profiles for the way systems hand work to each other.
This guide covers the data model and network services DICOM defines, the move to DICOMweb, the IHE profiles worth requiring in an enterprise build, and the difference between a PACS and a VNA. It ends with the failure points that surface during archive migrations and image-sharing projects.
What is imaging informatics?
Planning a PACS, VNA or image-sharing build?
Agnotic builds imaging software for the client, from DICOM and DICOMweb services to VNA integration, EHR viewer launch and archive migration.
Imaging informatics is the engineering and governance of medical image data across its whole life: capture at the modality, storage in PACS and a vendor neutral archive, exchange between organizations, and display in viewers launched from the EHR. It applies the DICOM standard and IHE profiles so that images stay findable, correct and linked to the right patient.
Radiology produces the most images, but it is not the only source. Cardiology, dermatology, endoscopy, ophthalmology, wound care and point-of-care ultrasound all create images that clinicians expect to find in the same record. Imaging informatics treats these as one enterprise problem rather than a set of departmental systems.
What does DICOM define?
DICOM defines both the format of an imaging object and the network services that move it. It is the one standard every modality, PACS, archive and viewer has in common, so its details decide how well those systems work together.
- Information model: Every object belongs to a patient, a study, a series and an instance. Each study, series and instance carries a globally unique identifier (UID), and those UIDs are how every downstream system recognizes the same image.
- SOP classes: Each object type, such as CT Image Storage, Structured Report or Segmentation, is a Service-Object Pair class with its own required attributes.
- DIMSE services: The classic network services include C-STORE to send objects, C-FIND to query, C-MOVE and C-GET to retrieve, and Modality Worklist to give scanners their scheduled exams.
- Conformance statements: Each product publishes the SOP classes, roles and transfer syntaxes it supports. Comparing two conformance statements is the first integration test.
Most interoperability problems trace back to attributes, not to transport. Two systems can exchange objects perfectly and still disagree on which patient ID, accession number or issuer of patient ID is authoritative.
DICOMweb and the move to HTTP
DICOMweb is the RESTful form of DICOM, and it lets web and cloud applications work with images without a DIMSE stack. The standard defines its services in PS3.18, and DICOMweb can be implemented directly or as a proxy in front of existing DIMSE services.
- QIDO-RS: Searches for studies, series or instances and returns the matching attributes, including as DICOM JSON.
- WADO-RS: Retrieves whole studies, single instances, metadata only or rendered frames.
- STOW-RS: Stores new objects over HTTP, which suits mobile capture and cloud ingestion.
- UPS-RS: Manages worklist items, the web counterpart to procedure step workflow.
DICOMweb does not replace the information model. A STOW-RS upload with a wrong patient ID is as wrong as a C-STORE with one. What changes is deployment: standard web authentication, gateways and caching become possible, and a browser viewer can pull frames on demand instead of downloading a whole study.
HL7 FHIR adds a lighter index on top. The FHIR ImagingStudy resource summarizes a DICOM study, its series, its instances and an endpoint to reach them, so an EHR app can find images without querying the archive directly.
How do images move from modality to PACS, VNA and viewer?
An image travels through seven stages, and a different IHE profile governs each handoff. The sequence below follows one scheduled exam from the order to an outside clinician's viewer.
- 1. Order and worklist: The EHR or RIS schedules the exam, and the modality pulls patient and procedure details from the Modality Worklist. IHE Scheduled Workflow.b (SWF.b) defines this handoff and the status updates that follow.
- 2. Acquisition: The modality creates DICOM instances with new UIDs, the accession number and the patient identifiers it received from the worklist.
- 3. Store to PACS: The modality sends the study by C-STORE or STOW-RS and requests storage commitment, so it deletes local copies only after the archive confirms receipt.
- 4. Read and correct: The PACS presents the study for interpretation. Fixes such as a wrong patient or a rejected series follow IHE Patient Information Reconciliation (PIR) and Imaging Object Change Management (IOCM).
- 5. Archive in the VNA: The PACS forwards the study to the vendor neutral archive for long-term storage under the enterprise patient identity, and passes IOCM changes along so both copies agree.
- 6. Share across organizations: An XDS-I.b manifest registers the study in a document registry so another facility can find and retrieve it. Cross-Community Access for Imaging (XCA-I) extends the same pattern between communities.
- 7. View: A clinician opens the study from the EHR through Invoke Image Display (IID), which passes patient or study context to the viewer, or through a browser viewer that uses Web-based Image Access (WIA).
An AI step can branch off stage 3. IHE AI Workflow for Imaging (AIW-I) describes how an AI task is requested and tracked, and AI Results (AIR) describes how its output is stored and displayed. Both are still Trial Implementation supplements, so vendor support varies.
Two duties apply at every stage rather than in sequence. HIPAA Security Rule audit controls apply to each system that stores or displays ePHI, and each outside party that hosts images needs a business associate agreement.
Which IHE profiles are mature enough to require?
Profiles published as Final Text in the IHE Radiology Technical Framework are safe to name in a contract, while Trial Implementation supplements are still being tested. This decision list uses the status shown on profiles.ihe.net in November 2026.
- SWF.b, Final Text: Require it in any modality, RIS or PACS purchase. It covers orders, worklists, storage and procedure step status.
- PIR and IOCM, Final Text: Require both. Without them, patient merges and rejected images leave stale copies in downstream archives.
- XDS-I.b and XCA-I, Final Text: Require them when images must be shared with other facilities or a health information exchange.
- IID and WIA, Final Text: Require IID for EHR-launched viewing, and WIA when a browser viewer must reach the archive.
- Encounter-Based Imaging Workflow (EBIW), Trial Implementation: Ask for it for photos and video captured without a scheduled order, such as wound or skin images, and test it before relying on it.
- AIW-I and AIR, Trial Implementation: Ask vendors for their roadmap and test results rather than writing these as mandatory.
A vendor claim of IHE support means little without evidence. Ask for the IHE Integration Statement and Connectathon results for the specific actor the product plays, such as Image Manager or Image Display.
PACS, VNA and enterprise imaging
A PACS is built for reading, and a vendor neutral archive is built for keeping. The PACS is tuned for the reading worklist and fast display of current and prior studies. A VNA stores images in standard formats from many departments, so the organization can change viewers or PACS without migrating everything again.
- Primary user: A PACS serves radiologists and technologists. A VNA serves the enterprise, including systems that never display images.
- Content: A PACS holds DICOM radiology studies. A VNA can also hold non-DICOM content such as photos, PDFs and video, either wrapped as DICOM or registered as XDS documents.
- Patient identity: A PACS usually works with one facility's local identifier. A VNA needs the enterprise identifier and a map to each facility's local IDs.
- Lifecycle: A PACS keeps studies online for reading. A VNA applies retention and deletion rules per content type, set by legal and records teams.
Enterprise imaging is the program that brings departments onto shared storage, a shared viewer and one patient identity. Storage is rarely the hard part. Capturing images from phones and cameras with the right patient and encounter attached is harder, and that is the gap EBIW and Web-based Image Capture (WIC) address.
What rules apply to stored and shared images?
Images are ePHI, so archives, viewers and sharing gateways need the same safeguards as the EHR. One rule settles the hosting question, and the rest is design work the imaging team owns.
- Cloud archives are business associates: HHS states in its HIPAA cloud computing guidance that a cloud provider which stores ePHI counts as a business associate. Lacking the decryption key does not change that status.
- Audit every access: Each PACS, VNA, viewer and sharing gateway should log who opened which study, from where and when, and someone should review those logs rather than only store them.
- Encrypt links and storage: Modality connections, DICOMweb endpoints and archive disks all carry ePHI. Encryption at rest is an addressable HIPAA safeguard, so implement it or document the equivalent measure.
- Check access at the viewer: An EHR launch should carry the user's identity, and the viewer should confirm that the user may see that patient before it loads a single image.
- Control exports: Disc and USB exports, research sharing and teaching files need de-identification rules that cover burned-in text and scanned pages, not only DICOM headers.
Where imaging informatics projects break
Imaging projects usually fail on identity and change handling, not on storage capacity. Walk through this failure-point list before an archive migration or a sharing go-live.
- Merges that never propagate: The EHR merges two patient records and PACS updates, but the VNA and the sharing registry keep the old identifier.
- Unmapped facilities: Studies from an acquired facility carry a different issuer of patient ID, and nobody maps them to the enterprise identifier during migration.
- Duplicate UIDs: A misconfigured modality or migration tool reuses a UID that already exists, so one study silently overwrites another.
- Lost rejections: A technologist rejects a bad series in PACS, but without IOCM the rejected images stay in the VNA and appear in the next viewer.
- Unchecked viewer launches: The EHR passes a study identifier in a URL, and the viewer never checks the user's authorization for that patient.
- Identifiers in shared studies: Studies sent to a research partner keep burned-in names on ultrasound frames or scanned documents after header de-identification.
- Retention left at defaults: The VNA keeps or deletes everything because nobody set retention rules for each content type.
How Agnotic can help
Imaging informatics work pays off when identity, change handling and sharing are designed before the first study moves. Agnotic Technologies builds that layer for hospitals, imaging groups and medical imaging software companies: DICOM and DICOMweb services, PACS and VNA interfaces, IHE-based image sharing and EHR viewer launch.
For an archive migration, Agnotic writes the tag-mapping rules, reconciles patient identities against the enterprise index, verifies every migrated study by UID and object count, and keeps an audit record of each change.
Plan your imaging informatics work with Agnotic
Explore medical imaging and PACS solutions, or browse more articles in the medical imaging hub.
Related reading on Agnotic
Continue with radiology workflow software, AI medical imaging, HL7 orders and results, healthcare data migration, cloud computing and radiology cybersecurity.
