DOCSEARCHbyAlgolia
Submit Docs

pynetdicom Documentation

repository·main·Indexed 20 days ago

https://github.com/pydicom/pynetdicom

A pure Python implementation of the DICOM networking protocol. It enables developers to create DICOM Service Class Users (SCUs) and Service Class Providers (SCPs) for medical image exchange. The library includes several command-line applications for connectivity and query tasks, such as echoscp, echoscu, and findscu.

Tokens
151.9K
Snippets
282
Records
516
Agent score
66%

What's inside pynetdicom

  1. Explore pynetdicom code examples

    main

    The pynetdicom library provides several implementation examples for common DICOM service classes. You can use these examples to understand how to implement different DIMSE services, including:

    • Worklist Management: Using C-FIND for basic worklist tasks.
    • Display System Management: Using N-GET.
    • Modality Performed Procedure Step (MPPS): Using N-CREATE and N-SET.
    • Print Management: Implementing Basic Grayscale Print Management via N-CREATE, N-SET, N-GET, N-DELETE, and N-ACTION.
    • Query/Retrieve (Q/R):
      • C-FIND for finding objects.
      • C-GET and C-STORE for retrieving objects.
      • C-MOVE and C-STORE for moving objects.
    • Relevant Patient Information Query: Using C-FIND.
    • Storage: Using C-STORE.
    • Verification: Using C-ECHO.

  2. Use pynetdicom.utils for common tasks

    main

    The pynetdicom.utils module provides several helper functions for handling DICOM UIDs, byte conversions, and configuration.

    Available utilities include:

    • decode_bytes: Decodes byte sequences.
    • make_target: Creates a target object.
    • pretty_bytes: Formats byte sequences into a human-readable string.
    • set_ae: Sets the Application Entity (AE) configuration.
    • set_uid: Sets a UID.
    • validate_uid: Validates whether a string is a valid DICOM UID.

  4. What is a Presentation Context?

    main

    In DICOM, a Presentation Context defines the content and encoding of a piece of data (typically a DICOM dataset). It consists of three components:

    1. Context ID: An odd integer between 1 and 255 that identifies the context. In pynetdicom, this is usually managed automatically.
    2. Abstract Syntax: Defines what the data represents, typically identified by a SOP Class UID (e.g., 1.2.840.10008.1.1 for Verification SOP Class).
    3. Transfer Syntax: Defines how the data is encoded, identified by a Transfer Syntax UID (e.g., 1.2.840.10008.1.2 for Implicit VR Little Endian).

    In pynetdicom, these are managed using the PresentationContext class.

  5. What is Association Negotiation and Extended Negotiation

    main

    Association negotiation is the process where peer AEs agree on abstract syntax and transfer syntax combinations via presentation contexts.

    Extended Negotiation refers to the exchange of additional user information items during the association request to communicate specific features or service requirements. Common extended negotiation items include:

    • Asynchronous Operations Window Negotiation
    • SCP/SCU Role Selection Negotiation (e.g., required for C-GET operations)
    • SOP Class Extended Negotiation
    • SOP Class Common Extended Negotiation
    • User Identity Negotiation

    Some negotiation items are conditionally required depending on the requested service class.

  6. What is an Application Entity (AE)

    main

    In DICOM networking, an Application Entity (AE) is an application that supports the DICOM standard. This includes handling Information Object Definitions (IODs), service classes, and the encoding/decoding of DICOM datasets.

    To identify an AE during network communication, a unique identifier called an AE Title is used.

  7. What is an Abstract Syntax?

    main

    An Abstract Syntax is a specification of data elements and their semantics, identified by a unique Abstract Syntax Name (usually a SOP Class UID).

    While pynetdicom can negotiate associations involving private abstract syntaxes, the user is responsible for implementing the services associated with them. To support a custom or private abstract syntax, use the pynetdicom.sop_class.register_uid function.

  9. Understand the DICOM Information Model

    main

    The DICOM Information Model is built upon three hierarchical concepts that define how data is structured and how services are provided between Application Entities (AEs):

    1. Information Object Definition (IOD): An object-oriented abstract data model representing real-world objects (e.g., Patient, Study, Series, Equipment).
      • Normalised IODs: Represent a single class of real-world objects.
      • Composite IODs: Include information about multiple related real-world objects (e.g., a CT Image IOD containing Patient and Study information).
    2. SOP Classes (Service-Object Pair Classes): The union of an IOD and a DIMSE service group. This defines how a specific type of data is handled.
      • Composite SOP Classes: Union of a Composite IOD and the DIMSE-C service group (e.g., CT Image Storage SOP Class).
      • Normalised SOP Classes: Union of a Normalised IOD and the DIMSE-N service group (e.g., Print Job SOP Class).
      • Each SOP Class is uniquely identified by a UID.
    3. Service Classes: A group of one or more SOP Classes related to a specific service (e.g., Storage Service Class, Verification Service Class, Query/Retrieve Service Class).

  10. Implement SCP services as a Service Class Provider

    main

    When acting as a Service Class Provider (SCP), you must bind user-defined callable functions (handlers) to specific intervention events to process incoming DIMSE requests.

    To implement an SCP:

    1. Import events: from pynetdicom import evt.
    2. Define handler functions that accept a single event parameter (an Event object).
    3. Bind handlers to events using the evt_handlers keyword argument in AE.start_server() or AE.associate().

    Supported Intervention Events:

    • evt.EVT_C_ECHO (C-ECHO)
    • evt.EVT_C_FIND (C-FIND)
    • evt.EVT_C_GET (C-GET)
    • evt.EVT_C_MOVE (C-MOVE)
    • evt.EVT_C_STORE (C-STORE)
    • evt.EVT_N_ACTION (N-ACTION)
    • evt.EVT_N_CREATE (N-CREATE)
    • evt.EVT_N_DELETE (N-DELETE)
    • evt.EVT_N_EVENT_REPORT (N-EVENT-REPORT)
    • evt.EVT_N_GET (N-GET)
    • evt.EVT_N_SET (N-SET)

    Note: Handlers must return or yield specific values depending on the event type to correctly complete the DIMSE service request. Refer to the pynetdicom.events documentation for specific return requirements.

    from pynetdicom import AE, evt

def handle_store(event):
    # Process the C-STORE request
    return True

ae = AE()
ae.start_server(evt_handlers={evt.EVT_C_STORE: handle_store})

  12. Structure of an A-ASSOCIATE-AC PDU

    main
    An A-ASSOCIATE-AC PDU (Protocol Data Unit) is used during the association process. It consists of a sequence of mandatory fields followed by a variable-length section. This variable section must contain exactly one ApplicationContextItem, one or more PresentationContextItemAC items, and one UserInformationItem. Both the Presentation Context and User Information items require sub-items to be valid.