Radiology Imaging Stack: DICOM, PACS, Viewers, Build vs Buy

Quick reference

The eight things you will look up during a vendor call. Everything below is from the current DICOM edition (PS3.1 2026c) unless a row says otherwise.

Information hierarchyStudy → Series → Instance Patient → Study (0020,000D) → Series (0020,000E) → SOP Instance (0008,0018) → Frame. Frames have no UID of their own; they are addressed by number inside an instance.

Registered ports104 / 11112 IANA registers acr-nema on 104 (the historic DICOM port) and dicom on 11112 (registered Aug 2005). dicom-tls is 2762; dicom-iscl is 2761. 11112 is the usual unprivileged choice.

AE Title length16 bytes max PS3.5 Table 6.2-1: VR AE is “16 bytes maximum”, default repertoire, leading/trailing spaces non-significant, all-spaces forbidden. It is an identifier, not a credential.

Conformance statementPS3.2 Annex N The template a real statement follows: N.4 Implementation Model, N.5 Service & Interoperability Description, N.6 Configuration, N.7 Network/Media details, N.8 Security. Open N.5 first.

DIMSE core verbsECHO STORE FIND MOVE GET Plus N-ACTION / N-EVENT-REPORT for Storage Commitment and N-CREATE / N-SET for MPPS. Composite services are C-, normalized services are N-.

DICOMweb servicesQIDO STOW WADO UPS PS3.18 defines the URI Service (WADO-URI), Studies Service (QIDO-RS / WADO-RS / STOW-RS), Worklist Service (UPS-RS), Non-Patient Instance, Storage Commitment, and Modality Scheduled Procedure Step services.

Storage UID roots1.2.840.10008 Image and document Storage SOP Classes sit under 1.2.840.10008.5.1.4.1.1.; transfer syntaxes under 1.2.840.10008.1.2. Anything that does not start 1.2.840.10008 is not a DICOM-defined UID.

Vocabulary ladder5 rungs, not synonyms Standards support → conformance → compatibility → interoperability → workflow fitness. A vendor can honestly claim rung 1 and fail rung 5.

The five-rung vocabulary ladder Standard Recommendation

Standards support: the product implements some capabilities defined by a standard.
Conformance: the implementation’s relationship to the standard is described through the standard’s own conformance mechanism. For DICOM that is a PS3.2 Conformance Statement, not a marketing sentence.
Compatibility: two implementations share a mutually usable set of capabilities.
Interoperability: the implementations actually exchange and use information in the required workflow.
Workflow fitness: the combined system meets the clinical, product, safety, and operational need.

Use it like this: when a supplier says “we are DICOM compatible”, ask which rung they are claiming and what evidence exists for it. “Compatible” is rung 3 and is usually asserted with rung 1 evidence.

The stack map

Thirteen strata, read bottom-up like a geological section. Tint = strategic character. The stamp is a default lean for a company building an imaging product, not a requirement Recommendation. Every stratum is a link to its section, so this is also the table of contents. Fill in your own verdicts in the scorecard.

What each standard and body actually is

The rest of this page uses about forty acronyms as if you already knew them. This section is the one place that says what each one is, in a sentence, and who stands behind it. Read it once and the later tables stop being alphabet soup: the difference between a standard, a profile of a standard, a professional guideline, and a regulation is exactly the difference between the evidence badges used everywhere else on this page. Standard Prof. guidance

Standards and service families

Table 2B.1: What each standard is, in one sentence
Name	What it is	Published by	Where it stops
DICOM	Digital Imaging and Communications in Medicine: the standard defining how medical images and their related information are encoded, stored, queried, and moved between systems. It is both a file format and a set of network services, which is why one word covers a `.dcm` file on disk and a conversation between two servers. Recognised as ISO 12052; first published under the DICOM name in 1993.	NEMA, developed by the DICOM Standards Committee	At the wire and the object. It defines nothing about your product: no viewer, no workflow, no user model. See what DICOM does not provide.
PS3.1 … PS3.22	Not versions: parts. DICOM is published as one standard split into twenty-two numbered parts, each governing one concern (PS3.4 services, PS3.5 encoding, PS3.6 the data dictionary, PS3.18 web services). “PS” is the NEMA publication-standard prefix. The edition label (2026c) moves several times a year; part numbers do not.	Same standard, one document per part	Part numbers tell you where to look, not what a product does. A conformance claim cites a part and a service.
DIMSE	DICOM Message Service Element: the original DICOM networking layer, running its own protocol directly over TCP/IP rather than over HTTP. Two applications open an association, negotiate what they may send, then exchange messages such as C-STORE (send an image) and C-FIND (search). This is what people mean by “classic DICOM” or “port 104”.	DICOM PS3.7 and PS3.8	It is a transport, not a workflow. No session concept, no user identity worth the name, no web-friendly story. See DIMSE.
DICOMweb	The name for the family of RESTful web services defined for sending, retrieving, and querying medical images and related information over HTTP. Same objects and same identifiers as DIMSE, addressed as URLs: QIDO-RS searches, WADO-RS retrieves, STOW-RS stores, UPS-RS manages worklist items. This is the transport a browser-based product actually uses.	DICOM PS3.18	It is DIMSE’s peer, not its replacement: modalities still speak DIMSE, so most real systems need a gateway between the two.
DICOM SR	Structured Report: a DICOM object whose content is a coded tree of observations rather than pixels. It is how measurements, CAD output, dose records, and AI results travel as first-class imaging objects that reference the exact images they describe. TID 1500 is its measurement-report template.	DICOM PS3.3 and PS3.16	It is an encoding, not a reporting application. Nothing in SR gives you templates, dictation, or a sign-off workflow.
GSDF	Grayscale Standard Display Function: a curve, not a service. It defines how a grayscale display maps stored pixel values to luminance so the same image looks the same on any calibrated monitor.	DICOM PS3.14	Conformance is a property of the display and its calibration, not of your software alone.
HL7 v2	The pipe-and-caret messaging standard that still carries most real-world clinical traffic: orders (`ORM`, `OMI`) and results (`ORU^R01`), usually over a minimal framing protocol called MLLP. Elderly, ubiquitous, and heavily site-customised, which is why interface engines exist.	HL7 International	It carries the words around the images; it never carries the images. Optionality is so wide that two conformant v2 feeds can still need a mapping project.
HL7 CDA	Clinical Document Architecture: an XML document standard for clinical documents, including imaging reports. DICOM PS3.20 defines the transformation from an imaging report into CDA.	HL7 International	A document format. It says nothing about how the document is produced, delivered, or acknowledged.
HL7 FHIR	Fast Healthcare Interoperability Resources: the modern HL7 standard, built as REST plus a library of typed resources (Patient, ServiceRequest, ImagingStudy, DiagnosticReport). Current published version R5 (v5.0.0). Each resource carries its own maturity level, so “we support FHIR” means nothing until you name the resources.	HL7 International	At the pixels. ImagingStudy is an index that points at a DICOMweb service; it is not a store. See FHIR.
FHIRcast	An HL7 specification for context synchronisation between applications on one user’s desktop: when the radiologist opens a study in the viewer, the reporting application follows. The IHE IRA profile depends on it. Emerging	HL7 International	Version dependency matters: IRA needs FHIRcast 3.0.0, still under development, which is why IRA says it is not production-ready.
IHE integration profile	A named recipe saying how to combine existing standards to solve one integration problem, written in terms of actors and transactions. A profile invents no new standard: SWF.b, IOCM, and PDI are all DICOM and HL7 underneath, constrained until two vendors can actually interoperate.	IHE International	A profile claim is worthless without an actor role and a maturity level. See IHE profiles.
IHE Technical Framework	The volumes holding the Final Text profiles for one domain. Radiology is at Revision 23.0 (2025-08-08). A profile that is “in the framework” is Final Text; anything else is a supplement at a lower maturity.	IHE International	It is not a certification. Testing happens at a Connectathon and those results are published separately.
XDS-I.b / XCA-I	The cross-organisation sharing family: publish a manifest of a study to a registry so another organisation can find and retrieve it (XDS-I.b), or query across communities of registries (XCA-I). The document-sharing model of health information exchanges, applied to imaging.	IHE International	Heavy infrastructure. Point-to-point DICOMweb or a shared archive is the usual alternative for a single product.
ACR–AAPM–SIIM technical standards	Consensus documents from three professional bodies covering the electronic practice of medical imaging: compression, display luminance, teleradiology practice. The source of the DAIC concept.	ACR, AAPM, and SIIM jointly	Guidance, not regulation: ACR states its practice parameters and technical standards are educational tools, not a legal standard of care. Cite as Prof. guidance, never as “required”.
NIST SP 1800-24	A practice guide, Securing Picture Archiving and Communication System (PACS) (December 2020): a reference architecture and capability list for locking down an imaging environment.	NIST, US Department of Commerce	Voluntary guidance. It is not HIPAA, though it maps to it. See the control areas.
HIPAA Security Rule	US federal regulation (45 CFR Part 164 Subpart C) setting administrative, physical, and technical safeguards for electronic protected health information. Deliberately technology-neutral: it names no cipher, no protocol, and no product.	US HHS, enforced by the Office for Civil Rights	It never says “use TLS 1.3”. Anyone telling you HIPAA requires a specific product feature is quoting a vendor, not the rule.
JPEG family, HTJ2K	The image codecs DICOM wraps rather than invents: baseline and lossless JPEG, JPEG-LS, JPEG 2000, and High-Throughput JPEG 2000 (the same wavelet transform with a much faster block coder). Each appears in DICOM as a transfer syntax UID.	ISO/IEC codecs, registered as DICOM transfer syntaxes	Support is per transfer syntax UID, per direction. “We support JPEG 2000” is not a decoder list. See transfer syntaxes.
TLS, syslog, ATNA	The ordinary internet security stack as DICOM and IHE constrain it: TLS for transport, syslog for audit transport, and the ATNA profile plus the PS3.15 audit message format for what an audit record must contain and where it goes.	IETF protocols, profiled by DICOM PS3.15 and IHE	Encryption and audit are necessary, never sufficient. Neither tells you who was allowed to open the study.

The bodies behind them

Four kinds of organisation appear on this page, and which kind it is decides how much weight a claim carries: a standards developer, an initiative that profiles standards, a professional society, and a regulator. Each row below was checked against that body’s own pages, Sep 2026.

Table 2B.2: Organisations named on this page
Body	What it is	What it owns or publishes	Why it appears here
NEMA	National Electrical Manufacturers Association: a US trade association whose members include the medical imaging equipment manufacturers. A standards developer, not a clinical body.	Holds the DICOM copyright and publishes the standard as NEMA Standard PS3.	Every `dicom.nema.org` link on this page, and the normative text behind every Standard badge.
MITA	Medical Imaging & Technology Alliance: the division of NEMA representing medical imaging manufacturers.	Serves as the DICOM Secretariat: meetings, balloting administration, publication.	The “Secretariat: MITA/NEMA” line on working-group minutes, if you ever chase a change proposal.
DICOM Standards Committee	The committee that actually develops the standard, working through 35 numbered working groups as of Sep 2026 (WG-06 Base Standard, WG-14 Security, WG-23 Artificial Intelligence, WG-27 Web Services, among them).	Supplements (new capability) and Change Proposals (corrections), which accumulate into the next edition label.	Why the standard has several editions a year, and why a UID never changes underneath you.
ACR	American College of Radiology: the professional body for radiologists, radiation oncologists, and medical physicists.	Practice parameters and technical standards; co-author of the ACR–AAPM–SIIM documents.	With NEMA it formed the 1983 standards committee that produced ACR-NEMA 300 in 1985, DICOM’s ancestor. That history is why IANA still calls port 104 `acr-nema`.
AAPM	American Association of Physicists in Medicine: the medical physics scientific and professional society, founded 1958.	Task group reports on image quality, dose, and display QA; co-author of the joint technical standards.	The display luminance and calibration numbers a diagnostic viewer gets judged against.
SIIM	Society for Imaging Informatics in Medicine: the professional society for imaging informatics, founded 1989 as SCAR and renamed in 2006.	Enterprise imaging guidance; co-author of the joint technical standards.	The informatics half of the ACR–AAPM–SIIM standard that defines diagnostically acceptable irreversible compression.
IHE International	Not a standards developer: an initiative by healthcare professionals and industry to make existing standards work together, begun in 1998 by HIMSS and RSNA.	Integration profiles, domain Technical Frameworks, and Connectathon testing events.	Everything in Table 10.1. When a vendor says “we do IHE”, they mean they implement some actor in some profile.
RSNA and HIMSS	The Radiological Society of North America (a radiology professional society) and the Healthcare Information and Management Systems Society (a health IT society).	IHE itself, which they founded jointly.	Context for why IHE profiles are shaped by radiology workflow first and enterprise IT second.
HL7 International	Health Level Seven International: a not-for-profit, ANSI-accredited standards developing organisation founded in 1987. “Level Seven” is the application layer of the OSI model.	HL7 v2, CDA, and FHIR.	Every order, result, and clinical-context integration your imaging product has to live inside.
ISO	International Organization for Standardization.	Recognises DICOM as ISO 12052.	Useful when a procurement document demands an ISO reference. It is the same DICOM.
FDA	US Food and Drug Administration: the medical device regulator, covering software as a medical device and animal devices.	Device classification, clearance pathways, and the public list of AI-enabled devices.	Whether your viewer or model is a regulated device at all, and on which side of the human/veterinary line. Regulatory (US)
NIST	National Institute of Standards and Technology: a US federal measurement and standards agency. It regulates nothing.	SP 1800-24 and the wider cybersecurity practice-guide series.	The most usable public checklist for securing an imaging estate.
HHS OCR	The Office for Civil Rights inside the US Department of Health and Human Services.	Enforces the HIPAA Privacy and Security Rules.	The authority behind every Regulatory row in security.
IANA	Internet Assigned Numbers Authority: the registry for protocol numbers, including TCP ports.	The service name and transport protocol port number registry.	The authority for `acr-nema` 104, `dicom` 11112, and `dicom-tls` 2762.

IHE’s four words, which vendors use loosely and you should not

UnitActorA functional unit that produces, manages, or acts on information: Image Manager, Acquisition Modality, Report Creator. Products implement actors, not whole profiles.

ExchangeTransactionOne information exchange between two actors, defined on top of an existing standard such as DICOM or HL7 and given a number (RAD-x).

RecipeIntegration profileA named set of actors and transactions that solves one workflow problem end to end. The unit a vendor claims and you test.

ProofConnectathonA supervised, face-to-face event where implementations test the transactions against other vendors’ systems. Results are published; ask for the year and the actor.

System categories: what the product words mean

The standards above are written down somewhere. These words are not: they are market categories, and nobody owns their definitions. Two products called the same thing routinely have different boundaries, and two products called different things routinely overlap. So each row below gives the working definition, the problem the category exists to solve, and the specific way the word misleads people in a vendor call. This is why PACS versus VNA has to be settled by capability rather than by label. Common practice

Table 2B.3: The system categories, and where each word misleads
Term	What it is	The problem it exists to solve	Where the word misleads
Modality	The device that acquires the image: a CT scanner, an ultrasound machine, a digital radiography plate, an intraoral dental sensor. In DICOM the word is also a two-letter code in `(0008,0060)`: `CT`, `MR`, `US`, `DX`, `MG`.	Nothing: it is the source. Everything downstream exists because the modality produces objects that must reach a reader with the right patient attached.	The device and the code are not the same thing. One scanner can produce several modality codes, and a code tells you the acquisition type, never the manufacturer or the protocol.
RIS	Radiology information system: the department’s order, scheduling, and workflow system. Usually where the accession number is born and where the exam’s administrative state lives.	Getting from “a clinician wants a chest CT” to a scheduled procedure step a scanner can pull off a worklist, then tracking the exam to billing.	Many small practices have no RIS at all: the EHR or PIMS carries the order, and the identity source of truth moves with it. Do not design as if a RIS is always there.
PACS	Picture Archiving and Communication System: the traditional bundle of image archive, workflow, and diagnostic viewer sold and deployed as one product. NIST notes FDA classifies PACS as a Class II device.	Being the department’s single place where images land, are read, and are found again, replacing film and the light box.	The word says nothing about a specific product’s boundaries. Two “PACS” can differ on whether they hold reports, drive worklists, do routing, or offer a web viewer. Ask for the capability list, never the category.
VNA	Vendor-neutral archive: the imaging store deliberately separated from any one viewer, department, or PACS, so studies outlive the application that created them. It keeps original objects, normalises metadata across sources, owns retention and holds, and serves several readers over standards-based interfaces.	PACS lock-in. When archive, workflow, and viewer ship as one product, replacing the viewer means migrating every image out of a system whose vendor has no incentive to make that easy.	“Vendor-neutral” is a claim, not a property, and no standard defines it. Test it: demand a timed bulk export of a real cohort in original form, and ask whether metadata normalisation is auditable and reversible. If it owns workflow state, you have bought a second PACS. See the exit test.
Image manager / image archive	The IHE actor pair underneath both product words: the manager knows what exists, where it is, and what may be released; the archive holds the bytes.	Naming the two responsibilities separately, so a workflow claim can be tested against the right one.	Products fuse them and market the pair as one box. The split is how you ask a precise question: which actor implements storage commitment, and which one answers the query?
EHR / EMR	The organisation-wide clinical record system. In imaging it is usually the launch point (a link into a viewer in patient and study context) and the consumer of the finished report.	Holding the patient’s whole record, of which imaging is one section.	It is rarely an imaging system. “Images in the EHR” almost always means a launched viewer or an embedded link, not stored DICOM. See IID for the standards-based way to do that launch.
PIMS	Practice information management system: the veterinary equivalent of an EHR plus practice management and billing, and typically the identity source of truth in a clinic.	Running the whole practice: appointments, records, inventory, invoicing. Imaging is a small module inside it.	Veterinary identity is not human identity: no national patient identifier, owner and animal are separate entities, and the same pet is re-registered across clinics. Identity reconciliation is harder here, not easier. See identity.
Interface engine	The middleware that translates, routes, filters, and buffers HL7 and DICOM traffic between systems that disagree about message content, codes, and identifiers.	HL7 v2’s optionality. Two conformant feeds still need a per-site mapping, and somebody has to own that mapping, monitor it, and replay what it drops.	It gets treated as “a script the integration guy wrote”. It is a production component with uptime, versioning, and an owner, and it is where undiagnosed data loss hides.
DICOM gateway / router	The process that accepts DIMSE associations from modalities and re-emits the objects elsewhere, commonly as DICOMweb, with queueing, retry, routing rules, and often de-identification or tag morphing.	Modalities speak DIMSE and will for the life of the hardware; a cloud product speaks HTTP. Something has to sit on the boundary. See the gateway section.	“We have a DICOM receiver” is roughly ten percent of the job. The other ninety is state: what arrived, what is incomplete, what failed, and what a human does about it. See ingestion failure scenarios.
Edge uploader	The on-site agent that gets studies out of a clinic across a consumer-grade link, surviving reboots, outages, sleeping workstations, and NAT.	The last mile. Small sites have no IT staff, no static address, and no tolerance for a device that needs attention.	Confused with the gateway. The difference is where it runs and who owns the network: you cannot assume a firewall change, a fixed address, or a machine nobody switches off.
Viewer	Anything that displays images, spanning three tiers: a thumbnail or preview, a review viewer for referrers, and a diagnostic workstation for primary interpretation.	Getting pixels in front of the person who has to make a call, with the tools that decision needs.	One word, three regulatory and calibration situations. Diagnostic reading carries display and device obligations a review viewer does not. Never evaluate one from screenshots. See the tiers.
Workbench / worklist	The radiologist’s working surface: what to read next, in what order, with which priors, context, and prior reports loaded.	Throughput and safety in the reading session itself: assignment, prioritisation, hand-off, escalation of critical findings.	Almost none of it is standardised, so it is invisible in a standards conversation and is exactly where product differentiation and most of the build cost live. See the workbench.
AI orchestrator	The layer that decides which studies go to which model, runs and tracks the job, and files the output as a DICOM SR, GSPS, or secondary capture. Separate from the models.	Models are point solutions; the routing, queueing, provenance, and result-filing around them is a platform problem you own whether you buy or build the models.	Vendors sell the model and imply the orchestration. Ask where results land, in what object type, with what model and version recorded. See AI orchestration.
Teleradiology platform	A product that moves studies from sites that acquire to radiologists who read somewhere else, adding assignment, licensure and credentialing rules, turnaround commitments, and report delivery.	The reader is not in the building, and often not in the same organisation, state, or country as the patient.	It sounds like a viewer plus a queue. The hard parts are contractual and jurisdictional: who may read what, under which licence, with what turnaround, and what happens when the commitment is missed.
Enterprise imaging	The programme word for handling imaging from every service line, not just radiology: dermatology photographs, endoscopy video, point-of-care ultrasound, pathology.	Non-radiology images that live on phones, on cameras, and in departmental silos, unreconciled and unretained.	It describes a scope and a budget line, not a product. When a supplier sells “enterprise imaging”, ask which encounter-based capture workflow they actually implement. See EBIW and WIC.

