DICOM PS3.2 2022b - Conformance |
---|
This application provides Standard Conformance to the following DICOM SOP Classes:
DICOMSRV will support as many simultaneous associations as SCP as are requested by Workflow SCUs up to a configurable maximum. DICOMSRV limits the number of concurrent associations to a given Workflow SCU as described below.
DICOMSRV will accept associations for the MWL, MPPS and Verification SOP Classes as an SCP. The job runs in the background and forks a new process for each connection request from a Remote AE
When Modality Worklist SCUs query DICOMSRV the queries run against the Scheduled Procedure Step Worklist (referred to hereafter as the 'SPS Worklist' or 'Worklist') in the DICOMRis database. There is a configurable mapping between the Universal Service ID contained in the HL7 Order messages (see Table C.8.1-4) and one or more Requested Procedures within the DICOMRis database. A Requested Procedure may, in turn, map to 1 or more Scheduled Procedure Steps though the relation is usually 1-to-1. This mapping is also site-configurable. The relation between Accession Number (0008,0050) and Requested Procedure ID (0040,1001) is 1-to-1 within DICOMRis and these attributes have the same value in all MWL responses. Scheduled Procedure Step entries are added and removed from the Worklist as follows:
Add Scheduled Procedure Step Entries Normal Pathway - As orders are received from the HIS via HL7 or entered using DICOMRis' Ordering and Scheduling application, additions are made to the SPS Worklist in the DICOMRis database per the mapping specified above.
Add Scheduled Procedure Step Entries Exception Pathway - Users can interactively create additional Scheduled Procedure Step entries for a given Requested Procedure using the Procedure Update application. It may be necessary to create additional entries under certain conditions such as when it is discovered that a procedure must be redone after having previously been marked as completed. This does not apply to canceled procedures
Remove Scheduled Procedure Step Entries Normal Pathway - An SPS entry is removed from the SPS Worklist under the following circumstances:
As mentioned previously, DICOMRis supports common RIS function to set the state of the procedure as it progresses from being ordered to being resulted and signed. Setting the procedure state may be initiated interactively via the Procedure Update application or as a result of various events. An entry in the SPS Worklist is removed when the Requested Procedure that is the parent of the SPS is set to a configured status. This configuration is system-wide applying equally to all procedures.
If configured to change the state of a Requested Procedure on receipt of an MPPS N-CREATE or N-SET referencing the procedure then the change in state may result in removal of SPS entries related to the procedure as described above
Remove Entries Exception Pathway - When a procedure is canceled all SPS entries related to that procedure are removed from the Worklist.
Remove Entries Maintenance Pathway - SPS entries that are still in the Worklist a configurable time after their scheduled start date/time will be removed by a day-end maintenance job.
In the table below the following applies:
Table C.4.2-5. Scheduled Procedure Step Entry Actions Table
The figure above is a possible sequence of messages between a Modality Worklist SCU and DICOMSRV.
The Modality opens an Association with DICOMSRV for the purpose of querying for a Modality Worklist
DICOMSRV queries its database using the attributes from the C-FIND Request and returns 0 to N C-FIND responses depending on matches returned from the database. DICOMSRV checks for a C-FIND Cancel Request after a configured number of responses are sent. If a Cancel is received then no further Pending responses are sent.
Table C.4.2-6. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity 'Configured AE Requests MWL Query'
DICOMSRV does not support matching on any optional matching key attributes.
DICOMSRV supports case-insensitive matching on the following Person Name Value Representation elements:
DICOMSRV supports optional return key attributes as described in the table below.
Table C.4.2-7. Modality Worklist Optional Return Keys Supported
DICOMSRV returns C-FIND response statuses as specified below.
Table C.4.2-8. MWL C-FIND Response Status Reasons
When a configured remote AE sends a conformant association request including one of the Modality Performed Procedure Step Presentation Contexts in the table below then DICOMSRV will accept the Association.
As mentioned above, DICOMSRV is started at system boot time and is thus ready to process MPPS messages at any time thereafter. The sequencing diagram below specifies a common flow of messages related to this activity. Prior to this sequence of messages it is necessary that orders have been received from the HIS interface or created via DICOMRis Ordering and Scheduling application. Attributes from the orders and created procedures, usually queried using MWL, will be included in the MPPS messages the Modality sends to DICOMSRV. Key attributes in the MPPS N-CREATE and N-SET, specified below, are extracted and matched against values in the DICOMRis database. A match allows full update of all applicable DICOMRis database tables.
The figure above is a possible sequence of messages and events for the Configured AE Makes Procedure Step Request activity.
The Modality opens an Association to update DICOMSRV using MPPS
The Modality sends an N-CREATE Request to indicate that it is performing one or more Requested Procedures
DICOMSRV stores the MPPS and executes the matching algorithm described in the conformance section below. If a successful match is found, then updates to various tables per the N-CREATE are performed. See Table C.4.2-10 for additional detail. In the matching case, the procedure state of the procedure(s) referenced in the MPPS is updated if so configured
The Modality sends an N-SET setting the status of the MPPS to COMPLETED
DICOMSRV stores the MPPS. If the N-CREATE for this step matched then updates are performed as specified in step 4
DICOMSRV also supports the 5 IHE Unidentified Patient Use Cases. Cases 1, 2 and 4 are transparent to the MPPS SCU and follow the normal flow. In case 3, the patient upon whom a given procedure must be immediately performed has been registered on the HIS and has a valid Patient ID but has no order specifying the applicable procedure. DICOMSRV recognizes this case when an MPPS N-CREATE is received with a matching Patient ID, zero-length Accession Number (0008,0050) and Requested Procedure ID (0040,1001). If the MPPS SCU is configured for support of IHE Trauma cases, DICOMSRV will order a procedure corresponding to the code contained in the Procedure Code Sequence (0008,1032), if this code is recognized, or will order a default procedure based on configuration. If the default procedure is ordered then a user may modify the procedure using DICOMRis Ordering and Scheduling application.
In case 5, there is no existing registration or order for a patient on whom a procedure must be immediately performed. Values are entered on the Modality identifying the patient and procedure. DICOMSRV recognizes this case when an MPPS N-CREATE is received containing a Patient ID within a configured range. This range will never contain Patient IDs created in the normal flow. If the MPPS SCU is configured for support of IHE Trauma cases, DICOMSRV will register the patient with the Patient ID provided and will order a procedure as described above.
Table C.4.2-9. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity "Configured AE Makes Procedure Step Request"
DICOMSRV's preferred Transfer Syntax is Explicit VR Little Endian and this will be selected if offered.
The table below lists all Modality Performed Procedure Step attributes, whether they may be created by N-CREATE and updated by N-SET and what parts of the DICOMRis database they are used to update. All MPPS messages and thus their attributes are stored for the configurable Purge Period described below. The 'Database Updates' column considers updates separate from the storage of MPPS messages. If no value is present this indicates that there are is no update to the database associated with the given element.
Table C.4.2-10. Supported N-SET/N-CREATE Attributes for MPPS
The list below details the behavior of DICOMSRV on occurrence of certain MPPS events and with respect to the coercion of attributes and duration of storage of MPPS messages:
Reception of a New MPPS Instance - The MPPS message is stored in the database. DICOMSRV will then extract the Patient ID (0020,0010) and as many Accession Numbers (0008,0050) as there are items in the Scheduled Step Attribute Sequence (0040,0270) from the N-CREATE and try to match these values against the Patient Medical Record Number and one or more Accession Numbers in the DICOMRis database. If a non-matching N-CREATE is received, it and any following N-SETs will be marked as exceptions. These exceptions can be reconciled using the RisView application. Otherwise, DICOMSRV will:
Update its database with values contained in the N-CREATE per table above.
Update the state of each referenced procedure if so configured.
Update of MPPS to 'DISCONTINUED' or 'COMPLETED' - The N-SET is stored in the database. If the preceding N-CREATE matched then the following is done:
The attribute values in the N-SET will be used to update the DICOMRis database per table above.
Update the state of each referenced procedure if so configured.
Coercion of Attributes - DICOMSRV will coerce attributes as specified in Table C.8.1-3. This coercion may occur when a given step is set to the 'IN PROGRESS' or 'COMPLETED' or 'DISCONTINUED'
Storage Duration for MPPS Messages - MPPS messages are purged from the DICOMRis database after a configurable period of time has elapsed since the step has been set to a final state or was last updated.
Table C.4.2-11. MPPS N-CREATE/N-SET Response Status Reasons
A remote AE sends an Echo Request to verify that DICOMSRV is awake and listening. DICOMSRV responds with success status as long as the request can be parsed.
Table C.4.2-12. Acceptable Presentation Contexts for AE DICOMSRV and Real-World Activity Configured AE Requests Verification
Depending on configuration, DICOMSRV may or may not accept multiple presentation contexts containing the same abstract syntax.
Transfer Syntaxes in addition to the default Implicit VR Little Endian may be configured for a given Abstract Syntax using DICOM Tool's configuration files. When this is done, the first Transfer Syntax encountered in the configuration file, which matches a Transfer Syntax offered for a given Presentation Context, will be selected as the accepted Transfer Syntax for that Presentation Context.
DICOM PS3.2 2022b - Conformance |
---|