What a DICOM server is
A DICOM server is software that speaks the DICOM network protocol so that imaging equipment and workstations can talk to it. DICOM is both a file format and a networking standard, and the server is the networking half made concrete: it listens on a port, accepts connections, called associations, from modalities and clients, and provides the standard services those devices expect. In the language of the standard it acts as a Service Class Provider, an SCP, while the modality or workstation that connects to it acts as a Service Class User.
At its narrowest, a DICOM server is a networked node that receives studies and hands them back on request. That is genuinely useful on its own: it lets a scanner push its images somewhere durable, and lets another system pull them later. But a node that only receives and forwards is not the same thing as a system a clinician can read from, and keeping that distinction straight is most of what this page is about.
The DICOM network services
Almost everything a DICOM server does resolves to a handful of named services. When a vendor or an open-source project describes what its server supports, these are the terms it uses, and its DICOM conformance statement is where the exact list lives.
- Storage (C-STORE). The server acts as a Store SCP: a modality opens an association and pushes each image object to the server, which stores it. This is how studies get from the scanner into the archive in the first place.
- Query/Retrieve (C-FIND, C-MOVE, C-GET). A client searches the server with C-FIND for patients or studies that match criteria, then uses C-MOVE or C-GET to pull the matching studies to a destination. This is how a workstation asks the archive for a prior study.
- Storage Commitment. Before a modality deletes its local copy of a study, it can ask the server to confirm it has taken durable responsibility for that study. The server answers only once the images are safely held, so nothing is dropped in the handoff.
- Modality Worklist. The server provides scheduled patient and procedure details to a modality, so a technologist selects the booked exam rather than retyping the patient demographics. This is what keeps the identifiers on the images consistent with the rest of the record.
- Verification (C-ECHO). The simple handshake two nodes use to confirm they can reach and talk to each other, the DICOM equivalent of a ping.
No single server has to implement all of these, and which ones a given server provides is exactly what determines whether it fits your equipment. That is why the conformance statement matters more than the marketing.
DICOM server versus PACS
The single most useful distinction to get straight is that a DICOM server and a PACS are not the same thing, even though the terms get used loosely. A DICOM server is the networking layer that receives, stores and serves the images. A PACS is that server plus everything built around it to make imaging usable day to day.
| Bare DICOM server | PACS (DICOM server + archive + viewer) | |
|---|---|---|
| Core job | Receive, store and serve DICOM objects over the network | Everything a server does, plus archive, database, viewer and workflow |
| Receive from modalities | C-STORE as a Store SCP | Same, integrated with worklist and the patient index |
| Find a prior study | C-FIND / C-MOVE if the service is implemented | Search the indexed database, open it in the viewer |
| Read the images | Not included; needs a separate viewer | Built-in viewer, often zero-footprint in the browser |
| Reporting and access workflow | Not included | Reading, reporting and access control on top |
Every PACS contains a DICOM server; not every DICOM server is a PACS. The mistake is assuming a store-and-forward node will give clinicians a way to view and work with studies, or, in the other direction, standing up a full PACS when the real requirement was a lightweight router between two systems. Naming which one you need saves the wrong deployment.
Where MiniPACS fits
MiniPACS is a full self-hosted PACS built on standard DICOM networking. It acts as a DICOM server, it receives studies from modalities, and it supports query/retrieve and modality worklist, and on top of that it gives you the archive, a zero-footprint web viewer and the workflow to actually read the images. It is not just a bare store-and-forward node; the networking is the foundation, not the whole product.
The honest way to put it: if what you need is a networked node to receive and route DICOM and nothing more, a minimal server, or one of the open-source projects below, may be all you should deploy. If you need to receive from your modalities and also give clinicians an archive and a viewer they can open from anywhere, that is the case MiniPACS is built for. We speak here at the level of standard DICOM services rather than claiming specific conformance details you can confirm for yourself in the conformance statement.
Open-source DICOM servers
Two open-source projects come up constantly when people talk about DICOM servers: Orthanc and dcm4che. Both implement the standard network services and both are widely used as archives, routers and integration points. They are a reasonable answer when the requirement really is a server, and less of one when the requirement is a complete system with a viewer and workflow that you would otherwise have to assemble and maintain yourself. For where the open-source route stops being just a server, see the Orthanc alternative comparison, which walks through exactly that boundary.
Self-hosted or managed
The hosting question for a DICOM server is the same one a PACS faces, and it is worth deciding deliberately rather than by default. Self-hosting keeps the studies on your own server, under your own backups and audit trail, with no per-study cloud fee and no dependence on a vendor to return the archive if the relationship ends. The cost is that you own the hardware, the backups and the security work. A managed or cloud DICOM service moves that burden to the vendor and bills for it, and puts your imaging history on the vendor's infrastructure.
Imaging archives grow, and the per-study cost model of a cloud service and the fixed cost of owning the hardware pull apart as volume climbs, so it is worth running your real study volume against both before deciding. For the full version of that tradeoff, see cloud vs onsite.
What to check before deploying a DICOM server
- Conformance statement. Confirm the exact services supported, C-STORE, query/retrieve, storage commitment, modality worklist, and that they match what your modalities expect.
- Server or system. Decide whether you need a bare networked node or a full archive with a viewer and workflow before you shortlist anything.
- Viewer path. If the server does not view, confirm how clinicians actually read the studies, so the images and the people who need them do not end up in two disconnected places.
- Ownership and exit. Ask who holds the archive and how you get it back. See comparing PACS vendors for the contract terms that matter.
- Access. Whether studies open in a browser from anywhere or need a specific workstation with software installed.
For how a full system works day to day, see what is PACS. For the open-source route specifically, see the Orthanc alternative comparison. For pricing and a live demo you can click through, see the landing.
FAQ
What is a DICOM server?
A DICOM server is a piece of software that speaks the DICOM network protocol so that imaging equipment can send it studies and clients can ask it for them back. In DICOM terms it acts as a Service Class Provider: it listens on a port, accepts associations from modalities and workstations, and provides the standard services those devices expect, chiefly receiving images (C-STORE) and answering queries and retrieval requests (C-FIND, C-MOVE, C-GET). At its narrowest a DICOM server is just that networked store-and-forward node; in practice most useful ones also hold an archive and an index of what they have received.
What is the difference between a DICOM server and a PACS?
A DICOM server is the networking layer: it receives, stores and serves DICOM objects. A PACS is a DICOM server plus the rest of the system built around it, an archive with a real storage strategy, a database that indexes patients and studies, a viewer to read the images, and the workflow that ties reading, reporting and access together. Put simply, every PACS contains a DICOM server, but not every DICOM server is a PACS. A bare server can receive from a modality and hand studies to another node; it does not by itself give clinicians a way to view and work with the images.
What DICOM network services does a server provide?
The core ones are Storage (C-STORE, where the server acts as a Store SCP and receives images pushed from modalities), Query/Retrieve (C-FIND to search, and C-MOVE or C-GET to pull matching studies to a destination), Storage Commitment (the modality asks the server to confirm it has taken durable responsibility for a study before the modality deletes its local copy), and Modality Worklist (the server hands scheduled patient and procedure details to a modality so technologists do not retype them). Verification (C-ECHO) is the simple handshake used to confirm two nodes can talk. Which of these a given server supports is stated in its DICOM conformance statement.
Is Orthanc a DICOM server?
Yes. Orthanc and dcm4che are two well-known open-source DICOM server projects, and both implement the standard network services. They are commonly used as lightweight archives, routers or integration points. What they give you out of the box, and how much viewer and workflow sits on top, varies by project and by how you assemble them. If you are weighing the open-source route specifically, the Orthanc comparison covers where a bare server ends and a full system begins.
Can I self-host a DICOM server?
Yes, and it is a common choice. Self-hosting keeps the studies on your own server, under your own backups and audit log, with no per-study cloud fee and no dependence on a vendor to hand the archive back if the relationship ends. The cost is that you own the hardware, the backups and the security hardening. A managed or cloud DICOM service reverses that tradeoff: the vendor runs the infrastructure and bills for it, and your imaging history lives on their systems. Neither is automatically right; it comes down to who you want holding the archive and how you prefer to pay for it.