Use this to weigh a claim, not just to decode it Recommendation

Every sentence in a vendor conversation has an author, and the author sets the ceiling on what the sentence can prove. A standards developer (NEMA, HL7) produces normative text you can cite by section. A profiling initiative (IHE) produces a recipe plus a maturity level and a testing record. A professional society (ACR, AAPM, SIIM) produces guidance whose own front matter usually says it is educational rather than a legal standard of care. A regulator (FDA, HHS OCR) produces obligations with a jurisdiction attached, while a guidance agency such as NIST produces none at all.

So when you are told something is required, the useful question is not “required by whom?” but “which of those four, and can you name the section?” The prescriptive vocabulary table applies the same test to your own writing.

Vocabulary that must not be confused

Most bad imaging decisions are made in the gap between what a standard requires, what vendors commonly do, and what somebody recommends. These two tables are the page’s grammar. Every badge below appears on the tables that follow.

Prescriptive vocabulary: when each phrase is allowed

Table 3.1: Prescriptive vocabulary
Phrase	Use only when	Failure mode when misused
must / shall	A verified normative, contractual, or legal requirement establishes the obligation.	An architecture preference gets treated as a compliance obligation and blocks a reasonable design.
is required by	The cited authority explicitly imposes the requirement, and you can name the clause.	“HIPAA requires…” claims that are not in 45 CFR Part 164 at all.
conforms to	The claim is tied to the standard’s own conformance mechanism: for DICOM, a PS3.2 Conformance Statement.	Conformance is claimed where only partial support exists; the gap surfaces at integration.
supports	The implementation documents the named capability, without implying workflow interoperability.	“Supports GSPS” read as “writes GSPS” when the product only reads it.
should	Professional guidance or a clearly identified strong recommendation supports it.	Guidance is enforced as a gate, or ignored as an opinion, both because nobody said which it was.
commonly	Credible evidence supports recurring industry use.	One vendor’s behavior becomes “the industry standard” in a requirements document.
can / may	The text describes an option or capability, not a requirement.	An optional DICOM attribute is assumed to be always present, and parsing breaks on the first sender that omits it.
we recommend	The statement is your own synthesis, and you own the consequences.	A recommendation is laundered into a “standard” to win an argument.
in this case study	The observation is deliberately limited to the implementation described.	One site’s compression ratio, throughput, or cost becomes a universal number.

Evidence labels used on this page

Table 3.2: Badge legend
Badge	Means	Where you verify it
Standard	Normative requirement or definition from a recognized standards-development organization.	The part and section: PS3.4 C.4.2, PS3.6 Annex A, PS3.18 §10.4.
IHE: Final Text	Mature IHE profile incorporated into the Radiology Technical Framework.	profiles.ihe.net/RAD, Technical Framework volume list.
IHE: Trial Impl.	Supplement published for implementation testing; may still change.	Same page, “Supplements for Trial Implementation”.
IHE: Public Comment	Emerging proposal open for comment. Not implementation guidance.	Same page, “Public Comment” block, with the comment window dates.
IHE: Deprecated	Withdrawn or replaced; kept for legacy context only.	Same page and the IHE Radiology Archive.
Regulatory	A law, rule, or regulator-issued requirement, with jurisdiction stated. All regulatory rows here are US unless labelled.	eCFR, hhs.gov, fda.gov: cited per row.
Prof. guidance	Consensus or educational guidance from a professional body. ACR states its practice parameters are educational tools, not a legal standard of care.	ACR practice parameters and technical standards, with the revision year.
Common practice	A recurring implementation approach, not mandated by any standard.	Conformance statements, product docs, your own PoC.
Architecture pattern	A reusable design with benefits, costs, limits, and alternatives.	Nowhere authoritative: argue it on its merits.
Recommendation	This page’s synthesis. Disagree freely.	Your own context and risk appetite.
Emerging	Technology or profile not yet mature enough to present as settled practice.	Re-check annually; the badge is a decay timer.

What DICOM does not provide Recommendation

DICOM covers production, storage, display, transmission, query, processing, and retrieval of imaging information. It stops well short of a product. Nothing in any DICOM part gives you:

A finished diagnostic viewer
A complete reporting application
A customer or owner experience
Customer onboarding

A radiologist staffing model
Case assignment policy
Support and exception processes
Product pricing

A cloud deployment architecture
Business-system identity ownership
Tenant and entitlement models
A product analytics strategy

Every one of those is in your scope whether you buy or build. Half the cost overruns in imaging programs live in this list.

DICOM, part by part

What a “part” isDICOM is not published as one document with a version number. It is one standard cut into twenty-two numbered parts, each governing a separate concern, and every part is republished together several times a year under an edition label such as 2026c. PS3.4 is a part, not a release: PS is NEMA’s publication-standard prefix. Citing “DICOM” without a part is how requirements documents become unfalsifiable.

The standard is republished several times a year; the current edition when this page was written is 2026c (each part’s cover page carries the edition label, e.g. “DICOM PS3.1 2026c”). UIDs and tags are stable across editions; the edition label is not. Parts 9 and 13 were retired and are listed so you recognise them in old documents. Standard

Table 4.1: PS3.1 through PS3.22, and when to open each
Part	Title	What it governs	Open it when…
PS3.1	Introduction and Overview	Scope, the communication model, and the map of the other parts.	You need the current edition label, or you are orienting someone new.
PS3.2	Conformance	What a conformance claim means and the structure of a Conformance Statement (Annex N is the template).	A vendor hands you a PDF and you need to know which sections are load-bearing. Start at N.5.
PS3.3	Information Object Definitions	The structure and semantics of every imaging and related object; modules and IODs.	You are deciding which attributes your product may rely on being present.
PS3.4	Service Class Specifications	Storage, Query/Retrieve, Worklist, Storage Commitment, UPS and the rest, with SCU/SCP behavior.	You need the exact C-MOVE / C-GET semantics before designing a firewall or a retrieve path.
PS3.5	Data Structures and Encoding	Value representations, data-set encoding, and transfer syntaxes.	You are checking a VR length limit (AE = 16 bytes) or what a transfer syntax actually encodes.
PS3.6	Data Dictionary	Every standard attribute with tag and VR; Annex A is the registry of DICOM UIDs.	You need to confirm a tag number or a SOP Class / transfer syntax UID. This is the single source of truth for identifiers.
PS3.7	Message Exchange	DIMSE message structure, association services, and protocol behavior.	You are debugging an association negotiation or a status code.
PS3.8	Network Communication Support for Message Exchange	The upper-layer protocol over TCP/IP that carries DIMSE.	You are writing or tuning a DICOM listener, or explaining why DIMSE is not HTTP.
PS3.9	Retired: Point-to-Point Communication Support	Historic point-to-point networking.	Only when reading pre-2006 documentation.
PS3.10	Media Storage and File Format for Media Interchange	The DICOM file format, including the File Meta Information header.	You are importing from CD/USB, or your parser is choking on a file without a preamble.
PS3.11	Media Storage Application Profiles	Which objects and encodings are allowed on which physical media.	You support import from external media and need to know what to expect on it.
PS3.12	Media Formats and Physical Media for Media Interchange	The physical media themselves.	Rarely. Legacy media import projects.
PS3.13	Retired: Print Management Point-to-Point Communication	Historic print management.	Only when reading legacy film-printer documentation.
PS3.14	Grayscale Standard Display Function	The GSDF: a perceptually linearised luminance response curve for grayscale display.	You are specifying or auditing diagnostic display calibration.
PS3.15	Security and System Management Profiles	TLS transport profiles, audit trail message format, and the attribute confidentiality (de-identification) profiles and options.	You are designing de-identification, audit, or encrypted DIMSE. Annex E is the de-identification annex.
PS3.16	Content Mapping Resource	Coded terminology, context groups (CIDs), and structured report templates such as TID 1500 Measurement Report.	You are encoding AI or measurement results as SR, or need the IOCM rejection codes in CID 7010.
PS3.17	Explanatory Information	Informative annexes, examples, and rationale.	You want to understand why something in PS3.3 or PS3.4 is shaped the way it is. Informative, not normative.
PS3.18	Web Services	DICOMweb: the URI Service, Studies Service, Worklist Service, Non-Patient Instance, Storage Commitment, and Modality Scheduled Procedure Step services.	You are writing or evaluating anything that speaks HTTP to an imaging archive.
PS3.19	Application Hosting	An interface for hosting a second application inside a DICOM application.	You are evaluating a plug-in model for analysis applications.
PS3.20	Imaging Reports using HL7 Clinical Document Architecture	Transformation of imaging reports into HL7 CDA documents.	Your delivery path includes CDA documents rather than plain HL7 v2 or FHIR.
PS3.21	Transformations between DICOM and other Representations	Mappings between DICOM and other models, including FHIR.	You are building the DICOM-to-FHIR bridge and want the standard’s own mapping rather than your own.
PS3.22	Real-Time Communication	Real-time video and metadata transport (DICOM-RTV).	You are carrying live surgical or interventional video, not stored studies.

DIMSE services and the association model

What DIMSE isDIMSE is the original way two DICOM systems talk to each other over a network: its own protocol running directly on TCP/IP rather than over HTTP, which is why it needs its own port and its own firewall rules. Before anything moves, the two applications open an association and negotiate which object types and encodings they will accept. Only then do the verbs run: C-STORE sends, C-FIND searches, C-MOVE and C-GET retrieve. Every modality in the world speaks this, and will for the life of the hardware.

Classic DICOM networking. Composite services start with C-, normalized services with N-. Every one of these runs inside an association negotiated over TCP, and everything a modality can do to you is bounded by what that association negotiated. Standard

Table 5.1: DIMSE services, roles, and the gotcha that costs you a week
Service	SCU → SCP	What it does	The gotcha
C-ECHO 1.2.840.10008.1.1	Anything → anything	Verification. Confirms an association can be established and the peer answers.	A green C-ECHO proves TCP reachability and AE Title acceptance. It proves nothing about whether your objects will be accepted. Do not let a successful echo close a connectivity ticket.
C-STORE	Modality/gateway → archive	Pushes one SOP Instance per message over an established association.	The SCP can only accept transfer syntaxes it proposed acceptance for in the presentation context. An archive that stores JPEG 2000 but did not negotiate it will reject the instance, and many modalities respond by silently retrying forever.
C-FIND (Query/Retrieve) 1.2.840.10008.5.1.4.1.2.2.1	Client → archive	Searches the Study Root (or Patient Root) Query/Retrieve Information Model and returns matching identifiers.	Hierarchical query requires unique keys at every level above the one you are querying; relational query lets you skip levels but is optional. If the SCP is hierarchical-only, “find all instances in this study” needs a series-level round trip first.
C-FIND (Modality Worklist) 1.2.840.10008.5.1.4.31	Modality → worklist SCP	Delivers scheduled procedure and patient information to the modality so the technologist selects rather than types.	Different SOP Class and a different matching model from Q/R. MWL is the single highest-leverage defect reducer in the whole stack: no worklist means hand-typed identity, which means reconciliation work forever.
C-MOVE 1.2.840.10008.5.1.4.1.2.2.2	Client → archive, which then becomes a Storage SCU	Instructs the archive to send matching instances to a third Application Entity.	Move Destination is an AE Title (PS3.4 C.4.2.1.3) that must already be configured on the SCP, and the C-STORE sub-operations “shall always be accomplished over an Association different from” the C-MOVE association: a new inbound connection to your host. This is the single most common firewall and NAT trap in imaging.
C-GET 1.2.840.10008.5.1.4.1.2.2.3	Client → archive	Same retrieval intent, but the instances come back to the requester.	“The C-STORE Sub-operations shall be accomplished on the same Association as the C-GET operation.” One outbound connection, no inbound hole, which is why C-GET is friendlier across firewalls. It is also less widely implemented, so check the conformance statement before designing around it.
N-ACTION (Storage Commitment) 1.2.840.10008.1.20.1	Sender → archive	Asks the archive to take custody of a listed set of instances.	Commitment is the archive’s promise, not the network’s. A modality that deletes local copies on commitment and an archive that answers optimistically will lose studies together.
N-EVENT-REPORT (Storage Commitment)	Archive → sender	The asynchronous answer: which instances are committed and which failed.	The result may arrive on a new association initiated by the archive, so the sender must be reachable as an SCP too. Same firewall shape as C-MOVE.
N-CREATE / N-SET (MPPS) 1.2.840.10008.3.1.2.3.3	Modality → MPPS SCP	Modality Performed Procedure Step: announces that acquisition started, and later that it completed or was discontinued.	MPPS is how you know a study is finished rather than merely quiet. Without it, “study complete” is a timeout heuristic, and every partial study looks like a slow one.
UPS (Unified Procedure Step) 1.2.840.10008.5.1.4.34.6.1	Any worker → UPS SCP	Push / Watch / Pull / Event / Query SOP Classes: a general worklist for post-acquisition work, including AI tasks.	The trial-era UPS SOP Classes (`….34.4.x`) are retired; use the `….34.6.x` set. UPS also has a DICOMweb form, UPS-RS.
Association / presentation context	Negotiated at connect time	Each presentation context pairs one abstract syntax (a SOP Class) with one or more transfer syntaxes (encodings) the initiator will accept.	Support is per-context, not per-product. A device can be a Storage SCU for CT and refuse Secondary Capture on the same association.
AE Title	Both ends	A 16-byte identifier for an Application Entity, carried in the association request.	An AE Title is not a user credential Recommendation. It is unauthenticated, guessable, and frequently reused across sites. Where legacy devices cannot do better, compensate with network segmentation and TLS, not with trust.

DICOMweb endpoints

What DICOMweb isDICOMweb is the name for the family of RESTful web services defined for sending, retrieving, and querying medical images and related information over HTTP. The objects and identifiers are identical to DIMSE’s; only the transport changes, from a negotiated association to an ordinary URL with an HTTP verb and a media type. Four services carry the traffic: QIDO-RS searches, WADO-RS retrieves, STOW-RS stores, UPS-RS manages worklist items. This is the transport a browser-based product actually runs on.

PS3.18 defines six services. The Studies Service is the one your browser application lives on. URI templates below are quoted from PS3.18 §10.4–10.6 and §11. Standard

Table 6.1: DICOMweb transactions, URI templates, media types
Transaction	Method	URI template	Media types	Gotcha
QIDO-RS: search studies	GET	`/studies{?search*}`	`application/dicom+json`, `multipart/related; type="application/dicom+xml"`	Hierarchical query. Every origin server must support it.
QIDO-RS: search a study’s series	GET	`/studies/{study}/series{?search*}`	`application/dicom+json`	Hierarchical. `{study}` is the Study Instance UID, not a database id.
QIDO-RS: search all instances	GET	`/instances{?search*}`	`application/dicom+json`	A relational query: mandatory for a native origin server, optional for a proxy. Do not assume it exists behind a gateway.
WADO-RS: retrieve instances	GET	`/studies/{study}` · `/studies/{study}/series/{series}` · `…/instances/{instance}`	`multipart/related; type="application/dicom"`	Returns whole Part 10 objects. The transfer syntax you get is negotiated through `Accept`; if you do not ask, you get the origin server’s choice.
WADO-RS: retrieve metadata	GET	`/studies/{study}/metadata` · `…/series/{series}/metadata` · `…/instances/{instance}/metadata`	`application/dicom+json`	Bulk data is replaced by `BulkDataURI` references. This is the endpoint that makes a viewer feel fast: fetch metadata first, pixels second.
WADO-RS: retrieve frames	GET	`/studies/{study}/series/{series}/instances/{instance}/frames/{frames}`	`multipart/related` with a bulk-data media type	`{frames}` is a comma-separated list of DICOM frame numbers, which begin at 1, not 0 Common practice. Off-by-one here shows a radiologist the wrong slice.
WADO-RS: bulk data	GET	`/studies/{study}/bulkdata` · `…/instances/{instance}/bulkdata` · `{bulkdataURI}`	`multipart/related`, octet-stream or a compressed bulk-data type	The `{bulkdataURI}` form is opaque and server-generated. Never persist it as if it were a stable identifier.
WADO-RS: rendered	GET	`/studies/{study}/series/{series}/instances/{instance}/rendered` (also `/rendered` at study and series level, and on `/frames/{frames}`)	`image/jpeg`, `image/png`, `image/gif`	Rendered output is a picture, already windowed and consumer-encoded. It is convenient for a portal and unsuitable for primary interpretation.
WADO-RS: thumbnail	GET	`/studies/{study}/thumbnail` · `…/series/{series}/thumbnail` · `…/frames/{frames}/thumbnail`	`image/jpeg`, `image/png`	A distinct resource from `/rendered`, with its own query parameters. Useful for worklists; still a lossy picture.
WADO-RS: rendered MPR / 3D volume	GET	`…/renderedmpr` · `…/rendered3d` at study, series, instance, and frame level	`image/jpeg`, video media types	Server-side volume rendering, defined in the standard but sparsely implemented. Treat as Emerging and verify per product.
STOW-RS: store	POST	`/studies` (mixed studies) · `/studies/{study}` (all instances must share that Study Instance UID)	`multipart/related; type="application/dicom"`; JSON/XML metadata + bulkdata forms exist	A 202 Accepted with a failure list inside the response body is a partial success. Parse the body; do not trust the status line alone.
WADO-URI: retrieve instance	GET	Single-instance retrieval by query parameters (PS3.18 §9), with options `anonymize`, `annotation`, `transferSyntax`	`application/dicom` or a rendered image type	The older URI Service. Still what many legacy “launch the viewer” integrations emit. One instance per request: useless for a modern viewer’s prefetch.
UPS-RS: worklist	POST / GET / PUT	`/workitems` · `/workitems/{workitem}` · `/workitems/{workitem}/state` · `/workitems/{workitem}/subscribers/{subscriber}`	`application/dicom+json`	The web face of Unified Procedure Step, including subscribe/unsubscribe for event notification. This is the standards-based way to hand work to an AI service instead of inventing a queue.
Storage Commitment & MSPS over HTTP	POST / GET	Storage Commitment Service (PS3.18 §13) and Modality Scheduled Procedure Step Service (§14)	`application/dicom+json`	Both exist in PS3.18 and both are commonly missing from products that advertise “full DICOMweb support”. Ask specifically.

DIMSE vs DICOMweb, and when you need a gateway

