Use the Healthcare: Web service to DICOM pattern to integrate an application written using web services with DICOM applications that support C-FIND and C-MOVE operations. You can use the pattern to query patients, studies, series and images from a DICOM archive (PACS) using a web service implemented by IBM Integration Bus.
An instance of the Healthcare: Web service to DICOM pattern is configured with the DICOM connection details of the PACS. The connection information includes the host name and port of the PACS. DICOM applications identify themselves when they connect. Therefore, you configure the pattern with the application entity titles (AETs) of the IBM Integration Bus pattern instance and the PACS.
The Healthcare: Web service to DICOM pattern uses the DICOMFindMove node to interface to the PACS. The DICOMFindMove node has two closely related capabilities. The first capability is to query a PACS for patients, studies, series and images. The search criteria are specified in an XML message propagated to the input terminal of the node. The results of the DICOM queries propagate from the output terminal of the node.
The second capability of the DICOMFindMove node is to move the results of a query to a DICOM application using a C-MOVE command. The destination of a C-MOVE command could be a DICOMInput node configured in IBM Integration Bus, this enables very flexible routing topologies to be configured. The destination of the C-MOVE command is specified as an application entity title (AET) in the XML message. The PACS must be pre-configured with the C-MOVE destination so it will know where to send the DICOM object instances.
The requesting application sends the search criteria as an XML body in the SOAP request message. The main message flow generated by the Healthcare: Web service to DICOM pattern instance extracts the body and passes it to the DICOMFindMove node. The XML results propagated by the DICOMFindMove node are sent back to the requesting application in a SOAP response.
If an error occurs during a C-FIND or C-MOVE command, the message flow throws an exception. The exception list contains inserts which describe the problem. The pattern provides optional error handling based on an error queue. If error handling is enabled, and an exception is thrown, the error is logged to an error queue and an error HTTP response message is sent back to the requesting application.
DICOM defines several types of C-FIND queries, these are called query roots. The roots supported by the DICOMFindMove node are patient and study. There are several other query roots but these have been retired in the DICOM standard.
The patient root allows four levels of query: patient, study, series and image. The patient level query is used to query a PACS for patients. It has a small number of permissible attributes which can be used in the query, such as the patient name, patient sex and birth date. The study level query is used to query a PACS for the studies for a given patient. The study level query must include the patient ID attribute and zero or more optional attributes to further refine the search, such as the study date. The series level query is used to query a PACS for the series within a specific study. The series level query must include the study UID and zero or more optional attributes to further refine the search, such as the modality. Finally, the image level query is used to query for specific images in a series. It is little used. An image level query must include the series UID.
The study root is similar to the patient root, and this similarity often causes confusion. There is no patient level query in the study root. The first supported level is the study level query. This query has a larger set of permissible attributes which can be used. Supported attributes include the study date, study time, and also attributes of a patient such as the patient name, patient ID and patient sex. This study level query can therefore be considered a merging of the study and patient level queries from the patient root. The study level query is very useful because in one go you can query for all the studies for a patient given some basic search criteria like patient name and study date. The series level and image level queries are identical in the study root and the patient root.
The DICOMFindMove node supports the two roots and the seven query levels described above (four in the patient root, three in the study root). For each root and level combination, the node defines the supported search attributes and a minimum set of attributes which are returned by the PACS. Note that a query can return many result messages; these are propagated as a single message from the DICOMFindMove node and therefore they are returned as a single XML message in the SOAP response.
Vendors may support additional attributes which can be used as search criteria in the XML query message, or returned in the result messages. The node allows these to be configured in the XML query message but they are not documented by the Healthcare: Web service to DICOM pattern because they are vendor specific. DICOM requires that whatever search attributes are provided in the search criteria, are also returned in responses.
The pattern instance generates message flows that implement a web service. The pattern instance also generates a WSDL file that represents the web services interface between a requesting application and IBM Integration Bus.
The WSDL file generated by the pattern instance configures the SOAPInput node in the generated message flows. The WSDL files can also be used by requesting applications to ensure SOAP requests are sent and received in the correct format.
The WSDL file is a WS-I compliant web services description. The WSDL file
contains a WSDL port type definition, and a single operation for sending C-FIND
and C-MOVE requests. The operation has an input message and an output message.
The request message is very flexible because it supports the seven different
types of query message for the two query roots. The pattern instance also
generates an XML schema file. The XML schema represents the data types for the
request and response messages. The schema file is included in the WSDL file
using a standard WSDL include statement.
The WSDL and the schema must both be deployed to IBM Integration Bus alongside the generated message flows. Starting from WebSphere Message Broker Version 8.0, you do not need to import the WSDL file and the XML schema file into a message set before you deploy them to an integration node. The WSDL and schema are automatically packaged in a BAR file by the IBM Integration Toolkit.