*Studies are partially anonymized to remove unnecessary PHI (though not all PHI).

+

*Studies are stored, organized by patient ID.

−

*Studies are stored.

+

*A user account is automatically created, if necessary, for the patient when a study is received.

*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 view their studies at a web browser.

Line 29:

Line 28:

root="roots/dicom-import"

root="roots/dicom-import"

port="104" />

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

<FileStorageService

Line 53:

Line 45:

</pre>

</pre>

−

====Server====

+

===Server===

The configuration file places the CTP admin web server on port <b>1080</b>. 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 places the CTP admin web server on port <b>1080</b>. 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.

−

====DicomImportService====

+

===DicomImportService===

The configuration file puts the DicomImportService on the standard well-known DICOM port, (<b>104</b>). The DicomImportService accepts all Application Entity Titles, so when configuring the transmitting systems (modalities or PACS), any AE Title can be used.

The configuration file puts the DicomImportService on the standard well-known DICOM port, (<b>104</b>). The DicomImportService accepts all Application Entity Titles, so when configuring the transmitting systems (modalities or PACS), any AE Title can be used.

−

====DicomAnonymizer====

+

===FileStorageService===

−

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 <b>@initials</b> 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.

+

−

+

−

====FileStorageService====

+

The <b>root</b> 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 <b>storage</b> directory. An absolute path may be specified instead, and that path can be on a shared drive on another computer if so desired.

The <b>root</b> 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 <b>storage</b> directory. An absolute path may be specified instead, and that path can be on a shared drive on another computer if so desired.

Line 92:

Line 81:

==Security Issues==

==Security Issues==

+

Two security issues merit special consideration. Both are addressed in the following enhanced configuration file.

+

<pre>

+

<Configuration>

+

+

<Server

+

port="1080"

+

ssl="yes"

+

require-authentication="yes" />

+

+

<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"

+

ssl="yes"

+

require-authentication="yes"

+

quarantine="quarantines/storage" />

+

+

</Pipeline>

+

+

</Configuration>

+

</pre>

+

===Server===

+

This configuration version enables Secure Sockets Layer (SSL) on the admin web server and also requires that a user be authenticated when accessing the admin web server. Neither of these provides much additional security, but they at least ensure that only users known to the system can access it, and they ensure that encryption keys, which can be part of an anonymizer script, are not transmitted in the clear when edited by an anonymizer configurator servlet.

+

+

===DicomAnonymizer===

+

This stage is included in the pipeline to allow unnecessary PHI to be removed before storage. The idea is simply to minimize the PHI surface area of the objects as much as possible without compromising their utility. A simple example of what might be done is to replace the patient's name with his initials (using the <b>@initials</b> function). This would help to conceal the patient's identity, but still give the user viewing the study some confidence that the object belongs to the subject patient.

+

+

<em>It is critically important, however, that the PatientID element (0008,0020) not be modified because the FileStorageService uses it to separate the studies by patient.</em>

+

+

The DicomAnonymizer provides many functions. See [[The CTP DICOM Anonymizer]] for the excruciating details.

+

+

===FileStorageService===

+

This configuration version enables SSL on the FileStorageService web server. Unlike the case of the dmin web server, enabling SSL significantly improves security since the objects accessed on this web server do contain at least some PHI.

+

==Research Applications==

==Research Applications==

Revision as of 19:19, 21 November 2008

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.

Contents

1 Requirements

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 stored, organized by patient ID.

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.

2.1 Server

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.

2.2 DicomImportService

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.

2.3 FileStorageService

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 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.

3 Operation

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.

4 Security Issues

Two security issues merit special consideration. Both are addressed in the following enhanced configuration file.

4.1 Server

This configuration version enables Secure Sockets Layer (SSL) on the admin web server and also requires that a user be authenticated when accessing the admin web server. Neither of these provides much additional security, but they at least ensure that only users known to the system can access it, and they ensure that encryption keys, which can be part of an anonymizer script, are not transmitted in the clear when edited by an anonymizer configurator servlet.

4.2 DicomAnonymizer

This stage is included in the pipeline to allow unnecessary PHI to be removed before storage. The idea is simply to minimize the PHI surface area of the objects as much as possible without compromising their utility. A simple example of what might be done is to replace the patient's name with his initials (using the @initials function). This would help to conceal the patient's identity, but still give the user viewing the study some confidence that the object belongs to the subject patient.

It is critically important, however, that the PatientID element (0008,0020) not be modified because the FileStorageService uses it to separate the studies by patient.

4.3 FileStorageService

This configuration version enables SSL on the FileStorageService web server. Unlike the case of the dmin web server, enabling SSL significantly improves security since the objects accessed on this web server do contain at least some PHI.