Why a gateway exists at allA gateway is simply a process that terminates DIMSE on the clinic side and speaks DICOMweb, or your own API, on the cloud side. It exists because the two transports carry the same objects but meet different halves of the world: scanners are fixed-function devices that will speak DIMSE for a decade, while a web product wants HTTP, TLS, and an identity model. The gateway is where that mismatch is absorbed, along with queueing and retry.

These are not competing standards. They are two transports for the same objects, aimed at different clients, and a real deployment usually runs both. Architecture pattern

Table 7.1: Transport comparison
Dimension	DIMSE (PS3.4 / 3.7 / 3.8)	DICOMweb (PS3.18)
Transport	A DICOM upper-layer protocol directly over TCP, port 104 or 11112 by convention.	HTTP/HTTPS on 443, through the same infrastructure as the rest of your product.
Session model	Long-lived association with negotiated presentation contexts.	Stateless requests. Every call stands alone.
Identity / auth	AE Title, optionally TLS with PS3.15 profiles and user-identity negotiation. Commonly deployed with neither.	Whatever your HTTP stack does: OAuth 2.0 bearer tokens, mTLS, API keys, tenant scoping in the path.
Firewall posture	C-MOVE and Storage Commitment results arrive on new inbound associations. Requires an inbound listener and per-peer configuration on both ends.	Outbound-only from the client. Traverses proxies, WAFs and CDNs without special cases.
Who initiates	Often the device: modalities push with C-STORE without being asked.	Almost always the consuming application, pulling on demand.
Query model	C-FIND against the Q/R Information Model; hierarchical, with optional relational extensions.	QIDO-RS, with hierarchical and relational resources distinguished explicitly per PS3.18 §10.6.
Retrieve semantics	C-MOVE (third-party delivery) or C-GET (same association).	WADO-RS: study, series, instance, frames, metadata, bulkdata, rendered, thumbnail.
Partial / frame retrieval	Not natively. You get whole instances.	Yes: frames and bulk data are addressable resources. This is what makes a 3,000-slice CT usable in a browser.
Rendered output	None. DIMSE moves objects, not pictures.	`/rendered` and `/thumbnail`, server-side.
Typical consumers	Modalities, legacy PACS, workstations, routers, gateways.	Browser viewers, mobile apps, AI services, product APIs, portals.
Configuration burden	High and pairwise: each peer needs the other’s AE Title, host and port, negotiated in advance.	Low: one base URL plus credentials.

Four product implications Architecture pattern

Existing modalities will speak DIMSE even when everything you build speaks DICOMweb. Plan for both from day one; retrofitting a gateway later is a migration, not a feature.
An edge gateway bridging DIMSE to a cloud service is the normal shape. It also becomes the place where local buffering, resend, and clinic-network diagnostics live. Scope it as a product, not a config file.
A viewer may require WADO-RS while the incumbent archive exposes only a proprietary retrieval API. That backend contract, not the viewer’s feature list, decides whether a viewer is replaceable. A viewer swap behind a proprietary image-delivery interface is a backend project wearing a frontend hat.
DICOMweb defines transport and payloads. It does not define your authorization model, tenant boundaries, rate limits, product workflow, or support process. Those are yours whichever transport you pick.

SOP Classes beyond images

What a SOP Class isA SOP Class (Service-Object Pair Class) is one object definition paired with the services allowed on it, named by a UID: “CT images, and the operations you may perform on them”. It is the unit of DICOM support. When a conformance statement says a product supports something, it means it accepts or sends that SOP Class UID as a specific role, so a product can happily store CT images and reject the Encapsulated PDF sitting next to them.

Storage SOP Classes live under the root 1.2.840.10008.5.1.4.1.1. Every UID below was read from the PS3.6 Annex A registry of DICOM UIDs (edition 2026c). The non-image objects are the ones that decide whether your data survives a viewer or archive replacement. Standard

