A Service Class Provider (SCP) is the role of a DICOM Application Entity that performs a specific network operation on behalf of a requesting Service Class User (SCU). In a DICOM association, the SCP acts as the server, listening for incoming connection requests and executing the commanded service, such as storing a CT image via the C-STORE command or returning a list of studies via C-FIND. The SCP's capabilities are formally declared in its DICOM Conformance Statement, which lists the SOP Classes it supports.
Glossary
SCP (Service Class Provider)
A Service Class Provider (SCP) is a DICOM Application Entity that passively listens for and executes a requested network operation, such as storing images or answering a query, on behalf of a Service Class User (SCU).
DICOM NETWORK ROLE
What is SCP (Service Class Provider)?
The SCP is the server-side Application Entity in a DICOM association that passively listens for and executes a requested operation, such as storing images or responding to a query.
The SCP role is fundamental to the client-server architecture of DICOM networking. A single device can simultaneously act as an SCP for some services and an SCU for others; for instance, a PACS archive acts as an SCP when receiving images from a modality, but may act as an SCU when forwarding those images to a VNA. The specific behavior of the SCP is defined by the DIMSE command it receives and the negotiated Transfer Syntax agreed upon during Association Negotiation.
DICOM SERVICE CLASS PROVIDER
Key Characteristics of an SCP
The Service Class Provider (SCP) is the server-side Application Entity in a DICOM network that passively listens for and executes operations requested by a Service Class User (SCU). An SCP is defined not by its hardware, but by the specific set of SOP Classes it agrees to support during Association Negotiation.
01
Passive Listener Role
An SCP operates as a TCP/IP server, listening on a well-known port (typically 104 or 2762 for TLS) for incoming Association Requests. It does not initiate connections. When a CT scanner (acting as an SCU) finishes a scan, it actively connects to the PACS archive (acting as an SCP) to push images. The SCP's primary function is to validate the request, perform the operation, and return a status code.
- C-STORE SCP: Receives and persists DICOM objects.
- C-FIND SCP: Queries its internal database and returns matching records.
- C-MOVE SCP: Initiates a secondary outbound C-STORE sub-operation to a third-party destination.
104
Default DICOM Port
2762
Default DICOM TLS Port
03
SOP Class Conformance
An SCP's identity is defined entirely by the SOP Classes it claims to support in its DICOM Conformance Statement. A single physical server can act as an SCP for multiple SOP Classes simultaneously. For example, a PACS archive typically provides the SCP role for:
- Storage SOP Classes: To receive images from modalities.
- Query/Retrieve SOP Classes: To allow workstations to search and pull studies.
- Storage Commitment SOP Class: To take responsibility for long-term safekeeping of objects.
Failure to support a required SOP Class is the most common cause of DICOM integration failure between vendors.
04
DIMSE Command Processing
The SCP processes incoming DIMSE (DICOM Message Service Element) command requests received over the established association. Each command is a structured data set containing a Command Field that specifies the operation type. The SCP must parse this command, execute the corresponding internal logic, and return a DIMSE response with a status code.
- Success (0x0000): Operation completed without error.
- Refused (0xA700): The SCP lacks resources to process the request.
- Data Set Does Not Match SOP Class (0xA900): The transmitted data violates the IOD definition.
A robust SCP implementation must handle malformed commands gracefully without crashing the association.
05
Verification SCP
The most basic SCP implementation is the Verification SOP Class, which responds to a C-ECHO request with a simple success status. This is the DICOM equivalent of a network 'ping' and is used to confirm basic connectivity and association-level compatibility before attempting complex operations.
- Every DICOM-compliant device must support the Verification SOP Class as both an SCU and an SCP.
- A failed C-ECHO typically indicates a firewall block, incorrect port configuration, or mismatched AE Titles.
- Integration engineers use C-ECHO as the first diagnostic step when troubleshooting a broken DICOM connection.
06
Storage Commitment SCP
A critical SCP role for data integrity is the Storage Commitment Push Model. After an SCU (modality) sends images via C-STORE, it requests a Storage Commitment from the SCP (PACS). The SCP takes ownership of the objects and guarantees their safekeeping. The modality is then free to delete its local copies.
- The SCP must persist the commitment obligation across system reboots.
- If the SCP cannot fulfill the commitment (e.g., disk failure), it must send a notification with a failure reason.
- This mechanism prevents data loss during the critical window between image acquisition and archival confirmation.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read moreDICOM SERVICE CLASS PROVIDER
Frequently Asked Questions
Clear, technical answers to the most common questions about the SCP role in DICOM network communication, its relationship to other Application Entities, and its critical function in medical imaging workflows.
A Service Class Provider (SCP) is the DICOM Application Entity (AE) that listens for and performs a requested network operation on behalf of a Service Class User (SCU). In the classic client-server model, the SCP acts as the server. It passively waits for an incoming association request, accepts the negotiated connection, and then executes the command sent by the SCU. For example, a PACS archive functions as an SCP when it receives and stores images pushed from a CT scanner via the C-STORE command. The SCP role is defined by the specific SOP Class it supports; a single AE can be an SCP for storage services while simultaneously acting as an SCU for query services. The SCP is responsible for returning a status code indicating the success or failure of the requested operation.
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us