CTP Configuration for Study Distribution
This article describes how the CTP application can be configured to distribute patient studies to referring physicians and researchers. The intended audience for this article is system administrators. There are several articles on CTP on the RSNA MIRC wiki. All would be useful references when reading this article.
Many hospitals distribute digital examinations to referring physicians by producing DICOM CDs. The cost and time to produce and distribute these CDs, along with the lack of standardization of the software viewers for them, has limited their acceptance by referring physicians, although most people acknowledge the need to make such information available quickly and conveniently.
This section describes a CTP configuration with these features:
- Studies are received from modalities or PACS via the DICOM protocol.
- Studies are partially anonymized to remove unnecessary PHI (though not all PHI).
- Studies are stored.
- A user account is automatically created, if necessary, for the patient when a study is received.
- Patients can view their studies at a web browser.
- Patients can download and/or delete their studies.
- Patients can make their images available to their physicians, either by providing their credentials to their physicians or by granting their physicians guest access to their studies.
- Administrators can grant physicians guest access to a patient's studies on behalf of the patient.
- The system can automatically remove studies older than a specified age.
2 The Configuration File
The configuration of a CTP instance is specified by an XML file called config.xml located in the same directory as the program. See the main wiki article for details on how CTP processes data objects and all the standard pipeline stages that are available. This section describes only those standard stages which are necessary to implement this application, and only those attributes which are required to provide the necessary features.
<Configuration> <Server port="1080" /> <Pipeline name="Pipeline"> <DicomImportService name="DICOM Import Service" class="org.rsna.ctp.stdstages.DicomImportService" root="roots/dicom-import" port="104" /> <DicomAnonymizer name="DICOM Anonymizer" class="org.rsna.ctp.stdstages.DicomAnonymizer" root="roots/anonymizer" script="roots/anonymizer/scripts/da.script" quarantine="quarantines/anonymizer" /> <FileStorageService name="File Storage Service" class="org.rsna.ctp.stdstages.FileStorageService" root="storage" timeDepth="90" fs-name-tag="00080020" auto-create-user="yes" port="80" require-authentication="yes" quarantine="quarantines/storage" /> </Pipeline> </Configuration>
The configuration file places the CTP admin web server on port 1080. This web server is used by administrators to monitor the status of the system. The choice of 1080 rather than the standard port 80 is made to preserve port 80 for the FileStorageService's web server.
The configuration file puts the DicomImportService on the standard well-known DICOM port, (104). The DicomImportService accepts all Application Entity Titles, so when configuring the transmitting systems (modalities or PACS), any AE Title can be used.
This stage is included in the pipeline to allow unnecessary PHI to be removed before storage. An example of what might be done is to replace the patient's name with his initials (using the @initials function). The PatientID element (0008,0020), however, must not be modified because the FileStorageService uses it to separate the studies by patient. The DicomAnonymizer provides many functions. See The CTP DICOM Anonymizer for the excruciating details. If anonymization is not required, this stage can be removed from the configuration file.
The root attribute can point to any location where the FileStorageService can build its directory structure. It is shown in the configuration above as a relative path from the CTP directory (the directory in which the CTP application runs) to the storage directory. An absolute path may be specified instead, and that path can be on a shared drive on another computer if so desired.
The fs-name-tag attribute is critical to the operation of this application. It is specified to point to the DICOM PatientID attribute. This causes the FileStorageService to create a separate tree of directories for each patient and to store all the patient's studies in that tree. Since access is restricted by such trees, this ensures that each patient can only see his own studies. For more information on the organization of directories, see the notes in FileStorageService.
The timeDepth attribute is included with its value set to 90. Studies older than 90 days will then automatically be deleted. If permanent storage is desired, the attribute should be set to zero.
The FileStorageService web server is enabled in this configuration by specifying a port attribute. The value, 80, assumes that this will be the most convenient port for users.
The require-authentication attribute is required to ensure that only authorized users can view studies. More information on access to studies is contained in The CTP FileStorageService Access Mechanism.
The auto-create-user attribute is included so that the system will create user accounts for users as their studies are received. This is only an administrative convenience. Administrators can use the User Manager servlet on the main admin web server to create and manage accounts at any time.
The simplest way to use this application in practice is to install it on a computer in the institution's DMZ and open port 80 for access from the internet. This will allow modalities or the PACS to transmit studies from the protected network to CTP. It will also allow patients and their guests to access the studies while still protecting the secure network from the internet.
Two approaches can be taken for getting studies to CTP. One sends the studies automatically; the other requires manual selection and transmission.
- The automatic case can be implemented by having the modalities automatically send studies to the DicomImportService when they transmit them to the PACS. Equivalently, it may be possible to configure a PACS to forward studies when they are received. If neither of those approaches is convenient, the RSNA MIRC project has a tool, DicomRouter, which receives studies and forwards them to multiple destinations.
- The manual case requires someone to select the study at a PACS workstation and send it to the DicomImportService.
Once the studies are in the FileStorageService, they are automatically available for access.
Three approaches can be taken for providing referring physicians access to their patients' studies.
- The simplest approach is to require the patient to give the referring physician his credentials (PatientID and password) on the FileStorageService's web server. In this case, when the physician logs in, the system thinks he is the patient, and he will have all the privileges of the patient, including the ability to delete cases.
- A more complex approach is to create accounts for all referring physicians and require the patient to access the web server, click the Manage Guest List button, and add the referring physician to the guest list. In this case, when the physician logs in, the system knows who he is and provides access to all patients on whose guest list he appears. The guest privilege provides access to the studies for viewing but not for deletion.
- In the case where a patient cannot access the web server, an administrative user with the proxy privilege can log in as himself, and add a referring physician to a patient's guest list on behalf of the patient.
All three approaches can be used concurrently since they are all equivalent as far as the system is concerned. Each has advantages and disadvantages. The first is simplest to operate and administer since it requires no manual intervention by hospital staff, but it grants referring physicians more control than some patients might want. The other approaches are more secure in that regard, but they require work by hospital staff.