Table 8.1: Commonly encountered Storage SOP Classes
Object	SOP Class UID	What it carries	Why a product leader cares
Computed Radiography Image Storage	`1.2.840.10008.5.1.4.1.1.1`	CR plate images.	Still arrives from older equipment. If your viewer’s decoder matrix only covers DX, CR studies fail on a Tuesday.
Digital X-Ray Image Storage: For Presentation	`1.2.840.10008.5.1.4.1.1.1.1`	DX images already processed for viewing.	This is what a radiologist should read. Confusing it with the processing variant is a real safety issue.
Digital X-Ray Image Storage: For Processing	`1.2.840.10008.5.1.4.1.1.1.1.1`	Raw, unprocessed detector data.	Displays as a flat, inverted-looking image in a naive viewer. Ideal for AI training, wrong for a clinician. Decide explicitly whether you store, route, or drop it.
Digital Mammography X-Ray Image: For Presentation	`1.2.840.10008.5.1.4.1.1.1.2`	FFDM images for display.	Mammography drags its own regulatory and display constraints along. Do not treat it as “another DX”.
CT Image Storage	`1.2.840.10008.5.1.4.1.1.2`	Classic single-frame CT slices, one instance per slice.	Instance counts, not gigabytes, drive metadata cost. A modern CT can be thousands of instances.
Enhanced CT Image Storage	`1.2.840.10008.5.1.4.1.1.2.1`	Multi-frame CT with per-frame functional groups.	One instance, thousands of frames. Halves your object count and breaks every parser written for classic CT.
MR Image Storage	`1.2.840.10008.5.1.4.1.1.4`	Classic single-frame MR.	Series-level semantics matter more than in CT: hanging protocols key off series description and sequence attributes.
Enhanced MR Image Storage	`1.2.840.10008.5.1.4.1.1.4.1`	Multi-frame MR with functional groups.	Same trade as Enhanced CT. Check your viewer and your AI pipeline separately.
Ultrasound Image Storage	`1.2.840.10008.5.1.4.1.1.6.1`	Single-frame ultrasound stills.	Often colour, often with burned-in annotation. See the de-identification table before you share one.
Ultrasound Multi-frame Image Storage	`1.2.840.10008.5.1.4.1.1.3.1`	Cine loops.	Cine playback, frame rate handling, and video transfer syntaxes are three separate viewer capabilities. Test all three.
Enhanced US Volume Storage	`1.2.840.10008.5.1.4.1.1.6.2`	3D ultrasound volumes.	Needs volumetric rendering, not a frame flipper. Rarely supported outside dedicated ultrasound products.
Secondary Capture Image Storage	`1.2.840.10008.5.1.4.1.1.7`	A screenshot of something, wrapped in DICOM.	The universal escape hatch and the universal information graveyard: annotations and measurements baked into pixels stop being data.
Grayscale Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.1`	Window/level, zoom, rotation, shutters, and graphic annotations, stored as a separate object referencing the images.	GSPS is how annotations survive a viewer replacement. A viewer that only writes annotations into its own database creates data you cannot export. Ask for read and write.
X-Ray Angiographic Image Storage	`1.2.840.10008.5.1.4.1.1.12.1`	XA runs, usually multi-frame.	Has its own presentation state class (`….11.5`). Generic GSPS support does not cover XA/XRF.
Nuclear Medicine Image Storage	`1.2.840.10008.5.1.4.1.1.20`	NM images, often multi-frame with detector/energy dimensions.	The retired `….1.1.5` class still appears in old archives. Migration tooling must handle both.
Positron Emission Tomography Image Storage	`1.2.840.10008.5.1.4.1.1.128`	PET images.	Almost always paired with CT in one study. Fusion display is a viewer capability you must test explicitly.
Parametric Map Storage	`1.2.840.10008.5.1.4.1.1.30`	Per-voxel derived quantitative values (perfusion, ADC, SUV maps).	The standards-based place to put continuous AI output instead of a colour-burned Secondary Capture.
Segmentation Storage	`1.2.840.10008.5.1.4.1.1.66.4`	Labelled binary or fractional voxel masks referencing source images.	The standards-based place to put an AI or contouring result so a different viewer can display it later.
Basic Text SR Storage	`1.2.840.10008.5.1.4.1.1.88.11`	Narrative structured report content.	The lowest-friction way to put a report inside the imaging record. Minimal structure, so minimal reuse.
Comprehensive SR Storage	`1.2.840.10008.5.1.4.1.1.88.33`	Fully coded structured reporting, including measurements with references to source instances.	TID 1500 Measurement Report (PS3.16) lives here. This is where machine-readable measurements belong.
Comprehensive 3D SR Storage	`1.2.840.10008.5.1.4.1.1.88.34`	As above, with spatial coordinates in a 3D frame of reference.	Needed when a measurement must point at a location in a volume rather than a pixel in a slice.
Key Object Selection Document Storage	`1.2.840.10008.5.1.4.1.1.88.59`	A titled, coded list of referenced instances.	KOS is how IOCM expresses a rejection, and how “key images” and manifests are expressed. See the change-management section for the codes.
X-Ray Radiation Dose SR Storage	`1.2.840.10008.5.1.4.1.1.88.67`	The RDSR: irradiation event dose data.	The object the IHE REM profile moves. If dose monitoring is in scope, this is the payload, not a PDF.
Encapsulated PDF Storage	`1.2.840.10008.5.1.4.1.1.104.1`	A PDF wrapped in a DICOM object.	Convenient for delivering a report inside the imaging record. The content is opaque: no coded findings, and identifiers hide inside the PDF where de-identification tools will not look.
Encapsulated STL / OBJ Storage	`1.2.840.10008.5.1.4.1.1.104.3` / `….104.4`	3D surface meshes for printing and planning.	Also exists. Relevant only if surgical planning or 3D printing is in scope, but it means “DICOM object” no longer implies “image”.

Transfer syntaxes and compression

What a transfer syntax isA transfer syntax is how the bytes are written: byte ordering, whether value representations are stated explicitly, and which compression, if any, is applied to the pixel data. Each combination has its own UID, and the pair of systems negotiates one per association or names one per request. It is orthogonal to the SOP Class: the same CT image can arrive uncompressed, JPEG 2000, or HTJ2K, and a receiver that accepts the object may still refuse the encoding.

A transfer syntax specifies byte ordering, VR encoding, and any compression. It is negotiated per presentation context in DIMSE and requested through Accept in DICOMweb. UIDs verified against the PS3.6 Annex A registry, edition 2026c. “Browser decode” describes what a mainstream browser can do without a WebAssembly codec. Standard

Table 9.1: Transfer syntaxes you will actually meet
Name	UID	Lossless?	Typical use	Browser decode
Implicit VR Little Endian	`1.2.840.10008.1.2`	Uncompressed	The DICOM default transfer syntax. Every SCP must support it, so it is the fallback when negotiation goes badly.	N/A: raw pixels, rendered by the viewer.
Explicit VR Little Endian	`1.2.840.10008.1.2.1`	Uncompressed	The sane storage default: self-describing VRs make parsing robust.	N/A: raw pixels.
Deflated Explicit VR Little Endian	`1.2.840.10008.1.2.1.99`	Lossless (whole data set)	Deflates the entire data set, not just pixel data. Occasionally used on slow links.	N/A: inflate first.
Encapsulated Uncompressed Explicit VR LE	`1.2.840.10008.1.2.1.98`	Uncompressed	Uncompressed pixels in the encapsulated (fragmented) format, so frame offsets work like the compressed syntaxes.	N/A
Explicit VR Big Endian (Retired)	`1.2.840.10008.1.2.2`	Uncompressed	Retired in PS3.5 (2011). Appears in old archives and in files from long-lived equipment.	N/A: byte-swap on ingest.
RLE Lossless	`1.2.840.10008.1.2.5`	Lossless	Run-length encoding. Cheap, weak, and still emitted by some ultrasound and NM devices.	No. Needs a decoder.
JPEG Baseline (Process 1)	`1.2.840.10008.1.2.4.50`	Lossy	The default lossy 8-bit syntax. Ubiquitous in ultrasound and in image-sharing exports.	Yes: native. The reason so many portals settle on it.
JPEG Extended (Process 2 & 4)	`1.2.840.10008.1.2.4.51`	Lossy	The default lossy 12-bit syntax.	No. Browsers do 8-bit baseline only.
JPEG Lossless, Non-Hierarchical (Process 14)	`1.2.840.10008.1.2.4.57`	Lossless	Older lossless JPEG. Common in legacy CR/DX archives.	No.
JPEG Lossless, First-Order Prediction (SV1)	`1.2.840.10008.1.2.4.70`	Lossless	The default lossless JPEG syntax. Very widely implemented; a safe archive target.	No.
JPEG-LS Lossless	`1.2.840.10008.1.2.4.80`	Lossless	Better ratios than lossless JPEG at low CPU cost. Popular in newer DX.	No.
JPEG-LS Lossy (Near-Lossless)	`1.2.840.10008.1.2.4.81`	Lossy (bounded error)	Near-lossless mode with a guaranteed maximum per-pixel error. Rare in practice.	No.
JPEG 2000 (Lossless Only)	`1.2.840.10008.1.2.4.90`	Lossless	The common lossless archive target for CT/MR/DX in cloud-era systems.	No: needs a WASM codec (viewers commonly bundle an OpenJPEG build).
JPEG 2000	`1.2.840.10008.1.2.4.91`	Lossy (can also carry lossless)	The workhorse lossy syntax for teleradiology and bandwidth-constrained delivery.	No: WASM codec.
JPEG 2000 Part 2 Multi-component	`1.2.840.10008.1.2.4.92` / `….93`	Lossless / lossy	Multi-component variants. Sparsely implemented; a good conformance-statement trap question.	No.
HTJ2K (Lossless Only)	`1.2.840.10008.1.2.4.201`	Lossless	High-Throughput JPEG 2000: same wavelet, an order of magnitude faster block coder. Emerging	No native decode; WASM codecs exist and are maturing. Re-check annually.
HTJ2K with RPCL Options (Lossless Only)	`1.2.840.10008.1.2.4.202`	Lossless	Progression-order-constrained variant that makes resolution-first streaming practical.	No. WASM.
HTJ2K	`1.2.840.10008.1.2.4.203`	Lossy (can also carry lossless)	The lossy HTJ2K syntax. The reason to care: decode speed at browser scale.	No. WASM.
JPEG XL Lossless / JPEG XL	`1.2.840.10008.1.2.4.110` / `….112`	Lossless / lossy	Registered in PS3.6 as a DICOM transfer syntax; a third recompression variant (`….111`) losslessly re-encodes existing JPEG. Adoption in imaging products is early. Emerging	Browser support varies by engine. Verify, do not assume.
MPEG-4 AVC/H.264 High Profile / Level 4.1	`1.2.840.10008.1.2.4.102`	Lossy	Video encoding for endoscopy, ultrasound cine, and recorded procedures. A “fragmentable” variant exists at `….102.1`.	Usually yes for playback, but not inside a DICOM container without a demuxer.
HEVC/H.265 Main Profile / Level 5.1	`1.2.840.10008.1.2.4.107`	Lossy	Higher-efficiency video. Also a Main 10 variant at `….108`.	Patchy. Verify per browser and per platform.
MPEG2 Main Profile / Main Level	`1.2.840.10008.1.2.4.100`	Lossy	Legacy video. You will still find it in older cardiology and endoscopy archives.	No.
SMPTE ST 2110-20 Uncompressed Video	`1.2.840.10008.1.2.7.1` / `….7.2`	Uncompressed	Real-time video transport for DICOM-RTV (PS3.22), progressive and interlaced.	No: this is a live-video path, not a storage path.

The four attributes that make lossy compression auditable

Table 9.2: Compression provenance attributes
Attribute	Tag	VR	What it records
Lossy Image Compression	`(0028,2110)`	CS	“00” or “01”: whether this image has ever been irreversibly compressed. Once set, it stays set through every later decompression.
Lossy Image Compression Ratio	`(0028,2112)`	DS (1-n)	The ratio, one value per compression step, which is how you detect that an image was compressed twice.
Lossy Image Compression Method	`(0028,2114)`	CS (1-n)	Which algorithm was used at each step, paired positionally with the ratio.
Derivation Description	`(0008,2111)`	ST	Free text describing how this object was derived from its source. Human-readable, not machine-parsable: do not build logic on it.

What the professional standard actually says about lossy compression Prof. guidance

The ACR–AAPM–SIIM Technical Standard for Electronic Practice of Medical Imaging (Revised 2022, Resolution 48; Amended 2023) defines diagnostically acceptable irreversible compression (DAIC) as irreversible compression that does not affect a particular diagnostic task, and permits its use under the direction of a qualified physician with no reduction in clinical diagnostic performance. It then says, in terms: “The ACR and this technical standard make no general statement on the type or amount of compression that is appropriate to any modality, disease, or clinical application to achieve the diagnostically acceptable goal.”

The standard also notes that reversible compression may always be used, and that DICOM defines fields for recording compression information and requires their persistence even after an image has been decompressed.

So: anyone who quotes you a universally safe ratio is quoting themselves.

Human health: Human health

Per the same ACR–AAPM–SIIM standard: FDA does not allow irreversible compression of digital mammograms for retention, transmission, or final interpretation, although irreversibly compressed prior studies may be used for comparison if the interpreting physician judges them acceptable. For other modalities FDA does not restrict compression, but requires manufacturers of devices that use irreversible compression to submit data on its impact on quantitative image-quality metrics. Regulatory (US)

Veterinary: Veterinary

No equivalent modality-specific compression prohibition applies, which means the constraint is entirely yours to set and defend. Radiographs dominate the case mix and are cheap to store losslessly, so the honest default is lossless in the archive and lossy only on the delivery path, with (0028,2110) written truthfully so nobody later mistakes a portal copy for the original. Recommendation

Four validation layers before you accept a compression or transcoding change

Layer 1Automated validityEvery object parses, instance counts match, UIDs preserved, pixel dimensions and photometric interpretation unchanged.

Layer 2Decoder matrixEach target viewer, each browser, each mobile client actually renders each transfer syntax you now emit. A valid object nobody can display is still an outage.

Layer 3Clinical quality reviewQualified readers compare originals and variants side by side on calibrated displays, on representative anatomy and pathology.

Layer 4Downstream AI behaviorRe-run every model on the new pipeline. Human visual acceptability does not establish AI equivalence: a change invisible to a reader can move a model’s output. Recommendation

IHE Radiology profiles and their maturity

What an IHE Radiology profile isIHE (Integrating the Healthcare Enterprise) is not a standards body and publishes no new protocol. It publishes integration profiles: named recipes saying exactly how to combine standards that already exist, mostly DICOM and HL7, to solve one workflow problem end to end. Each profile is written as actors (functional roles such as Image Manager or Acquisition Modality) exchanging numbered transactions. So “we support SWF.b” means the product implements some actor’s side of that recipe, which is why a profile claim without an actor role tells you nothing. RAD is the radiology domain; the maturity label below tells you whether the recipe is settled (Final Text) or still moving (Trial Implementation).

IHE profiles say how DICOM, HL7, FHIR and security standards are combined to solve one defined integration problem. Maturity is the whole point of reading this table: a Final Text profile is incorporated into the Technical Framework; a Trial Implementation supplement may still change. Status below is as published at profiles.ihe.net/RAD, Technical Framework Revision 23.0 (published 2025-08-08), read Sep 2026. This is the fastest-rotting table on the page. Re-check it quarterly.

Table 10.1: IHE Radiology profile index
Acronym	Full name	Problem it solves	Status
SWF	Radiology Scheduled Workflow	The backbone: order → scheduled procedure step → modality worklist → acquisition → MPPS → storage → storage commitment.	Final Text
SWF.b	Scheduled Workflow.b	The modernised Scheduled Workflow, added to the framework 2020-09-18 (Rev. 19.0). Ask which one a product implements.	Final Text
PIR	Patient Information Reconciliation	Reconciles studies acquired before or without a matching order: the unscheduled and emergency case.	Final Text
CPI	Consistent Presentation of Images	Same image looks the same on different displays: DICOM GSPS plus GSDF-calibrated displays.	Final Text
PGP	Presentation of Grouped Procedures	One acquisition that satisfies several ordered procedures, presented and reported separately.	Final Text
ARI	Access to Radiology Information	Query and retrieve of images and reports by non-radiology systems.	Final Text
KIN	Key Image Note	Flags selected images with a coded reason, using Key Object Selection Documents.	Final Text
SINR	Simple Image and Numeric Report	Reports as DICOM Structured Reports with references to the images they describe.	Final Text
CHG	Charge Posting	Moves procedure and charge information from the imaging workflow to billing.	Final Text
PWF	Post-processing Workflow	Worklists for post-acquisition work such as CAD and reconstruction.	Final Text
RWF	Reporting Workflow	Worklists and state for the reporting task itself, including draft, verify, and revise.	Final Text
ED	Evidence Documents	Moves non-image evidence (measurements, CAD results, dose) as first-class DICOM objects.	Final Text
PDI	Portable Data for Imaging	The interchange CD/USB: what must be on it so another site can actually read it.	Final Text
NMI	Nuclear Medicine Image	Constrains NM image encoding and display so cross-vendor NM actually works.	Final Text
MI	Mammography Image	Constrains mammography image encoding, laterality, and display conventions.	Final Text
DBT	Digital Breast Tomosynthesis	Extends mammography handling to tomosynthesis objects. Added 2016-09-09 (Rev. 15.0).	Final Text
IRWF	Import Reconciliation Workflow	Importing outside studies and reconciling their identity with the local record.	Final Text
TCE	Teaching File and Clinical Trial Export	Selecting, de-identifying, and exporting studies for teaching and trials.	Final Text
REM	Radiation Exposure Monitoring	Collects and reports irradiation event dose data, primarily via the X-Ray Radiation Dose SR. Added 2012-07-24.	Final Text
REM-NM	Radiation Exposure Monitoring for Nuclear Medicine	The NM equivalent, using the Radiopharmaceutical Radiation Dose SR. Added 2023-06-15 (Rev. 21.0).	Final Text
XDS-I.b	Cross-Enterprise Document Sharing for Imaging	Publishing and retrieving imaging manifests and objects across organisations. Added 2012-07-24.	Final Text
XCA-I	Cross-Community Access for Imaging	Cross-community imaging retrieval, one level above XDS-I.b. Added 2013-09-16.	Final Text
IOCM	Imaging Object Change Management	Communicates rejection and correction of already-distributed objects so downstream systems purge, hide, or re-fetch. Added 2014-07-30. The profile to ask about in every vendor call.	Final Text
MRRT	Management of Radiology Report Templates	An interoperable format for structured report templates so templates move between reporting systems. Added 2022-03-10 (Rev. 20.0).	Final Text
BIR	Basic Image Review	A minimum functional baseline for a review-only display. Incorporated into Rev. 22.0 (2024-06-25). It moved out of Trial Implementation.	Final Text
WIA	Web-based Image Access	Standards-based web access to imaging using DICOMweb. Incorporated into Rev. 22.0 (2024-06-25).	Final Text
WIC	Web-based Image Capture	Web-based capture and submission of images, including from encounter-based and mobile sources. Incorporated into Rev. 22.0 (2024-06-25).	Final Text
IID	Invoke Image Display	A simple, standard URL to launch an image display from an EHR or other application in the right patient and study context. Incorporated into Rev. 23.0 (2025-08-08).	Final Text
PERF	CT/MR Perfusion Imaging with Contrast	Consistency of perfusion acquisition and derived results. Incorporated into Rev. 23.0 (2025-08-08).	Final Text
AIR	AI Results	How AI results are encoded and communicated as DICOM objects. Revised 2025-08-08.	Trial Impl.
AIW-I	AI Workflow for Imaging	Task-based orchestration of AI work using Unified Procedure Step. Published 2020-08-06.	Trial Impl.
AIRA	AI Result Assessment for Imaging	Capturing human assessment of AI results, so feedback becomes data. Published 2025-06-12.	Trial Impl.
IMR	Interactive Multimedia Report	Diagnostic reports with interactive multimedia content, built on FHIR ImagingSelection. Published 2024-06-25. Its own page states IMR is NOT yet recommended for production use and that ImagingSelection is at maturity level 1.	Trial Impl.
IRA	Integrated Reporting Applications	Context and content synchronisation between reporting-time applications using FHIRcast. Published 2023-10-04. Its own page states IRA is NOT yet recommended for production use; it depends on FHIRcast 3.0.0, still under development.	Trial Impl.
XC-WADO	Cross-Community Web-Based Access to DICOM Objects	Cross-community retrieval over DICOMweb rather than DIMSE. Revised 2025-09-10.	Trial Impl.
MADO	Manifest-based Access to DICOM Objects	Manifest-driven access to imaging objects. Published 2026-03-16, the newest supplement in the domain.	Trial Impl.
EBIW	Encounter-Based Imaging Workflow	Imaging captured at the point of care without a prior order: the phone-camera and handheld-ultrasound problem. Revised 2025-06-19.	Trial Impl.
IDEP	Import and Display of External Priors	Getting outside priors in, reconciled, and on screen next to the current study. Published 2019-05-30.	Trial Impl.
IRWF.b	Import Reconciliation Workflow.b	Revised import reconciliation. Revised 2016-09-09.	Trial Impl.
MIMA	Multiple Image Manager/Archive	Several image managers and archives cooperating in one enterprise. Revised 2023-06-15.	Trial Impl.
CAM	Contrast Administration Management	Contrast injection records tied to the imaging record. Published 2021-04-30.	Trial Impl.
MAP	Management of Acquisition Protocols	Distributing and governing acquisition protocols across a fleet of scanners. Published 2024-06-25.	Trial Impl.
XRR-WD	Cross-Enterprise Remote Read Workflow Definition	Remote reading across organisational boundaries: the teleradiology shape. Published 2017-01-13.	Trial Impl.
XDR-I	Cross-Enterprise Document Reliable Interchange of Images	Push-based cross-enterprise image exchange. Revised 2019-08-09.	Trial Impl.
CDS-OAT	Clinical Decision Support Order Appropriateness Tracking	Carries appropriateness-criteria decision support results with the order. Revised 2019-04-25.	Trial Impl.
FUS	Image Fusion	Consistent handling of fused, registered image sets. Published 2006-04-13, twenty years in Trial Implementation, which is itself a signal.	Trial Impl.
IDR	Imaging Diagnostic Report	The next generation of imaging report exchange. Published for public comment 2026-03-08; the comment window closed 2026-04-09.	Public Comment
XDS-I	Cross-enterprise Document Sharing for Imaging	Superseded. Deprecated 2012-07-24 and replaced with XDS-I.b. If a product claims “XDS-I”, ask which one.	Deprecated
CXCAD	Chest X-Ray CAD Display	Retired 2024-06-25; see the IHE Radiology archive.	Retired
MAWF	Mammography Acquisition Workflow	Retired 2024-06-25; see the IHE Radiology archive.	Retired

The maturity ladder

Rung 1Public CommentAn emerging proposal open for feedback. Not implementation guidance. Do not put it in a contract.

Rung 2Trial ImplementationPublished for implementation testing and Connectathon use; may still change. Usually stable enough for production, except where the profile itself says otherwise, as IMR and IRA both do.

Rung 3Final TextIncorporated into the Technical Framework after implementation testing and review. This is what “we support profile X” should mean.

Rung 4Deprecated / RetiredHistorical. Still useful for reading legacy conformance claims, and for noticing when a supplier quotes one.

How to use this in a vendor call Recommendation

Ask three questions, in this order: which profiles do you claim, at which maturity, and in which actor role? Then: have you tested them at an IHE Connectathon or equivalent, and when? A profile claim without an actor role is not a claim: SWF has a dozen actors, and implementing one of them is not implementing the profile.

FHIR imaging resources, and where they stop

What FHIR is, in imaging termsFHIR is HL7’s modern standard: an ordinary REST API over a library of typed resources (Patient, ServiceRequest, ImagingStudy, DiagnosticReport), each with its own maturity level, which is why “we support FHIR” is not a claim until the resources are named. In an imaging product it carries the clinical context around the study: who the patient is, what was ordered, what the report says. It never carries pixels.

FHIR carries the clinical context around images; DICOM carries the images. The published current version at hl7.org/fhir is R5 (v5.0.0) as of Sep 2026; maturity levels below are each resource’s own, and N means Normative. Standard

Table 11.1: FHIR R5 resources in an imaging product
Resource	Maturity	Role	DICOM mapping	What it does not hold
Patient	N	The human subject and their identifiers.	Patient’s Name `(0010,0010)`, Patient ID `(0010,0020)`, Issuer of Patient ID `(0010,0021)`.	Animal patients need the veterinary attributes plus extensions; FHIR’s core Patient is built around a person.
Practitioner	5	Radiologists, referrers, technologists.	Referring Physician’s Name `(0008,0090)`, Requesting Physician `(0032,1032)`.	Credentials, licensure by region, and reading privileges: those are your workbench’s problem.
Organization	5	Clinic, hospital, imaging centre, corporate group.	Institution Name `(0008,0080)`.	Tenant boundaries, entitlements, and billing relationships.
Encounter	4	The visit or consultation the imaging belongs to.	No single clean DICOM equivalent; loosely related to admission and location attributes.	Anything about the imaging workflow itself.
ServiceRequest	4	The imaging order: what was requested, by whom, why.	Corresponds to the requested procedure carried in the Scheduled Procedure Step, e.g. Requested Procedure ID `(0040,1001)` and Accession Number `(0008,0050)`.	Scheduling state, worklist behavior, and modality assignment.
ImagingStudy	4	A reference to a DICOM study and its series and instances.	`identifier` carries the Study Instance UID as a `urn:oid:` value; `series.uid` → `(0020,000E)`; `series.instance.uid` → `(0008,0018)`; `series.modality` → `(0008,0060)`; `numberOfSeries` / `numberOfInstances`; `endpoint` points at the WADO-RS service.	The pixels. HL7 states plainly that the DICOM instances are not stored in the ImagingStudy resource and that a DICOM WADO-RS server or other storage mechanism is still required.
ImagingSelection	1	A selection of SOP instances, frames, or regions within one study and series: the thing a finding points at.	References Study/Series/SOP Instance UIDs and frames, with an Endpoint for retrieval.	Everything else. Maturity 1 means backward-incompatible change is likely; IHE IMR names this as a reason it is not yet production-ready. Emerging
DiagnosticReport	3	The findings and interpretation, with status, coded conclusions, references to images, and attached formatted content such as a PDF.	Conceptually parallels DICOM Basic Text SR / Comprehensive SR and Encapsulated PDF.	A reporting workspace: templates, macros, speech, peer review, critical-results tracking. None of that is in the resource.
Observation	N	Atomic measurements and findings, including AI-produced quantities.	Parallels DICOM SR measurement content; TID 1500 is the DICOM-side equivalent.	Provenance of the model that produced it, unless you add it deliberately.
Task	3	A unit of work: read this study, run this model, chase this critical result.	Parallels DICOM Unified Procedure Step (UPS / UPS-RS).	Assignment policy, capacity, escalation rules: the actual workbench logic.
DocumentReference	4	A pointer to a document: a signed report PDF, a scanned requisition, an outside record.	Loosely parallels Encapsulated PDF Storage and the XDS-I.b manifest idea.	The document’s content model. It is a pointer with metadata, nothing more.
Endpoint	2	The network address of a service: typically the WADO-RS base URL that makes an ImagingStudy retrievable.	The DICOMweb service root.	Authorization. An Endpoint tells you where, never whether you are allowed.

Two things to keep straight Standard Common practice

ImagingStudy is an index, not a store. Treating it as the DICOM object repository is the single most common FHIR-imaging mistake. You still need a WADO-RS server or equivalent behind it.

HL7 v2 is not history. Real sites still run ORM/OMI order messages and ORU^R01 result messages over MLLP, and will for years. If your delivery layer is FHIR-only, you have a gap that an interface engine will fill: budget for it as a component with an owner, not as a script.

Identity and the source-of-truth worksheet

The three identifiers people confuseThree different things identify a study, and mixing them up is the root of most reconciliation incidents. The patient identifier (MRN, or the PIMS record in veterinary) says who the subject is and is only unique within its issuing organisation. The accession number identifies one requested procedure and links order, study, and report; its uniqueness scope is whatever the issuing system decides. The Study Instance UID is globally unique, assigned once at acquisition, and must never be regenerated.

Identity is an architecture problem and a clinical-safety problem at the same time. Fill one row per entity before you compare vendors; the column that exposes trouble is always update owner. Tags verified against the PS3.6 data dictionary. Standard Recommendation

Table 12.1: Source-of-truth worksheet, pre-filled with DICOM representations
Entity	Stable identifier	DICOM representation	FHIR / API representation	Typical update owner	Correction workflow
Human patient	Enterprise MRN, plus an assigning-authority qualifier	Patient’s Name `(0010,0010)`, Patient ID `(0010,0020)`, Issuer of Patient ID `(0010,0021)`, Patient’s Birth Date `(0010,0030)`, Patient’s Sex `(0010,0040)`	Patient	EHR / RIS	Demographic update propagated to archive, worklist, viewer cache, and any delivered report
Animal patient	Clinic patient ID; rarely globally unique across a group	The same identity tags plus Patient Species Description `(0010,2201)`, Patient Species Code Sequence `(0010,2202)`, Patient Breed Description `(0010,2292)`, Patient Breed Code Sequence `(0010,2293)`, Patient’s Sex Neutered `(0010,2203)`	Patient with veterinary extensions	PIMS	Same as above, plus re-linking to the correct owner record
Owner / guarantor	Client or account ID in the practice or billing system	Responsible Person `(0010,2297)`, Responsible Person Role `(0010,2298)`, Responsible Organization `(0010,2299)`	RelatedPerson, or Organization for a corporate owner	PIMS / billing	Ownership transfer: the pet changes hands, the historical studies do not
Clinic / facility	Facility ID in the business system	Institution Name `(0008,0080)`, plus the calling AE Title in practice	Organization	Business system, not the archive	Clinic reassignment after a study lands on the wrong tenant
Modality / device	Asset tag plus Device Serial Number	Modality `(0008,0060)`, Device Serial Number `(0018,1000)`, calling AE Title	Device	Operations / field service	AE Title reuse after a device swap: a silent source of misrouted studies
Referring clinician	NPI or equivalent registry identifier	Referring Physician’s Name `(0008,0090)`, Requesting Physician `(0032,1032)`	Practitioner, PractitionerRole	Order system	Report recipient resolution and redelivery
Order / request	Order number in the ordering system	Requested Procedure ID `(0040,1001)`, Scheduled Procedure Step Sequence `(0040,0100)`	ServiceRequest	EHR / RIS / PIMS	Order–study mismatch: relink, do not retype
Accession	Accession number, unique within an assigning authority	Accession Number `(0008,0050)`	ServiceRequest.identifier	Order system	Reused or duplicated accession: detect at ingest, never merge silently
Study	Study Instance UID: globally unique, immutable, and the one identifier you must never regenerate	Study Instance UID `(0020,000D)`	ImagingStudy.identifier as `urn:oid:`	The modality that created it	Never changes. Corrections happen through IOCM and new objects, not by editing the UID
Series / instance	Series Instance UID, SOP Instance UID	`(0020,000E)`, `(0008,0018)`, with SOP Class UID `(0008,0016)`	ImagingStudy.series.uid, .instance.uid	The modality	Duplicate SOP Instance UID with different pixel bytes is a defect, not a merge candidate
Workflow case	Your own case ID	None. Do not invent private tags to carry product state	Task, plus your product API	Your platform	State machine with an audit trail and an admin-visible correction path
Report	Report ID plus version	Basic Text / Comprehensive SR, or Encapsulated PDF	DiagnosticReport	Reporting platform	Addendum or amendment, with propagation to every channel it was already delivered on
AI result	Result ID plus model name and version	SR (TID 1500), Segmentation, Parametric Map, or Secondary Capture, referencing source SOP Instance UIDs	Observation, or DiagnosticReport for a drafted narrative	AI orchestration layer	Invalidate and re-run when source objects change; never leave a result attached to a corrected study

AE Title is not a user credential Recommendation

An AE Title is a 16-byte identifier carried in an association request. It is unauthenticated, frequently guessable, and routinely reused when devices are replaced. Treating it as authorization means any host that can reach your listener and guess a string can push studies into a tenant. Use it for routing and diagnostics; use TLS, network segmentation, and real service identities for trust. Where legacy devices cannot do better, compensate at the network layer and write the compensating control down.

The three reconciliation flows

1. Worklist-matched (the good case)

Order created in EHR / RIS / PIMS; accession assigned.
Modality performs C-FIND against the Modality Worklist SOP Class and the technologist selects the scheduled step.
Identity, accession, and requested procedure are copied into the objects by the modality.
MPPS N-CREATE on start, N-SET on completion, so “study complete” is a fact rather than a timeout.
Ingest matches on Accession Number and Study Instance UID; nothing is typed twice.

2. Unscheduled / emergency (IHE PIR)

Acquisition happens first: trauma, after hours, or a device that cannot reach the worklist.
Objects arrive with temporary or blank identity and no matching order.
Ingest parks the study in an explicit unreconciled state: visible, queryable, and countable, never silently accepted.
An operator links it to the real patient and order; the platform emits corrected identity downstream.
IHE Patient Information Reconciliation is the profile that defines this exchange. Ask for it by name.

3. Wrong-patient discovered after read

Freeze: stop further distribution of the affected study.
Reject the mis-identified objects using IHE IOCM, expressed as a Key Object Selection Document with the code (113037, DCM, “Rejected for Patient Safety Reasons”).
Re-ingest under the correct identity; the original is retained, not deleted, unless retention policy says otherwise.
Issue a report amendment and re-deliver on every channel the original went out on.
Invalidate viewer caches, downstream copies, and any AI results derived from the study.
Record the whole sequence in the audit trail. This flow is the one that gets audited later.

Ingestion failure scenarios

What “ingestion” actually coversIngestion is not the DICOM receiver. Accepting an association and writing objects to disk is the easy tenth of the problem. The rest is knowing what a complete study looks like, detecting what never arrived, holding the objects that cannot be matched to a patient, retrying what failed, and putting a human in front of the exceptions. Every scenario below is a state your system has to be able to name.

A DICOM receiver is the first ten percent of ingestion. The rest is detection, state, and a human-usable exception path. If a scenario below has no admin surface in the product you are evaluating, it becomes an engineering ticket every time it happens. Common practice Architecture pattern

Table 13.1: What goes wrong at the door, and what the product must show
Scenario	Detection signal	Correct handling	Product surface needed
Duplicate SOP Instance UID, identical bytes	UID already indexed; content hash matches	Idempotent accept. Acknowledge and discard the copy.	A counter, not an alert. Retransmits are normal.
Duplicate SOP Instance UID, different bytes	UID already indexed; content hash differs	Quarantine both. This is a standards violation by the sender and must never be resolved by last-write-wins.	Conflict queue showing both objects, sender AE, and timestamps; a human decision recorded in the audit trail.
Partial study / late series	MPPS says complete but instance count is short; or no MPPS and the series simply stops	Hold the study in an incomplete state with an explicit timeout policy, and accept late arrivals without creating a second study.	Incomplete-study list with age, expected vs received counts, and a manual “close as complete” action.
Unknown calling AE Title	Association request from an AE not in configuration	Reject the association and log it with source IP. Do not auto-provision.	Unknown-sender log with a one-click path to register the device against a clinic: the most-used screen in support.
Unsupported transfer syntax	Presentation context proposed and not accepted, or a stored object your decoder cannot open	Either negotiate a syntax you do support, or accept and transcode on ingest with provenance recorded.	Per-device decoder matrix and a report of what each modality is actually sending.
Valid object no viewer can render	Parses fine, fails in the viewer	Treat as a first-class ingest defect. Automated validity is layer 1 of four.	Render-check sampling on new device types, with the failures visible to support rather than to a radiologist.
Unscheduled study with no order	No Accession Number match and no worklist entry	Park in the unreconciled state; run the PIR flow. Never guess the patient from a name string.	Reconciliation queue with search across order systems and a recorded operator decision.
Off-hours retransmit storm	Sustained inbound rate far above baseline from one AE	Backpressure and per-sender rate limiting, not a global queue that starves live traffic.	Per-sender throughput dashboard and a throttle a support engineer can apply without a deploy.
Clock skew between modality and server	Acquisition Date/Time `(0008,0022)` / `(0008,0032)` ahead of or far behind server time	Store the modality’s time as sent, record receipt time separately, and never sort clinical worklists by a device clock.	Skew report per device; a documented rule for which timestamp drives SLAs.
Wrong or missing character set	Specific Character Set `(0008,0005)` absent or inconsistent with the bytes present	Decode per the declared repertoire; flag mojibake rather than silently normalising a patient name.	Encoding-anomaly queue. Name corruption is an identity defect, not a display quirk.
Oversized multi-frame object	A single Enhanced CT/MR instance far above your per-object limit	Stream rather than buffer; keep frame-level retrieval available so the viewer never needs the whole object.	Object-size distribution by modality, and a size ceiling that alerts before it rejects.
Private tags stripped by a middlebox	Objects from one route lack private groups present on another route	Preserve private attributes end to end, or document exactly which are dropped and why.	Route-level attribute diff. Lost private tags surface months later as a missing feature in one viewer.

The question that separates a protocol endpoint from a product

Is ingestion an endpoint, or a managed workflow with visible state, auditability, recovery, and support tooling? Ask a vendor to show you the exception queue in the demo environment, with real failures in it. A product that cannot show you failures has not been operated at scale.

Repository, storage lifecycle, and scale

What a repository is, beyond a bucketA logical DICOM repository is object storage plus a metadata database plus the rules that keep them consistent: the bytes in one place, the index of what exists in another, and an agreement about which is authoritative when they disagree. Retention, tiering, holds, and deletion are properties of the repository, not of the storage vendor, and they are what turns a bucket into an archive you can be audited against.

A logical DICOM repository is not a bucket. Object storage plus a metadata database is an implementation of a repository; the responsibilities below are what makes it one. Architecture pattern

Twelve responsibilities of the repository

Study / series / instance / frame organisation
Searchable metadata index
Query and retrieval
Original object preservation, byte for byte

Integrity information (hashes or equivalent)
Lifecycle and retention state
Replication state
Correction and rejection history

Authorization context
Audit events, separate from operational telemetry
Import and bulk export
Recovery and index reconstruction

Storage tiers as a workflow decision, not a price decision

Table 14.1: Tier placement
Tier	Retrieval behavior	Cost shape	Where it must never sit
Hot	Immediate, millisecond-to-second first-byte latency.	Highest per-GB-month; low per-operation.	Nowhere: this is the safe default. The risk is paying hot prices for data nobody opens.
Cool / nearline	Immediate but with higher per-request cost and sometimes a minimum storage duration.	Lower per-GB-month, higher per-operation, early-deletion penalties.	Anything on the interactive prior-fetch path unless prefetch reliably runs ahead of the read.
Archive / cold	Rehydration required: minutes to hours, per object, at a per-object cost.	Lowest per-GB-month; retrieval and rehydration dominate the real bill.	Never in the synchronous clinical path. A radiologist waiting on rehydration is an outage with a billing line.

Anti-pattern: capacity price as the tier decision Recommendation

Object storage is not an archive, and per-GB price is not total cost. Model, at minimum: object count (a classic CT study is thousands of instances, so per-object charges scale with instances, not terabytes), per-operation transaction cost, rehydration latency and its per-object fee, index rebuild duration, egress at migration time, and the throughput you can actually achieve on a bulk export. In large imaging estates, file count and per-file metadata operations become the binding constraint long before network bandwidth does.

Scale anchors, and an honest note about them

There is no authoritative, current, cross-modality table of per-study data volumes. Vendor blogs publish one; the peer-reviewed literature mostly does not. Rather than invent ranges, here is what is actually citable, and it is thin. Model your own estate from your own archive.

Table 14.2: Citable scale figures (and the gaps)
Modality	Citable figure	Source
CT	82 images per exam in 1999 rising to 679 images per exam in 2010, single institution, all CT exams.	McDonald RJ et al., Academic Radiology 2015;22(9):1191–1198. Images per exam, not megabytes.
MR	164 images per exam in 1999 rising to 570 images per exam in 2010.	Same study. Both figures argue for modelling instance count as the primary scale driver.
Mammography with tomosynthesis	Approximately 1 GB per combination DBT / digital-mammography examination; approximately 250 MB after 4:1 lossless compression.	Conant EF, “Clinical Implementation of Digital Breast Tomosynthesis”, Radiologic Clinics of North America 2014.
Ultrasound (echocardiography)	21.5 ± 11.4 MB per study, 35.4 ± 12.3 clips per study, with DICOM JPEG lossy compression and editing.	Frommelt MA et al., Pediatric Cardiology 2002. Dated, and specific to a paediatric echo lab: treat as an order of magnitude, not a planning number.
Veterinary, mixed modality	4,237 studies archived between mid-2015 and July 2021 occupied roughly 1 TB, across a 16-slice CT, a CR system, and ultrasound video.	Costanza D et al., Veterinary Radiology & Ultrasound 2022;63(3). The paper reports the aggregate, not per-study or per-modality sizes.
CR / DX, dental, PET-CT	No citable per-study size found.	Widely repeated figures for these trace to vendor material. If you need numbers, measure your own archive and label them as yours.

The recovery question that reveals the architecture

If the metadata database disappeared but the imaging objects survived, could you reconstruct a complete and trustworthy archive? The answer depends entirely on what identity mapping, workflow state, correction history, and lineage exist outside the DICOM objects. If the honest answer is “no”, your database is a single point of clinical failure and should be treated with the same rigour as the objects themselves.

The exit test: require evidence before you sign

Bulk export of original objects. Byte-identical Part 10 files, not a re-encoded export.
UIDs preserved at study, series, and instance level, and private attributes preserved or explicitly documented as dropped.
Presentation states, structured reports, key object selections, and reports exported alongside the images: annotations that live only in a vendor database do not leave.
Audit and correction history exportable, including which objects were rejected and why.
Demonstrated throughput at production scale, in objects per hour, with the per-object charges named. “Export is supported” and “export finishes this decade” are different claims.

Ask for a signed statement of the export rate achieved in a real customer migration. A supplier that cannot produce one has not done a migration out.

PACS, VNA, and the market categories

What the category words meanPACS is the traditional bundle of archive, workflow, and diagnostic viewer sold as one product. VNA is an archive deliberately separated from any one viewer or department, so images outlive the application that created them. Neither term is defined by any standard, so both are claims rather than properties: a product prints the word on a datasheet and you find out at migration time whether it was true. Hence the capability questions below rather than the labels.

Suppliers use the same words for products with different boundaries. Define capabilities first, map suppliers to them second. For each category below, the third column is the one question that exposes the boundary in a demo. Architecture pattern

Table 15.1: Categories, what they usually are not, and the boundary question
Category	Typically includes	Do not assume it includes	The question that exposes the boundary
Full PACS	DICOM receipt, metadata index, query/retrieve, archive functions, routing, worklists, viewer access, administration, reporting integration, distribution.	Diagnostic-grade viewing, a radiologist workbench, customer onboarding, or a support toolset for your operations team.	“Which functions are native, which are licensed from another supplier, and which are optional modules I would be quoted separately?”
Managed cloud DICOM service	Receive, store, index, query, retrieve through documented DIMSE and DICOMweb interfaces, with a tenant model and audit hooks.	A PACS. No worklist, no workbench, no reporting, no portal, and often no DIMSE without your own gateway.	“Do you accept DIMSE directly, or do I operate a gateway, and who is on call for it?”
DICOM server / archive software	Storage, index, DICOM and DICOMweb services, administration, an extension model. Ranges from a single lightweight binary to an enterprise archive.	High availability, upgrade tooling, or commercial support, unless separately contracted.	“At what scale has this exact configuration been run in production, and by whom?”
Vendor-neutral archive (VNA)	Durable, application-independent storage and access across systems, lifecycle and retention management, and multi-consumer access.	Neutrality, despite the name. Metadata normalisation can be irreversible, and export can still be slow and expensive.	“Show me a bulk export that preserves original objects, UIDs, private tags, and presentation states, and tell me the per-object charge.”
Diagnostic viewer / workstation	Primary interpretation: hanging protocols, priors, window/level, measurements, cine, MPR/3D, multi-monitor, keyboard workflow.	Regulatory clearance for your intended use in your jurisdiction, or your specialty’s specific tools.	“Is this product intended and labelled for primary diagnostic interpretation, where, and under what conditions?”
Zero-footprint / clinical review viewer	Browser access, report-linked launch, simple tools, broad device compatibility, sharing controls.	Diagnostic use. “Zero-footprint” describes deployment, not intended use.	“What in the product stops a referring clinician from reading primarily on it: label, configuration, or nothing?”
Viewer SDK / rendering library	Building blocks: decoders, rendering, tools, annotation primitives.	A validated product, workflow, administration, support model, or upgrade path. You become the manufacturer of what you assemble.	“What exactly do I own once I ship this: validation, support, security patching, or all three?”
Radiologist workflow & reporting platform	Work queues, rule-based assignment, capacity management, reporting, speech, critical-result workflow, peer review, operational metrics.	Image viewing. It may embed, integrate with, or ignore your viewer.	“Is viewing integrated, embedded, or someone else’s problem, and who owns the failure when the two disagree?”
Image exchange & sharing	Organisation-to-organisation exchange, referral workflows, secure links, expiry and revocation, recipient authentication, audit history.	Long-term archive, or a complete referral workflow. Sharing is a transfer, not a relationship.	“After the link expires, where does the study live and who is responsible for it?”
Teleradiology service provider	Radiologists, workflow software, or both: coverage, subspecialty support, turnaround commitments, critical-result communication, quality governance.	Ownership of your customer relationship, your data portability, or your escalation path.	“When a case is late, who does my customer call, and how do I trace it across the supplier boundary?”

PACS vs VNA, decided by capability rather than label

Table 15.2: The nine questions that actually separate them
Capability	PACS emphasis	VNA emphasis
Stores original DICOM objects unmodified	Usually, but workflow needs sometimes win	Core promise: verify it, do not assume it
Normalises metadata	For its own workflow	Across sources, often irreversibly. Ask whether normalisation is auditable and reversible
Manages lifecycle, retention, and legal or clinical holds	Sometimes	Expected
Serves multiple viewers and multiple PACS	Rarely by design	The defining case
Exposes standards-based interfaces	Varies widely	Expected, and the point of buying one
Supports bulk export at production scale	Often weak	Should be strong; measure it
Preserves presentation states and derived objects	Varies	Expected
Owns workflow state	Yes: that is what it is for	No, and if it starts to, you have two PACS
Owns reporting state	Sometimes, via integration	No

Open-source components, with versions as of Sep 2026

Named as examples of what each category looks like when it is open source, not as recommendations or a shortlist. Versions move; re-check semi-annually. No commercial products are named anywhere on this page. Common practice

Table 15.3: Open-source imaging components (verified Sep 2026)
Project	What it is	Version (release date)	License
Orthanc	Standalone DICOM server with a REST API and a plugin model; often used as a lightweight archive or gateway.	1.13.0 (2026-08-15)	GPL-3.0-or-later core; some plugins AGPL-3.0-or-later
dcm4che / dcm4chee-arc-light	Java DICOM toolkit and command-line utilities; the arc-light project is a full archive built on it.	5.35.1 (2026-08-24)	MPL-1.1 or GPL-2.0-or-later or LGPL-2.1-or-later (tri-licensed in source headers)
DCMTK	C++ toolkit and CLI tools implementing large parts of the standard; the reference implementation many products embed.	3.7.0 (2026-01-23)	BSD-3-Clause (some modules carry separate terms)
pydicom	Pure-Python library for reading, modifying, and writing DICOM files. The usual choice for data engineering and AI pipelines.	3.0.2 (2026-03-19)	MIT
fo-dicom	.NET DICOM library covering parsing, networking, and imaging.	5.2.6 (2026-03-30)	MS-PL
OHIF Viewer	A web-based zero-footprint viewer application built on Cornerstone3D.	3.12.14 (2026-09-03)	MIT
Cornerstone3D	The JavaScript rendering, tooling, and annotation library underneath OHIF. A library, not an application.	5.8.9 (2026-09-03)	MIT
Weasis	Java desktop DICOM viewer, also launchable from a web context.	4.7.3 (2026-08-25)	EPL-2.0 or Apache-2.0

Open source does not mean zero cost. Adopting any of these transfers security patching, upgrades, operation, clinical validation, and support to you. That is often the right trade. It is never a free one.

Viewer tiers, architectures, and evaluation

Why “viewer” is three productsA thumbnail preview, a review viewer for a referring clinician, and a diagnostic workstation for primary interpretation are all called viewers, and they sit in different regulatory, display-calibration, and performance situations. Most imaging products need at least two of the three. Decide which tier you are building before you compare features, because the obligations differ more than the screenshots do.

Most products need more than one viewing experience, and the differences are regulatory and ergonomic before they are technical. Calling all three “the viewer” is how a review tool ends up being used for primary interpretation.

Three tiers

Table 16.1: Viewer tiers
Tier	Intended user	Regulatory posture (US)	Display requirement	Must-have tools
Diagnostic viewer	The interpreting radiologist doing primary reads.	A claim of intended use for primary diagnostic interpretation is a medical-device claim in human health. Determine the pathway before you build or market it. Regulatory (US)	Displays calibrated to the DICOM Grayscale Standard Display Function (PS3.14). The ACR–AAPM–SIIM standard (Revised 2022) says L′_max for diagnostic interpretation displays should be at least 350 cd/m² with L′_min 1.0 cd/m²; for mammography, at least 420 and 1.2. Prof. guidance	Hanging protocols, priors, window/level presets, measurements with correct calibration, cine, MPR/MIP where the modality needs it, multi-monitor, full keyboard workflow, persistent presentation state.
Clinical review viewer	Referring clinicians and veterinarians, checking a study they did not order the read on.	Review-only. The distinction must be visible in the product, not just in the contract. IHE Basic Image Review (Final Text) defines a functional baseline worth quoting.	The same ACR–AAPM–SIIM standard puts displays used for other purposes at L′_max at least 250 cd/m² with L′_min 0.8 cd/m². In practice you cannot control the device. Prof. guidance	Fast browser access, report-linked deep launch (IHE IID is the standard way), simple pan/zoom/window, sharing controls, and an unmistakable “not for primary diagnosis” state.
Customer or patient viewer	The pet owner, the patient, the referring practice’s front desk.	Must avoid any presentation that could be mistaken for a supported diagnostic use.	Whatever phone they have. Assume uncalibrated, assume daylight.	Simple navigation, strong permissions, clear context, explicit download and sharing policy, and an audit record of who looked.

Four architectures

Table 16.2: Viewer architecture trade-offs
Architecture	Strength	Weakness	Bandwidth	Offline
Thick client / desktop workstation	Full performance, GPU access, multi-monitor, deep OS integration, local caching of priors.	Deployment, versioning, and per-device support. Every upgrade is a field operation.	Bulk transfer, usually prefetched ahead of the read.	Yes, with local cache.
Server-side rendered zero-footprint	Any device, thin client, no local decode. Pixel data never reaches the endpoint, which some security teams love.	Server cost scales with concurrent readers; interaction latency is a network round trip; measurement fidelity depends on the render pipeline.	Continuous, low volume, latency-sensitive.	No.
Browser-side decode over DICOMweb	Real pixel data in the client via WASM codecs and WebGL; frame-level retrieval keeps large studies usable; scales with the client, not your servers.	Your decoder matrix becomes a compatibility surface. Every transfer syntax you accept must have a working client-side codec.	Bursty, high volume at study open; benefits from HTJ2K and progressive retrieval.	Partially, with a service worker and a cache.
Hybrid (metadata + thumbnails server-side, pixels client-side)	Fast worklists and previews without paying full decode cost; the usual real answer.	Two rendering paths to keep consistent. A thumbnail that disagrees with the full render is a support ticket you cannot reproduce.	Mixed.	Partially.

Viewer evaluation matrix: twenty criteria

Work through this with the product open, not with a datasheet. Criteria are ordered by how often they turn out to be the deal-breaker. Recommendation

Table 16.3: Viewer evaluation criteria
#	Criterion	What to actually test	Why it decides things
1	Backend contract	Does it retrieve over standard WADO-RS / QIDO-RS, or a proprietary image-delivery API?	This single answer decides whether the viewer is replaceable. A proprietary delivery contract turns a viewer swap into a backend rebuild.
2	Transfer-syntax decoder coverage	Feed it every syntax in your archive, including RLE, JPEG-LS, JPEG 2000, HTJ2K, and video.	A gap here is invisible until the one device that emits it sends a study on a Friday night.
3	GSPS read and write	Create an annotation, save, reopen in a different product.	Read-only GSPS means annotations enter and never leave. This is the most common quiet lock-in in imaging.
4	Annotation storage location	Where does an annotation physically live: a DICOM object, your database, or browser storage?	Browser-local or proprietary-only annotations are unexportable and unauditable.
5	Measurement calibration	Measure a phantom of known size on CR/DX, CT, and US.	Pixel Spacing `(0028,0030)` and Imager Pixel Spacing `(0018,1164)` are different attributes. Projection radiography has detector spacing, not patient-plane spacing, so an uncalibrated length on a radiograph is wrong by the magnification factor. Confirm which attribute the viewer uses.
6	Hanging protocols	Open a multi-series MR and a comparison study without touching the mouse.	Hanging protocol quality is the largest single lever on radiologist throughput.
7	Priors auto-fetch	Open a study whose prior is on a cool or archive tier.	This is where storage tiering meets the reading room. If prefetch does not beat the reader, you have designed a wait.
8	MPR / MIP / 3D	Reconstruct from a real thin-slice CT, not a demo dataset.	Determines whether a second advanced-visualisation product is in your budget.
9	Multi-frame and cine	Play an ultrasound loop and an Enhanced CT object; check frame rate and scrub behavior.	Multi-frame handling and cine playback are separate implementations and fail separately.
10	Window / level presets	Per-modality and per-body-part presets, keyboard-switchable, persisting per user.	Missing presets cost seconds per image, which is hours per week per reader.
11	Multi-monitor behavior	Three displays, one portrait, mixed DPI.	Browser viewers frequently degrade here in ways that never appear in a demo.
12	Embedding and auth handoff	Embed it in your application; pass a session, not a shared secret.	Iframe embedding plus a token exchange is the normal integration; some products only support their own login.
13	Deep linking	Launch directly to a study, series, and instance from a report or an EHR.	IHE IID (Final Text) defines the standard way. Ask for it by name instead of accepting a bespoke URL scheme.
14	Keyboard accessibility	Complete a read using only the keyboard; check focus visibility throughout.	Both an accessibility obligation and a speed feature. Radiologists live on the keyboard.
15	Structured reports and segmentations	Display a Comprehensive SR and a Segmentation object produced elsewhere.	Determines whether AI results can be shown without a bespoke overlay pipeline.
16	Audit of who viewed	Open a study, then find the access event in an exportable audit log.	Required for real access review. Frequently absent in review-tier viewers.
17	Print and export	Export to DICOM, to a report attachment, and to an image file, and check what metadata goes with each.	Export paths are also data-leak paths. Test them for de-identification behavior at the same time.
18	Browser, GPU, and display requirements	The real matrix, including the oldest machine in your customer base.	“Modern browser” is not a requirement. Get versions and GPU capabilities in writing.
19	Mobile behavior	Open a large study on a phone on a mobile network.	Owners and referrers will do this whatever your intended use says. Decide deliberately what they see.
20	Error telemetry and upgrade path	Force a decode failure and a retrieval failure; see what you learn and where.	A viewer that fails silently makes every incident a user-reported one.

Human health: Human health

Diagnostic display calibration is a documented, audited programme, not a setup step: the ACR–AAPM Technical Standard for Diagnostic Interpretation Displays (Revised 2024, effective 1 July 2024) and the ACR–AAPM–SIIM electronic-practice standard cover luminance response, calibration, quality control, pixel pitch, and ambient light. If you sell into hospitals, someone will ask you how your viewer supports that programme. Prof. guidance

Veterinary: Veterinary

General-purpose viewers do not ship veterinary measurements, and they are not optional in practice. Verified examples with published methods: Vertebral Heart Score (Buchanan & Bücheler, JAVMA 1995, reference range 9.7 ± 0.5 vertebrae, under 10.5 in 98% of normal dogs); Vertebral Left Atrial Size (Malcolm et al., JAVMA 2018); tibial plateau angle for TPLO planning (Reif et al., Veterinary Surgery 2006); Norberg angle and the PennHIP distraction index for hip dysplasia (Smith et al., JAVMA 1990). The angle of lateral opening is real but belongs to implant assessment, not native anatomy: it is acetabular cup orientation after total hip replacement (Dyce et al., Veterinary Surgery 2001). Budget these as extensions with clinical review, and check the viewer’s tooling model before you commit.

Anti-pattern: selecting a viewer from screenshots

Every viewer looks capable in a curated demo on a curated dataset. Insist on your own studies, your own transfer syntaxes, your own network, and a round trip of annotations into a second product. The failures that matter are all invisible in a screenshot: a decoder gap, read-only presentation states, a proprietary delivery API.

The radiologist workbench as a state machine

What a workbench isThe workbench is the radiologist’s working surface, as distinct from the viewer inside it: what to read next, in what order, with which priors and prior reports loaded, and what happens when a study is escalated, reassigned, or handed to the next shift. Almost none of it is standardised, which is why it is invisible in a standards conversation and is where most of the build cost and most of the differentiation live.

In a teleradiology or consultation product the back office is not a worklist beside a viewer; it is often the differentiating capability. Model it as explicit states with entry and exit conditions, then instrument every transition. Architecture pattern

Table 17.1: Case states from arrival to closure
State	Entry condition	Exit condition	Metric	Failure mode
Received	First object of a study lands and is indexed.	Ingest validation passes and identity is resolved or explicitly parked.	Ingest latency; percentage parked as unreconciled.	Silent acceptance of a study nobody can attribute to a patient.
Reconciled	Study is linked to a patient, clinic, and order or consultation.	Linkage is confirmed and auditable.	Manual-reconciliation rate per clinic.	Guessed matches on name similarity. Never do this automatically.
Ready	All expected series present (MPPS or a completeness rule), priors fetched, order matched, AI complete or explicitly skipped.	The case is genuinely readable.	Time-to-ready; percentage of reads started on incomplete studies.	A partial study presented as complete. The single highest-severity workflow defect on this page.
Assignable	Ready, plus a routing decision is possible: modality, subspecialty, region, licence, customer SLA.	A qualified reader is available and eligible.	Queue depth by subspecialty; percentage unassignable.	Credential and region constraints discovered at assignment time rather than encoded in the rules.
Assigned	Rules or a coordinator allocate the case to a named reader.	The reader opens it.	Time-to-assignment; reassignment rate.	Two readers holding the same case, or a case held by someone who logged off.
In interpretation	Viewer open, priors loaded, history and AI results in the same workspace.	Findings dictated or entered.	Time-in-state; abandonment rate.	Context switching to find the order, the history, or the prior: the quiet productivity killer.
Reporting	Findings captured; template applied.	Report signed as preliminary or final.	Dictation-to-signature time.	Report state that exists only inside the reporting tool, invisible to the rest of the platform.
Critical result pending	A finding requires non-routine communication.	Documented receipt by the responsible clinician.	Time-to-acknowledged; percentage unacknowledged past threshold.	“Sent” recorded as “communicated”. They are not the same event.
Delivered	Final report released.	Confirmed receipt on every contracted channel.	Delivery success rate per channel; retry depth.	Silent delivery failure: the customer finds out before you do.
QA / peer review	Case sampled by policy, or flagged by a disagreement.	Review complete and recorded.	Sampling rate; discrepancy rate.	Peer review that is invisible to the workflow and therefore never happens.
Amended	New information, a correction, or an identity change after release.	Amendment issued and propagated everywhere the original went.	Amendment rate; propagation completeness.	An amendment that reaches the portal but not the EHR: two versions of the truth in the same practice.

Reporting sub-capabilities

Table 17.2: What a reporting layer has to do
Capability	Detail	Standards hook
Structured vs free text	Structured findings are reusable, comparable, and codeable; free text is faster to write and preferred by many readers. Real systems support both and pay for the ambiguity.	DICOM Comprehensive SR; FHIR DiagnosticReport with coded conclusions.
Templates	Per modality, body part, and customer, versioned, and editable without a vendor services engagement.	IHE MRRT (Final Text) defines an interoperable template format so templates can move between systems.
Macros and speech	Voice recognition with a domain vocabulary, plus text macros. Latency and accuracy here dominate perceived product quality for readers.	None. This is a product capability, not a standards one.
Critical-results communication	Non-routine communication when a finding needs urgent action, with documented receipt and escalation if unacknowledged.	ACR Practice Parameter for Communication of Diagnostic Imaging Findings (Revised 2025, Resolution 9) covers final and preliminary reports, non-routine communication, and communication policies. ACR states its practice parameters are educational tools, not a legal standard of care. Prof. guidance
Addendum vs amendment	An addendum adds to a final report; an amendment changes it. Model them as different transitions with different notification rules: conflating them destroys the audit story.	FHIR DiagnosticReport status values; DICOM SR verification and completion flags.
Discrepancy between preliminary and final	ACR guidance is explicit that changes between preliminary and final interpretations should be reported in a way that reasonably ensures receipt, and that the discrepancy is documented in the final report.	Same ACR parameter. Build the workflow, not just the field. Prof. guidance

Report lifecycle and delivery channels

Encoding, then deliveryTwo separate problems hide in the word “report”. Encoding is how the findings are represented: a DICOM Structured Report, an encapsulated PDF, an HL7 v2 ORU^R01, a FHIR DiagnosticReport. That part is largely standardised. Delivery is getting the released report to every system and person that needs it, proving it arrived, and tracking turnaround. That part is yours, and it is where products fail.

Report encoding is largely standardised. Turnaround visibility, delivery reliability, escalation, and correction propagation are not, and that is where the product experience lives.

Report status lifecycle

State 1DraftVisible only to the author. Not a clinical artifact; must not be deliverable by accident.

State 2PreliminaryReleased before final sign-off, typically after hours. Must be labelled as preliminary everywhere it lands.

State 3FinalSigned by the interpreting physician. The official interpretation, archived alongside the study.

State 4AddendumAdds information without changing the original. The original remains readable and intact.

State 5Corrected / amendedChanges the original. Requires active re-delivery on every channel the original went out on, not a quiet database update.

State 6Entered in errorRetracted. Every downstream copy must be marked, not silently deleted: deletion destroys the audit trail that proves you handled it.

Table 18.1: Delivery channels
Channel	What it carries	Image linkage	Correction propagation
HL7 v2 `ORU^R01` over MLLP	Observation result message with the report text in OBX segments. Still the workhorse in hospitals.	By accession number and study identifiers in OBR; images are elsewhere.	Result status field plus a corrected message. Whether the receiving system shows the correction is its decision, not yours: verify per interface.
FHIR `DiagnosticReport`	Status, coded conclusions, narrative, references to images, and attached formatted content such as a PDF.	`imagingStudy` reference, and in R5 an ImagingSelection can point at exactly the instances a finding is about.	Resource versioning plus status change. Cleaner than v2, and far less widely deployed.
DICOM Basic Text SR	Narrative report content inside the imaging record itself.	Native: it lives in the study.	A new SR object plus SR verification/completion state. Old copies persist unless you also run IOCM.
DICOM Comprehensive SR	Coded findings and measurements with explicit references to source SOP Instances.	Native and instance-precise.	As above. This is the right home for machine-readable measurements.
Encapsulated PDF	The signed report as a PDF wrapped in DICOM.	In the study, but opaque to any tool that reads DICOM attributes.	New object, prior one rejected via IOCM. Note that identifiers inside the PDF are invisible to attribute-level de-identification.
Customer / owner portal	The report, and often the images through a review or customer-tier viewer.	Deep link into the viewer: IHE IID is the standard mechanism.	You control it fully. This is the channel where amendments are easiest to get right, so get it right.
Secure email link	A notification and an authenticated link, not the report itself.	Link into the portal.	Expire and reissue. Never email a report as an attachment to an unverified address.
Image exchange / referral	Manifest plus objects to another organisation.	IHE XDS-I.b / XCA-I manifests; XC-WADO for a DICOMweb path (Trial Implementation).	Hardest case: the copy is outside your control. Contract for notification and record what you sent.
Fax	A rendered report image. Still real in many referral networks.	None.	None: you re-send and hope. Track it as a delivery channel with a known correction gap rather than pretending it does not exist.

AI orchestration

What orchestration means hereThe model is the small part. Orchestration is everything around it: deciding which studies are eligible, routing them to the right model, tracking the job, and filing the output as an object the rest of the system understands, typically a DICOM SR, a presentation state, or a secondary capture, with the model and version recorded. You own that layer whether you build the models or buy them.

Separate four decisions that are usually collapsed into one: buy or build the model; buy or build the orchestration; how results are encoded and versioned; and what validation and monitoring you owe.

Table 19.1: AI use cases and what each demands from the platform
Use case	Where it sits in the workflow	What the platform must provide
Triage and prioritisation	Between Ready and Assignable.	Sub-minute turnaround, a defined behavior when the model times out, and a worklist that visibly distinguishes “model says urgent” from “human says urgent”.
Detection	Before or during interpretation.	Overlay display in the diagnostic viewer, a way for the reader to accept or reject each finding, and storage of that decision as feedback data.
Quantification and measurement	During interpretation, or as a background job.	Results encoded as SR or Parametric Map with units and references, not as numbers in a side table.
Quality checks and protocoling	At acquisition or immediately after.	A feedback path to the technologist while the patient is still on the table, otherwise the finding is archaeology.
Worklist routing	At assignment.	Explainable routing. A reader who cannot see why a case reached them will not trust the queue.
Report drafting	At reporting.	Unambiguous draft status, an audit trail of what the model wrote versus what the physician kept, and a hard block on unattended release.

Orchestration platform checklist

Model and configuration version tracking, per result
Study and series selection rules
Preprocessing, made explicit and reproducible
Input provenance: exactly which SOP Instances went in

Result storage in a standards-based object
Viewer overlay path
Human review, override, and feedback capture
Reprocessing when source objects change

Performance monitoring against a stable reference set
Failure handling and timeouts that do not stall the queue
Separation of model telemetry from clinical audit
A rollback path to a previous model version

Where AI results should live

Table 19.2: Result encoding options
Encoding	Best for	Trade-off
DICOM SR, TID 1500 Measurement Report	Measurements and coded findings with explicit references to source instances.	The most reusable option and the most work to produce. TID 1500 is defined in PS3.16.
Segmentation Storage `1.2.840.10008.5.1.4.1.1.66.4`	Voxel-level masks: lesions, organs, contours.	Displayable in any viewer that supports Segmentation, which is fewer than you would hope. Test first.
Parametric Map Storage `1.2.840.10008.5.1.4.1.1.30`	Continuous per-voxel values: probability maps, perfusion, SUV.	Correct and rarely supported. Verify the display path before committing.
Secondary Capture	A rendered picture of the result when nothing else will display.	The finding stops being data. Acceptable as a fallback alongside a structured object, never as the only encoding.
FHIR Observation	Getting a quantitative result into the clinical record next to labs and vitals.	Excellent for clinical context, weak for image-precise references unless paired with ImagingSelection (maturity 1).

The rule, whichever encoding you pick: every AI result references the source SOP Instance UIDs it was computed from, and names the model and version that produced it. IHE AIR (AI Results) and AIW-I (AI Workflow for Imaging) are the Trial Implementation profiles that describe this; AIRA covers capturing human assessment of the results.

Anti-pattern: AI output as unversioned JSON

A result blob with no model version, no source instance references, and no place in the imaging record cannot be audited, reproduced, compared across model versions, or displayed by any viewer but yours. When the model is retrained, every historical result becomes uninterpretable. Encode results as DICOM objects or FHIR resources with provenance, and keep the blob as a debugging artifact if you want it.

Regulatory context Regulatory (US, human health)

FDA maintains a public list of AI-enabled medical devices authorised for marketing in the United States. Counted in Sep 2026, that list held 1,524 device entries, of which 1,164 (76%) sit under the Radiology panel: imaging is where AI device authorisation actually happens. The page content was current as of 16 Jun 2026 with the most recent decision dated 30 Mar 2026. FDA states plainly that the list is not a comprehensive resource: entries were identified largely from AI-related terms in marketing-authorisation summaries. Treat the count as a landscape signal, not a register.

These materials apply to human medical devices in the United States. Veterinary products need their own analysis. See the scope note in the security section. EU MDR and the EU AI Act also apply to products placed on the EU market and are not covered here.

Security, privacy, and clinical safety

The four separate problemsSecurity in imaging is four problems that get collapsed into one word. Transport: is the traffic encrypted, and is the peer authenticated. Access: who may open which study, which DICOM answers barely at all, since an AE Title is an identifier and never a credential. Audit: what was recorded, in what format, and where it was sent. De-identification: which attributes were removed or replaced, under which PS3.15 profile and options. A product can be strong at one and absent at the others.

Scope, stated once

Veterinary imaging generally falls outside HIPAA and outside FDA medical-device premarket scope. HIPAA’s Security Rule protects electronic protected health information about people. FDA states that it does not require a 510(k), PMA, or any premarket approval for devices intended for animal use, and that manufacturers of animal devices are not required to register establishments or list those devices, while remaining responsible for ensuring they are safe, effective, and properly labelled. Verify for your jurisdiction, and for any human-health data your system also touches: a platform serving both is inside scope for the human side. This note is not repeated per row. Regulatory (US)

NIST SP 1800-24 control areas

NIST SP 1800-24, Securing Picture Archiving and Communication System (PACS): Cybersecurity for the Healthcare Sector (December 2020), is the primary public reference for PACS security. It notes that FDA classifies PACS as a Class II device. Use its capability areas as your checklist. Regulatory context

Capability areas from SP 1800-24

Access control
Identification and authentication
Configuration management
Contingency planning
Risk assessment
System and communications protection
System and information integrity

Technical focus areas the guide demonstrates include network segmentation and microsegmentation, behavioural analytics, encryption, multifactor authentication, cloud storage, and privileged account management.

The operational checklist that follows from it

Asset and data-flow inventory: every modality, gateway, and AE Title
Central identities; no shared logins on workstations
Least privilege, plus tenant and clinic isolation you can demonstrate
Service identities distinct from human ones
Network segmentation between modality VLANs and everything else
TLS in transit for DIMSE as well as HTTP; encryption at rest
Secrets and certificate lifecycle with rotation that has actually been rehearsed
Audit logging kept separate from operational telemetry
Controlled, time-boxed, audited vendor remote access
Backups tested by restoring, including index reconstruction

DICOM PS3.15 security and confidentiality profiles

Table 20.1: PS3.15 profiles worth naming in a requirement
Profile	Where	What it gives you
Basic TLS Secure Transport Connection Profile	PS3.15 B.1	TLS for DIMSE associations. The baseline answer to “is DICOM traffic encrypted?”
BCP 195 TLS Secure Transport Connection Profiles	PS3.15 B.9–B.13	The modern family, including non-downgrading and RFC 8996/9325 variants. Ask which one a product implements, not merely “TLS”.
Basic User Identity Association Profile	PS3.15 B.4	Carries a user identity in association negotiation. Also B.5 with a passcode, B.6 Kerberos, B.7 SAML assertions.
Audit Trail Message Format Profile (ATNA)	PS3.15 A.5	The DICOM audit message schema and the specific audit events. Pair with A.6 SYSLOG-TLS transmission.
Basic Application Level Confidentiality Profile	PS3.15 E.2	The core de-identification profile: which attributes are removed, replaced, or retained.
Online Electronic Storage Secure Use Profile	PS3.15 A.1	Constraints for using DICOM objects held in online storage, including digital signature handling.

The eleven Basic Application Level Confidentiality Options

These are the named options in PS3.15 Annex E.3. When a supplier says “we de-identify”, this is the vocabulary to hold them to: option by option, because each changes what the data is usable for afterwards. Standard

Clean Pixel Data: remove burned-in identifiers from the pixels themselves
Clean Recognizable Visual Features: defeat re-identification from face or body renderings
Clean Graphics: remove identifying overlays and graphic annotations
Clean Structured Content: remove identifiers inside SR content
Clean Descriptors: scrub free-text description attributes, where identity loves to hide
Retain Longitudinal Temporal Information: keep dates, either fully or with a consistent shift

Retain Patient Characteristics: keep age, sex, weight, and similar research-relevant attributes
Retain Device Identity: keep equipment identifiers, which matters for imaging-physics research
Retain UIDs: keep Study/Series/SOP Instance UIDs so data can be re-linked later
Retain Safe Private: keep private attributes known to be free of identity
Retain Institution Identity: keep the institution, which is often itself identifying

Removing or replacing attributes does not by itself guarantee de-identification. DICOM material is explicit about this. De-identification is a process shaped by purpose, recipients, sharing context, regulation, and re-identification risk: the profile options are one control within it, not the whole of it.

Where identifying information actually hides

Table 20.2: Ten hiding places, and what to do about each
Location	Why it is missed	Control
Standard attributes	Nobody misses these. They are the easy 60%.	Apply the Basic Application Level Confidentiality Profile with an explicit, reviewed option set.
Private attributes	Vendor-defined, undocumented, and frequently full of identity, site names, and operator strings.	Remove by default; retain only what you have inspected. Retain Safe Private is a decision, not a default.
Burned-in pixels	Ultrasound and secondary capture routinely burn name, date, and clinic into the image. `Burned In Annotation (0028,0301)` tells you the sender’s claim, and senders are often wrong.	Clean Pixel Data option plus automated detection. Never trust the flag alone.
Overlays	Overlay planes are a separate mechanism from pixel data and survive naive pixel scrubbing.	Clean Graphics option; verify visually after processing.
Structured reports	SR content trees carry names, dates, and free text inside coded structures.	Clean Structured Content option. Test with a real SR, not an empty one.
Encapsulated documents	A PDF inside a DICOM object is opaque to attribute-level tools. The letterhead alone identifies the site.	Extract and process the document separately, or exclude Encapsulated PDF from the export entirely.
File names and folder paths	Export tooling loves `SMITH_JOHN_2026-03-04/`. The objects can be clean and the ZIP not be.	Generate names from UIDs or opaque keys. Include the packaging in the de-identification test.
Audit logs and support bundles	Diagnostic bundles pull identity into files that then travel by email.	Redact at generation, encrypt in transit, and expire them.
Thumbnails and caches	Rendered derivatives are produced before de-identification and outlive the source.	Include every derivative store in the deletion and correction path.
AI outputs	Model results copy patient context into a separate store that the de-identification pipeline was never pointed at.	Treat AI result stores as PHI stores with the same controls and the same retention rules.

HIPAA Security Rule, in one row

Regulatory (US, human health) 45 CFR §164.306(a) requires covered entities and business associates to: (1) ensure the confidentiality, integrity, and availability of all electronic protected health information they create, receive, maintain, or transmit; (2) protect against reasonably anticipated threats or hazards to its security or integrity; (3) protect against reasonably anticipated impermissible uses or disclosures; and (4) ensure workforce compliance. §164.306(b) makes the approach flexible: measures must be reasonable and appropriate given the organisation’s size, complexity, capabilities, technical infrastructure, cost, and the probability and criticality of the risks. That flexibility is why a risk analysis, not a control list, is the artifact an auditor asks for.

EU GDPR and EU MDR also apply to products placed on the EU market and are outside the scope of this page.

Clinical safety as a system property

Table 20.3: Hazard, mechanism, detection control
Hazard	How it happens	Detection or prevention control
Wrong-patient study	Hand-typed identity at the modality, or an incorrect worklist selection.	Modality Worklist so identity is selected not typed; duplicate-name and duplicate-DOB detection at ingest; IOCM correction path when it happens anyway.
Wrong side or orientation	Laterality mis-set at acquisition, or a viewer that mishandles patient orientation attributes.	Laterality and orientation displayed prominently in the viewer; automated consistency checks against the order.
Missing series	Partial transmission, an interrupted upload, or a series routed elsewhere.	MPPS completion plus an expected-series rule per protocol; the Ready gate refuses to open the case.
Partial study shown as complete	Timeout heuristics standing in for a completeness signal.	Explicit incomplete state, visible to the reader, that cannot be dismissed silently.
Stale or missing prior	Prefetch loses a race with the reader, or the prior sits on an archive tier.	Prefetch triggered at Reconciled, not at Assigned; the viewer states explicitly that priors are still loading.
Lossy artifact mistaken for pathology	Aggressive compression on a delivery path, or double compression through two systems.	`(0028,2110)`, `(0028,2112)`, and `(0028,2114)` written truthfully and surfaced in the viewer; block re-encoding of already-lossy objects.
Display miscalibration	Reading on an uncalibrated or ambient-washed display.	GSDF calibration with a quality-control programme; a viewer-side test pattern the reader can call up in one keystroke.
AI result attached to the wrong study	Orchestration keyed on a mutable identifier instead of the Study Instance UID.	Every result references source SOP Instance UIDs; results are invalidated automatically when source objects are rejected.
Report delivered to the wrong recipient	Stale referring-clinician records, or an inherited routing rule nobody owns.	Recipient resolution at release time, delivery receipts, and a mis-delivery incident path.
Silent migration loss	A migration validated on byte counts and totals alone.	The migration ladder in the next section. Byte counts are rung one of eight.

Change, correction, and migration

Why correction is a protocol problemOnce an object has left your system, fixing it is no longer a database update. Copies exist in other archives, viewers, and reports, and every one of them has to learn that the original is withdrawn or superseded. That is what IOCM is for: a standards-based way to say “this object is rejected, for this coded reason” so downstream systems purge, hide, or re-fetch. A product without it corrects data by phoning people.

Imaging objects are immutable by design, so “correcting” a study means issuing new objects and telling everyone who already has a copy. That telling is what IHE Imaging Object Change Management does.

IOCM rejection reasons, with the codes

A rejection is expressed as a Key Object Selection Document (1.2.840.10008.5.1.4.1.1.88.59) whose document title carries a code from DICOM CID 7010 (PS3.16). Codes verified against the 2026c edition. Standard IHE: Final Text

Table 21.1: Rejection reasons from CID 7010
Code	Code meaning	When it applies	Expected downstream behavior
`(113001, DCM)`	Rejected for Quality Reasons	Positioning, exposure, motion, or artifact makes the image unusable, but there is no safety or privacy issue.	Hide from clinical display; usually retain for quality and reject-analysis reporting.
`(113037, DCM)`	Rejected for Patient Safety Reasons	Wrong patient, wrong study, or anything where continued display could cause harm.	Remove from clinical display everywhere, including caches and derived copies. The strongest rejection.
`(113038, DCM)`	Incorrect Modality Worklist Entry	The right images acquired against the wrong scheduled step: the identity is wrong, the pixels are fine.	Hide the mis-identified objects; re-issue under the correct identity. The classic reconciliation case.
`(113039, DCM)`	Data Retention Policy Expired	Retention period has elapsed and the objects are to be removed from active use.	Remove from clinical display and proceed to deletion per policy, with the audit record retained.
`(131360, DCM)`	Rejection Withdrawn	A previous rejection was itself wrong and is being reversed.	Restore the objects to clinical display. Its existence is the reason rejection must not mean immediate hard deletion.

Two things to demand in a demo: that the archive emits these KOS objects when a correction is made, and that every consumer, such as a viewer, cache, worklist, AI store, or exchange partner, acts on them. An archive that records a rejection nobody downstream honours has documented a problem, not solved one.

Correction propagation matrix

When patient identity changes after a study has been read and delivered, this is the full blast radius. Walk it in a vendor call and ask who does each row. Architecture pattern

Table 21.2: What must update, where
System	What must happen	Who usually owns it	Failure signature
Archive	Rejection KOS issued; corrected objects ingested; both retained with lineage.	Archive supplier	The original quietly overwritten, destroying the audit trail.
Metadata index	Re-index under the corrected identity; the old index entry marked rather than dropped.	Archive supplier	Study searchable under both identities, or under neither.
Viewer caches and CDN	Invalidate every cached object, thumbnail, and rendered derivative.	You	A radiologist opens the correct study and sees the old name in the overlay.
Worklist and case state	Case re-linked; SLA clocks preserved or explicitly reset with a reason.	You	A duplicate case appears and gets read twice.
Report	Amendment issued referencing the correction; the original remains readable.	Reporting platform	Report silently edited: no version, no notification.
EHR / PIMS	Corrected result message or FHIR update; confirm the receiving system displays it.	Integration layer	Correction accepted by the interface and never shown to a clinician.
AI results	Invalidate and re-run against corrected source objects.	You	A finding attached to a patient who does not have it.
Exchange partners and portals	Notify recipients; expire outstanding links.	You	An external copy that nobody can recall, in a record you do not control.
Audit trail	Record the whole sequence, including who authorised the change.	Platform	No answer to “who changed this and when” six months later.

The migration validation ladder

Climb it in order. Most failed migrations stopped at rung two and called it done. Recommendation

Rung 1Storage totalsBytes and object counts match at the estate level. Necessary, wildly insufficient.

Rung 2Per-study instance countsEvery study has the same number of instances on both sides. Catches truncated transfers.

Rung 3SOP Instance UID set equalityThe exact set of UIDs matches per study, not just the count. Catches silent substitution.

Rung 4Header and pixel integrityHash the data set (or at minimum the pixel data plus key attributes) on both sides. Catches transcoding you did not intend.

Rung 5Parse validity at scaleEvery migrated object parses cleanly with an independent toolkit, not the one that wrote it.

Rung 6Viewer-open samplingOpen a stratified sample in the target viewer. Automated validity checks and “a human can read it” are different questions, and neither substitutes for the other.

Rung 7Linkage and clinical sample reviewReports, annotations, presentation states, and corrections still attach to the right study; qualified readers review a real sample.

Rung 8Dual-run monitoring and exit criteriaBoth platforms live, differences monitored, with written criteria for retiring the legacy system, and a rollback that has been tested, not just described.

Anti-pattern: validated with byte counts alone

Matching totals prove that a similar quantity of data arrived. They prove nothing about UID preservation, private-attribute survival, report linkage, presentation states, or whether any of it renders. Every one of those failures is discovered by a radiologist, in front of a customer, months later.

Sourcing decisions, component by component

The real question is not build versus buy. It is: which capabilities are commodities, which must stay under product control, which create differentiation, and which responsibilities can safely be delegated? Decide it per component, not once for the platform.

Commodity, enabling, differentiating

Table 22.1: Strategic character by capability
Capability	Typical character	Decision caution
Durable binary storage	Commodity infrastructure Recommendation	Retrieval latency, object count, portability, and lifecycle still decide the bill and the exit.
DICOM parsing and standard codecs	Commodity library capability	Rebuilding these without a strategic reason is the clearest waste in the whole stack. Mature toolkits exist in every language.
DICOMweb server	Mature enabling capability	“Supports DICOMweb” hides large conformance differences. Test the specific transactions you need.
Basic image viewer	Available commercially and as open source	Basic rendering is not a diagnostic workflow. The gap between the two is most of a product.
Specialised clinical tools	Potential differentiator	Requires clinical requirements, clinical validation, and an owner who is not the engineering team.
Customer imaging experience	Often differentiating	The part customers actually judge you on. Usually justifies custom workflow and UI.
Radiologist work orchestration	Often differentiating	Determines service efficiency and turnaround, which is to say, unit economics.
EHR / PIMS integration	Frequently market-critical	Integration burden routinely dominates protocol implementation. Count interfaces, not standards.
Identity reconciliation	Enabling and safety-critical	Invisible to buyers until it fails, at which point it is the only thing anyone talks about.
Reporting workflow	Context-dependent	Templates alone are not the workflow. Speech, macros, critical results, and amendments are the workflow.
AI orchestration	Potential differentiator	Model lifecycle, provenance, and clinical validation add scope that is easy to underestimate by an order of magnitude.
Long-term archive	Infrastructure with strategic portability implications	Exit rights and demonstrated bulk export are the terms that matter. Negotiate them at purchase, never at renewal.
Operations and analytics	Potential differentiator	Drives supportability and measured service performance. Usually the first thing cut and the first thing missed.

Buy, build, hybrid, or outsource: favoured when

Table 22.2: Four postures
Posture	Favoured when	What you still own	Principal risk
Buy	The capability is mature and standardised; it creates little differentiation; a supplier meets your interoperability, security, support, and portability needs; speed matters more than total control; you lack specialised imaging expertise in-house.	Integration, supplier management, validation, product fit, and the customer outcome. Buying moves work; it does not remove responsibility.	Workflow and roadmap dependence; extension points that constrain the product you actually want to build.
Build	The capability is central to the value proposition; the workflow is unusual or underserved; roadmap control is strategic; existing products cannot meet the clinical or integration requirement; you can sustain the expertise.	Everything: validation, security, support, upgrades, maintenance, and the long tail of modality edge cases.	Scope. Specialist staffing over a decade, and the interoperability burden you just took on.
Hybrid	You can name precisely which layers are commodity and which are differentiating: typically buy the archive and standards layer, build the customer experience and the workbench.	The integration boundary, which becomes the most important contract in the system.	Integration and supplier-management complexity. Hybrid is not automatically best; the value is selective control, not using many components.
Outsource operations	The capability needs specialised 24-hour expertise; running the infrastructure is not strategic; service levels and responsibilities can be defined and measured; the supplier has credible operational maturity; portability and transition rights stay protected.	Technical controls and product oversight. Contractual allocation of a responsibility does not allocate the risk.	Losing the ability to trace a problem across the supplier boundary, and your customer noticing first.

Component scorecard

Fifteen components, seven criteria, one strategy each. Nothing is pre-filled on purpose: the stack map shows this page’s default lean per layer, and your answers should differ from it wherever your context differs. Selections are stored in this browser only. Nothing is sent anywhere. Use Print blank to take an empty grid into a meeting.

Table 22.3: Component scorecard: rate each cell, then choose a strategy. Saved in this browser only.
Component	Strategic value	Market maturity	Customization need	Clinical risk	Integration difficulty	Operating burden	Portability risk	Strategy
Modality connectivity
Edge gateway / uploader
DICOM ingestion
Identity reconciliation
DICOM repository
DICOMweb / API layer
PACS workflow
Diagnostic viewer
Clinical review viewer
Customer viewer
Radiologist workbench
Reporting
Report delivery
AI orchestration
Administration, monitoring & support

Five reference strategies

Table 22.4: Reference product strategies A–E
Strategy	Advantages	Disadvantages	Best fit	Exit risk
A. Buy a complete platform	Fast access to an established capability set; small initial engineering scope; one supplier owns more of the integration and support surface.	Workflow and roadmap dependence; differentiation limited to the supplier’s extension points; commercial and operational concentration.	A first product, a small clinical footprint, or an organisation without imaging engineers.	Highest. Proprietary APIs, viewer coupling, and export costs compound. Negotiate the exit at purchase.
B. Buy the imaging core, build the product	Avoids rebuilding mature imaging infrastructure; keeps control where customers experience value; the archive and the experience can evolve on different clocks.	The integration boundary becomes critical; supplier upgrades can break custom workflow; you still own end-to-end operation.	The common answer for a platform company: buy archive and DICOM services, build customer experience, workbench, and reporting integration.	Moderate. Manageable if the core speaks standards and you never let workflow state leak into it.
C. Open-source core, custom workflow	Source access and full customisation; no single commercial licence dependency; often strong standards alignment.	You own security, upgrades, operation, validation, and support. Community direction may diverge from your needs.	Teams with real infrastructure capability and a workflow no product fits.	Low technical lock-in, high capability lock-in: the exit is from your own operating burden.
D. Build the entire stack	Maximum control; custom fit; potentially differentiated imaging technology.	Maximum scope: codecs, rendering, modality edge cases, interoperability and clinical validation, support, migration, and long-term specialist staffing.	Justified only when the imaging technology itself is strategic, or no available product can satisfy the required workflow.	Lowest supplier lock-in, highest opportunity cost. Every engineer on codecs is an engineer not on the workbench.
E. Platform plus outsourced clinical operations	Combines software with an external reading network; capacity scales without hiring radiologists; subspecialty coverage arrives ready-made.	Assignment, escalation, quality review, credentialing, and critical-result responsibility all become boundary questions.	Service-led products where turnaround and coverage are the promise.	Moderate to high on the clinical side. Answer in the contract: who owns assignment, escalation, quality review, turnaround commitments, critical-result communication, licensing constraints, customer support, and cross-boundary tracing.

Five reference architectures

Component lists and the decisions that dominate each shape. Expand the one you are in.

1. Small clinic or practice

Components

One or more modalities
Local connectivity software or a web uploader
Hosted DICOM repository or PACS
Clinical review viewer
Optional remote specialist workflow
PIMS or EHR integration
Report delivery
Basic administration and support

Decision emphasis

Onboarding a clinic must take hours, not a site visit
Resilience to unreliable connectivity: local buffering and resend are not optional
Minimal on-premises infrastructure: every box is a support contract
Explicit ownership of modality support: yours, theirs, or a field partner’s
Predictable cost; per-object charges surprise small practices badly
Secure external consultation without a second login

2. Hospital or referral centre

Components

Multiple modalities across departments
Modality worklists (SWF or SWF.b)
RIS, EHR, or PIMS as order source
PACS workflow layer
Diagnostic workstations on calibrated displays
DICOM archive or VNA
Reporting with templates and speech
Critical-result communication
Enterprise identity
Monitoring and support operations

Decision emphasis

High availability, because downtime procedures are clinical procedures
Priors: fetch policy, retention, and how far back
Multi-department identity and workflow, with one reconciliation authority
Diagnostic display programme with documented quality control
Correction workflows exercised, not merely available
Integration with enterprise systems you do not control and cannot change

3. Teleradiology platform

Components

Multi-customer ingestion
Tenant and facility configuration
Identity and order reconciliation
DICOM repository
Case-readiness workflow
Assignment and load balancing
Diagnostic viewer
Radiologist workbench
Reporting
Customer delivery
Critical-result escalation
Service analytics

Decision emphasis

Tenant isolation you can demonstrate to a customer’s security team
Regional and credential constraints encoded in routing rules, not in a coordinator’s memory
Work orchestration: the differentiating capability in this shape
Turnaround time measured per state, not end to end only
Customer communication when something is late, before they ask
24-hour operations, including who restarts the gateway at 03:00

4. Multi-tenant cloud imaging product

Components

Edge DIMSE gateway or uploader
Multi-tenant ingestion
DICOMweb repository
Identity and product APIs
Workflow services
Event or queue infrastructure
Viewer applications, all three tiers
Reporting and delivery
Administrative plane
Security, audit, and observability

Decision emphasis

Tenant boundaries enforced in storage, index, and API, not only in the UI
Stable service contracts, because every internal boundary becomes an upgrade constraint
Scale modelled by object count and access pattern, not terabytes
Regional deployment and data residency
Replaceability of every bought component: write the exit into the design
Cost attribution per tenant, or you will never price the product correctly

5. Hybrid legacy modernisation

Components

The existing PACS and archive, still live
Standards adapter or gateway
New repository or workflow services
New viewer or portal
Synchronisation and reconciliation
Controlled customer or facility migration
Duplicate-operation monitoring
Final export and retirement

Decision emphasis

One named source of truth at every moment of the transition
Dual-write or copy semantics decided explicitly, and written down
Rollback that has been tested with real data
Viewer parity checked feature by feature before any cohort moves
Correction propagation across both platforms, which is the hardest part
Operational support during coexistence: two systems, one support team
Written exit criteria for retiring the legacy platform, agreed before you start

Vendor questionnaire

Forty-four questions in six groups. Tick them off during the call; answers save in this browser only. Print it blank for a meeting. The point is not the checklist. It is that an unanswerable question is itself the answer.

Proof-of-concept plan

A PoC on curated images proves that curated images work. Use representative workflows and representative failures. Recommendation

Fourteen red flags

Each of these has sunk a real imaging programme. Any one of them is a reason to slow down; three of them together is a reason to walk. Recommendation

Reject 01 · Conformance“DICOM compatible” with no current conformance statementRung one of the vocabulary ladder, asserted as rung four. Ask for the PS3.2 document and read Annex N.5.

Reject 02 · InterfacesUndocumented proprietary image-delivery protocolThe viewer cannot be replaced, and neither can the archive. This is the highest-leverage lock-in in the stack.

Reject 03 · PortabilityNo bulk export pathOr one that exists, has never been run at your scale, and is billed per object.

Reject 04 · AnnotationsViewer-only or browser-local annotationsClinical work product that cannot leave the tool that made it, and cannot be audited.

Reject 05 · IntegrityCannot preserve the original DICOM objectIf the archive normalises on ingest and cannot return what it was given, you have no original.

Reject 06 · SafetyNo wrong-patient correction workflowThe event will happen. A product with no path for it makes it an engineering incident and a clinical one.

Reject 07 · OperationsNo partial-study or failed-ingestion administrationNormal operational problems become tickets to the supplier, forever.

Reject 08 · StorageArchive-tier data in a synchronous clinical pathCold storage with no prefetch design is a radiologist waiting on rehydration, billed per object.

Reject 09 · EvidenceDemonstrations limited to curated studiesIf they will not load your data, the answer to why is not one you will like.

Reject 10 · RegulatoryNo distinction between diagnostic and review-only useA supplier who has not thought about intended use has not thought about your regulatory exposure either.

Reject 11 · AIAI results without input and model provenanceUnauditable, unreproducible, and worthless the moment the model is retrained.

Reject 12 · ObservabilityNo end-to-end observabilityYou cannot trace one study from modality to delivered report, so every incident is a guess.

Reject 13 · IdentityNo clear source of truth for patient, order, study, and reportEvery downstream correction becomes a negotiation between systems that each think they are right.

Reject 14 · ConcentrationOne vendor owns archive, workflow, viewer and export through proprietary interfaces, with no exit planThe compound version of flags 02, 03 and 05. Price the exit before you sign the entry.

Common mistakes and anti-patterns

Fifteen recurring failures, each with the consequence it produces and the fix that prevents it. Recommendation

Table 25.1: Anti-patterns
Anti-pattern	Consequence	Fix
Treating object storage as a complete archive	No index recovery, no lifecycle state, no correction history: a bucket of files nobody can prove anything about.	Specify the twelve repository responsibilities and check each against the product, not the storage layer underneath it.
Assuming DICOM support guarantees interoperability	Integration slips a quarter because “supports” meant one SOP Class in one role.	Use the five-rung ladder. Demand the conformance statement, then test the specific transactions you need.
Selecting a viewer from screenshots	A decoder gap or read-only presentation states discovered after the contract is signed.	Run the twenty-criterion matrix on your own data, on your own network, with a round trip through a second product.
Letting the viewer own critical workflow state	Case state disappears when you replace the viewer, and cannot be queried by anything else.	Keep workflow state in explicit product services, linked to the Study Instance UID. The viewer displays state; it does not own it.
Storing annotations only in a browser or proprietary format	Clinical work product that cannot be exported, audited, or migrated.	Require GSPS or SR read and write, and verify by opening the annotation somewhere else.
Ignoring wrong-patient and correction workflows	The first real correction becomes an engineering incident with a clinical-safety report attached.	Design the IOCM path and the propagation matrix before launch, and rehearse it.
Validating a migration using byte counts alone	Missing UIDs, dropped private tags, orphaned reports: all discovered months later by a radiologist.	Climb all eight rungs of the migration ladder, and gate cutover on rungs six and seven.
Selecting storage tiers on capacity price alone	A cheap archive with a per-object rehydration fee and a radiologist waiting minutes for a prior.	Model object count, transaction cost, rehydration latency, and export throughput together. Never put cold storage in a synchronous clinical path.
Building commodity codecs and protocol plumbing	Years of specialist effort spent reproducing DCMTK, and a decoder matrix you now own forever.	Adopt a mature toolkit. Spend the engineering on the workbench and the customer experience instead.
Buying a complete platform before identifying the differentiating workflow	The product you can build is now bounded by someone else’s extension points.	Classify every component as commodity, enabling, or differentiating first. Then buy the commodities.
Treating FHIR `ImagingStudy` as the DICOM object repository	An architecture with nowhere for pixels to live, discovered at the first retrieval.	ImagingStudy is an index that points at a WADO-RS service. HL7 says so explicitly.
Treating AE Title as a user credential	Any host that reaches your listener and guesses a string can push into a tenant.	AE Titles route and identify. TLS, segmentation, and service identities authorise.
Assuming one compression ratio is universally safe	Artifacts in one modality or one clinical task, and an AI pipeline that quietly shifts.	There is no such ratio: the ACR–AAPM–SIIM standard declines to state one. Validate per modality and per task, through all four validation layers.
Treating AI output as unversioned JSON disconnected from source images	Results that cannot be audited, compared across versions, or displayed anywhere but your own UI.	Encode as SR, Segmentation, Parametric Map, or FHIR Observation, always referencing source SOP Instance UIDs and a model version.
Ignoring back-office and support tooling in the product estimate	Every operational exception becomes an engineering ticket; support cost scales with volume instead of with incidents.	Scope administration, support search, exception queues, and observability as first-class components with owners: they are two of the thirteen strata for a reason.

Glossary

Sixty terms in one alphabet. For the longer form of what each standard and body is, and who stands behind it, see standards and bodies.

AAPM: American Association of Physicists in Medicine: the US medical physics society, founded 1958. Co-author of the ACR–AAPM–SIIM technical standards and the source of most display-QA guidance.

Accession Number: a workflow identifier connecting an imaging request, study, and report. Carried in (0008,0050). Ownership and uniqueness scope vary by system, which is why it needs an assigning authority.

ACR: American College of Radiology: the US professional body for radiologists and medical physicists. With NEMA it formed the 1983 committee that produced ACR-NEMA 300, DICOM’s ancestor.

Actor: In IHE, a functional unit that produces, manages, or acts on information (Image Manager, Acquisition Modality, Report Creator). Products implement actors; a profile claim without an actor role is not a claim.

AE Title: a 16-byte identifier for a DICOM Application Entity, carried in an association request. An identifier, never a credential.

Association: the negotiated connection between two DICOM Application Entities, carrying one or more presentation contexts.

ATNA: Audit Trail and Node Authentication; in DICOM terms, the PS3.15 Audit Trail Message Format Profile plus its transmission profiles.

Bulk data: large binary values (usually pixel data) referenced from DICOMweb metadata by a BulkDataURI rather than inlined.

CDA: HL7 Clinical Document Architecture: an XML document standard for clinical documents. DICOM PS3.20 defines the imaging-report-to-CDA transformation.

Connectathon: IHE’s supervised interoperability testing event, where implementations test profile transactions against other vendors’ systems. Results are published by year and actor.

DAIC: diagnostically acceptable irreversible compression: lossy compression that does not affect a particular diagnostic task, as defined by the ACR–AAPM–SIIM standard.

DICOM: Digital Imaging and Communications in Medicine: the standard for representing, storing, and exchanging medical imaging information. Republished several times a year; 2026c at the time of writing.

DICOMweb: the web services defined in DICOM PS3.18: QIDO-RS, WADO-RS, STOW-RS, WADO-URI, UPS-RS and more.

DIMSE: DICOM Message Service Element: the classic message layer carrying C-STORE, C-FIND, C-MOVE, C-GET and the N-services.

FHIR: Fast Healthcare Interoperability Resources: the modern HL7 standard, REST plus typed resources. Current published version R5 (v5.0.0). Each resource carries its own maturity level.

FHIRcast: The HL7 specification for context synchronisation between desktop applications, so the reporting application follows the viewer. IHE IRA depends on it.

Frame: one image within a multi-frame instance. Addressed by number, starting at 1; frames have no UID.

GSDF: Grayscale Standard Display Function (PS3.14): the perceptually linearised luminance response curve that display calibration targets.

GSPS: Grayscale Softcopy Presentation State: a DICOM object storing display settings and annotations separately from the images they apply to.

Hanging protocol: rules for arranging series and priors on screen automatically at study open.

HIMSS: Healthcare Information and Management Systems Society: the health IT society that co-founded IHE with RSNA in 1998.

HL7 v2: the pipe-delimited messaging standard still carrying most real-world orders (ORM, OMI) and results (ORU^R01).

HTJ2K: High-Throughput JPEG 2000: the same wavelet transform with a much faster block coder. Transfer syntaxes 1.2.840.10008.1.2.4.201 to .203.

IHE: Integrating the Healthcare Enterprise: the organisation that publishes integration profiles combining existing standards to solve defined workflow problems.

Instance: a DICOM SOP Instance: one image, report, presentation state, or other object, identified by SOP Instance UID (0008,0018).

Interface engine: Middleware that translates, routes, and buffers HL7 and DICOM traffic between systems that disagree. Budget it as a component with an owner, not as a script.

IOCM: Imaging Object Change Management: the IHE Final Text profile for communicating rejection and correction of already-distributed objects.

IOD: Information Object Definition: the DICOM specification of an object’s modules and attributes, in PS3.3. Paired with the services allowed on it, it becomes a SOP Class.

ISO 12052: The ISO designation under which DICOM is recognised. The same standard; useful when a procurement document insists on an ISO reference.

KOS: Key Object Selection Document: a titled, coded list of referenced instances. The carrier for IOCM rejections, key images, and manifests.

MITA: Medical Imaging & Technology Alliance, a division of NEMA: serves as the DICOM Secretariat.

MLLP: Minimal Lower Layer Protocol: the framing that carries HL7 v2 messages over TCP. Not a security layer.

MPPS: Modality Performed Procedure Step: the DICOM service by which a modality announces that acquisition started and completed.

MPR / MIP: multi-planar reconstruction and maximum-intensity projection: two standard reformatting operations on volumetric data.

MRRT: Management of Radiology Report Templates: the IHE Final Text profile giving report templates an interoperable format.

Modality Worklist: the DICOM service (1.2.840.10008.5.1.4.31) that delivers scheduled procedure and patient information to a modality so identity is selected rather than typed.

NEMA: National Electrical Manufacturers Association: holds the DICOM copyright and publishes the standard as NEMA Standard PS3.

ORM / OMI / ORU: HL7 v2 message types: order (ORM), imaging order (OMI), and observation result (ORU^R01, the usual carrier for a released report).

PACS: Picture Archiving and Communication System. Scope varies enormously by product; NIST classifies it as an FDA Class II device.

PIMS: practice information management system: the veterinary equivalent of an EHR plus a practice-management system.

Presentation context: the pairing, negotiated at association time, of one abstract syntax (SOP Class) with acceptable transfer syntaxes.

PS3.n: A numbered part of DICOM, not a version. PS is the NEMA publication-standard prefix and the standard runs PS3.1 to PS3.22. The edition label (2026c) changes several times a year; part numbers do not.

QIDO-RS: the DICOMweb search service. Queries are hierarchical or relational depending on the resource.

RIS: radiology information system: the order, scheduling, and workflow system in a human-health radiology department.

RSNA: Radiological Society of North America: the radiology professional society that co-founded IHE with HIMSS in 1998.

SCU / SCP: Service Class User (the requester) and Service Class Provider (the responder). A product is usually both, in different roles.

Series: a group of instances acquired or produced in a common context within a study. Identified by (0020,000E).

SIIM: Society for Imaging Informatics in Medicine: the imaging informatics society, founded 1989 as SCAR and renamed in 2006. Co-author of the ACR–AAPM–SIIM technical standards.

SOP Class: a Service-Object Pair Class: an information object definition paired with the services allowed on it, identified by a UID.

SR: DICOM Structured Report: an object whose content is a coded tree of observations referencing the images they describe. The standards-based carrier for measurements, CAD, dose, and AI output.

Storage Commitment: The DICOM service by which a receiver takes documented responsibility for retaining instances, so the sender may delete its copy. Carried by N-ACTION and N-EVENT-REPORT.

STOW-RS: the DICOMweb store transaction. A 202 response can contain per-instance failures; parse the body.

Study: the top-level grouping of an imaging examination, identified by Study Instance UID (0020,000D). Globally unique and never regenerated.

TID 1500: the DICOM Measurement Report structured-report template (PS3.16). The standards-based home for AI and quantitative measurements.

Transaction: In IHE, one defined information exchange between two actors, built on an existing standard and numbered (RAD-x in Radiology).

Transfer syntax: the encoding of a DICOM data set: byte ordering, VR representation, and any compression. Identified by a UID.

UPS: Unified Procedure Step: DICOM’s general worklist service for post-acquisition work, including AI tasks. Push, Watch, Pull, Event, and Query SOP Classes, plus a web form, UPS-RS.

VNA: vendor-neutral archive: durable, application-independent imaging storage. Judge it by demonstrated capability, never by the label.

VR: Value Representation: the data type of a DICOM attribute (AE, UI, PN, DS…), defined in PS3.5 along with its length limit.

WADO-RS: the DICOMweb retrieve service, addressing studies, series, instances, frames, metadata, bulk data, rendered images, and thumbnails.

Sources

Standards bodies, regulators, professional bodies, and peer-reviewed literature only. No vendor material is cited anywhere on this page, and no commercial product is named. All accessed September 2026.

DICOM

DICOM current edition, PS3.1–PS3.22: DICOM Standards Committee and NEMA. Edition label 2026c at the time of writing.
PS3.2 Conformance: conformance requirements and, in Annex N, the Conformance Statement template.
PS3.4 Service Class Specifications: source for the C-MOVE (C.4.2) and C-GET (C.4.3) association semantics quoted above.
PS3.5 §6.2 Value Representations: source for “AE: 16 bytes maximum”.
PS3.6 Annex A, Registry of DICOM Unique Identifiers: every SOP Class and transfer syntax UID on this page.
PS3.6 §6, Registry of DICOM Data Elements: every tag number, including the veterinary attributes.
PS3.15 Annex E, Attribute Confidentiality Profiles: the eleven de-identification options.
PS3.16 CID 7010, Key Object Selection Document Title: the IOCM rejection codes.
PS3.18 Web Services: the DICOMweb URI templates in Table 6.1.
DICOM overview: what DICOM is used for.

IHE and HL7

IHE Radiology Technical Framework and profile index: Revision 23.0, published 2025-08-08. The source for every status in Table 10.1.
IHE Profiles: purpose and publication lifecycle.
IHE Interactive Multimedia Report (IMR): carries the “NOT yet recommended for production use” statement quoted above.
IHE Integrated Reporting Applications (IRA): same statement, plus its FHIRcast dependency.
FHIR R5 ImagingStudy: source for the DICOM mapping and for “the DICOM instances are not stored in the ImagingStudy resource”.
FHIR R5 DiagnosticReport.
FHIR R5 ImagingSelection: maturity level 1, Trial Use.

Regulators and standards bodies

NIST SP 1800-24, Securing Picture Archiving and Communication System (PACS): December 2020.
45 CFR §164.306, Security standards: General rules: the four HIPAA Security Rule general requirements and the flexibility-of-approach factors.
HHS: The HIPAA Security Rule.
FDA AI-Enabled Medical Devices list: 1,524 entries counted Sep 2026, 1,164 under the Radiology panel; page content current as of 16 Jun 2026.
FDA: Artificial Intelligence in Software as a Medical Device.
FDA: How FDA Regulates Animal Devices: source for the veterinary premarket-scope statement.
IANA Service Name and Transport Protocol Port Number Registry: acr-nema 104, dicom 11112, dicom-tls 2762.

Organisations and governance

DICOM: About: source for “NEMA serves as the DICOM Secretariat” and for DICOM’s recognition as ISO 12052.
DICOM: History: the 1983 ACR–NEMA committee, ACR-NEMA 300 v1.0 (1985) and v2.0 (1988), and the 1993 rename to DICOM published as NEMA Standard PS3.
DICOM Working Groups: the 35 working groups counted Sep 2026, including WG-06, WG-14, WG-23, and WG-27.
DICOMweb overview: the service family (QIDO-RS, WADO-RS, WADO-URI, STOW-RS, UPS-RS, capabilities).
NEMA: Medical Imaging & Technology Alliance (MITA): MITA as a division of NEMA and as DICOM Secretariat.
IHE FAQ: “IHE began in 1998 with the mutual realization by HIMSS and RSNA…”, plus the definitions of actor, transaction, integration profile, and Technical Framework.
HL7 International: About: founded 1987, not-for-profit ANSI-accredited SDO; V2, CDA, and FHIR product lines.
AAPM: scientific and professional organisation of medical physicists, founded 1958.
SIIM: History: founded 1989 as the Society for Computer Applications in Radiology, renamed SIIM in 2006.

Professional guidance and literature

ACR–AAPM–SIIM Technical Standard for Electronic Practice of Medical Imaging: Revised 2022 (Res. 48), Amended 2023. Source for the DAIC definition, the “no general statement” position on compression ratios, the mammography compression restriction, and the display luminance figures.
ACR–AAPM Technical Standard for Diagnostic Interpretation Displays: Revised 2024, effective 1 July 2024.
ACR Practice Parameter for Communication of Diagnostic Imaging Findings: Revised 2025 (Res. 9).
ACR Practice Parameters and Technical Standards: ACR’s own statement that these are educational tools and not a legal standard of care.
McDonald RJ et al., “The effects of changes in utilization and technological advancements of cross-sectional imaging on radiologist workload”, Academic Radiology 2015;22(9):1191–1198 (CT and MR images per exam).
Conant EF, “Clinical Implementation of Digital Breast Tomosynthesis”, Radiologic Clinics of North America 2014 (DBT/DM examination data volume).
Frommelt MA et al., “Experience with a DICOM-Compatible Digital Pediatric Echocardiography Laboratory”, Pediatric Cardiology 2002 (per-study ultrasound volume).
Costanza D et al., “Description of a low-cost picture archiving and communication system based on network-attached storage”, Veterinary Radiology & Ultrasound 2022;63(3) (veterinary archive scale).
Buchanan JW, Bücheler J, “Vertebral scale system to measure canine heart size in radiographs”, JAVMA 1995;206(2):194–199 (Vertebral Heart Score).
Malcolm EL et al., “Diagnostic value of vertebral left atrial size…”, JAVMA 2018;253(8):1038–1045 (VLAS).
Reif U et al., “Comparison of anatomical tibial plateau angle versus observer measurement from lateral radiographs in dogs”, Veterinary Surgery 2006;35(4) (tibial plateau angle).
Smith GK, Biery DN, Gregor TP, “New concepts of coxofemoral joint stability and the development of a clinical stress-radiographic method for quantitating hip joint laxity in the dog”, JAVMA 1990;196(1):59–70 (distraction index).
Dyce J et al., “Radiographic evaluation of acetabular component position in dogs”, Veterinary Surgery 2001;30(1):28–39 (angle of lateral opening).

Quick reference

The five-rung vocabulary ladder Standard Recommendation

The stack map

What each standard and body actually is

Standards and service families

The bodies behind them

IHE’s four words, which vendors use loosely and you should not

System categories: what the product words mean

Use this to weigh a claim, not just to decode it Recommendation

Vocabulary that must not be confused

Prescriptive vocabulary: when each phrase is allowed

Evidence labels used on this page

What DICOM does not provide Recommendation

DICOM, part by part

DIMSE services and the association model

DICOMweb endpoints

DIMSE vs DICOMweb, and when you need a gateway

Four product implications Architecture pattern

SOP Classes beyond images

Transfer syntaxes and compression

The four attributes that make lossy compression auditable

What the professional standard actually says about lossy compression Prof. guidance

🏥Human health: Human health

🐾Veterinary: Veterinary

Four validation layers before you accept a compression or transcoding change

IHE Radiology profiles and their maturity

The maturity ladder

How to use this in a vendor call Recommendation

FHIR imaging resources, and where they stop

Two things to keep straight Standard Common practice

Identity and the source-of-truth worksheet

AE Title is not a user credential Recommendation

The three reconciliation flows

1. Worklist-matched (the good case)

2. Unscheduled / emergency (IHE PIR)

3. Wrong-patient discovered after read

Ingestion failure scenarios

The question that separates a protocol endpoint from a product

Repository, storage lifecycle, and scale

Twelve responsibilities of the repository

Storage tiers as a workflow decision, not a price decision

Anti-pattern: capacity price as the tier decision Recommendation

Scale anchors, and an honest note about them

The recovery question that reveals the architecture

The exit test: require evidence before you sign

PACS, VNA, and the market categories

PACS vs VNA, decided by capability rather than label

Open-source components, with versions as of Sep 2026

Viewer tiers, architectures, and evaluation

Three tiers

Four architectures

Viewer evaluation matrix: twenty criteria

🏥Human health: Human health

🐾Veterinary: Veterinary

Anti-pattern: selecting a viewer from screenshots

The radiologist workbench as a state machine

Reporting sub-capabilities

Report lifecycle and delivery channels

Report status lifecycle

AI orchestration

Orchestration platform checklist

Where AI results should live

Anti-pattern: AI output as unversioned JSON

Regulatory context Regulatory (US, human health)

Security, privacy, and clinical safety

Scope, stated once

NIST SP 1800-24 control areas

Capability areas from SP 1800-24

The operational checklist that follows from it

DICOM PS3.15 security and confidentiality profiles

The eleven Basic Application Level Confidentiality Options

Where identifying information actually hides

HIPAA Security Rule, in one row

Clinical safety as a system property

Change, correction, and migration

IOCM rejection reasons, with the codes

Correction propagation matrix

The migration validation ladder

Anti-pattern: validated with byte counts alone

Sourcing decisions, component by component

Human health: Human health

Veterinary: Veterinary

Human health: Human health

Veterinary: Veterinary