Difference between revisions of "IHERO UseCase Anonymization"

From IHE Wiki
Jump to navigation Jump to search
 
(11 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
  
==1. Proposed Workitem: ''Radiotherapy Patient Anonymization''==
+
==1. Proposed Workitem: ''Clinical Trials submission II-Radiotherapy Patient Anonymization''==
  
 
* Proposal Editor: ''C.Field''
 
* Proposal Editor: ''C.Field''
Line 10: Line 10:
  
 
==2. The Problem==
 
==2. The Problem==
The anonymization and electronic submission of radiotherapy data for clinical trials quality assurance (QA) and storage in a central RT data repository requires some development and standardization.  The current process does not support  
+
1. The anonymization and electronic submission of radiotherapy data for clinical trials quality assurance (QA) and storage in a central RT data repository requires some development and standardization.  The current process does not support  
 
* the specification of which DICOM tags to anonymize (a configuration file which specifies which tags would be really nice)
 
* the specification of which DICOM tags to anonymize (a configuration file which specifies which tags would be really nice)
 
* a standard technique for performing the electronic transfer in a secure encrypted environment compliant with HIPPA in USA, FOIP and Health Information Act in Alberta, and regulations from other countries
 
* a standard technique for performing the electronic transfer in a secure encrypted environment compliant with HIPPA in USA, FOIP and Health Information Act in Alberta, and regulations from other countries
 +
2. Anonymization of data requested by the vendor for the troubleshooting of system issues is not currently possible.  The vendor must remotely view the operation of the system without the use of optimal software analysis tools.
 +
 +
3. The ability of users to assist one another or cooperate in developing treatment techniques/plans for difficult or uniques cases by electronically sharing patient data anonymously does not exist.  This situation is further complicated if institutions use different vendor's treatment planning systems.
  
 
==3. Key Use Case==
 
==3. Key Use Case==
 
'''How it currently works'''<br>
 
'''How it currently works'''<br>
For clinical trial submission on a treatment planning system, a user selects the patient to export.  The data is exported to a local file system.  Somehow the user is required to anonymize the data (the ITC_DICOMpiler provides this tool, but it misses some tags).  The data is then SFTP’d (or couriered on a CD) to the ITC centre in St.Louis, QARC, or elsewhere.  Treatment record information may not be sent in a DICOM-RT format, but should be anonymized if it was.   
+
For clinical trial submission on a treatment planning system, a user selects the patient to export.  The data is exported to a local file system.  Somehow the user is required to anonymize the data (the ITC_DICOMpiler provides this tool, but it misses some tags).  The data is then SFTP’d (or couriered on a CD, or mailed) to the ITC centre in St.Louis, QARC, or elsewhere.  Treatment record information is generally not sent in a DICOM-RT format, but as screen captures or printed copies.   
 
<br>
 
<br>
  
 
'''How it should work'''<br>
 
'''How it should work'''<br>
From a treatment planning system, virtual simulator, record and verify system, or imaging modality, the user selects a patient, the type of data required for export (e.g. CT, MR, structures, plans, doses, DVH, DRRs, treatment records), specific subsets of data (e.g. which structures to export and which DVHs to export), select tags to anonymize, select data repository to receive the data.  The data should then be anonymized, encrypted, and transmitted to the selected data repository.
+
From a treatment planning system, virtual simulator, or record and verify system the user selects a patient, the type of data required for export (e.g. CT, MR, structures, plans, doses, DVH, DRRs, treatment records), specific subsets of data (e.g. which structures to export and which DVHs to export), select tags to anonymize, select the data repository to receive the data.  The data would then be anonymized, encrypted, and transmitted to the selected data repository.
  
 
==4. Standards & Systems==
 
==4. Standards & Systems==
  
Treatment planning systems, virtual simulation system, record & verify systems, CT scanners, MR scanner, PET and other scanners, Picture Archive and Communication Systems (PACS).<br>
+
Affected Systems:
DICOM-RT, caBIG
+
:* Treatment planning systems, virtual simulation system, record & verify systems, CT scanners, MR scanner, PET and other scanners, Picture Archive and Communication Systems (PACS).
 +
 
 +
Related Standards:
 +
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev9-0ft_vol1_2008-06-27.pdf IHE Teaching File & Clinical Trial Export (TCE) Profile]
 +
:* [http://wiki.ihe.net/index.php?title=Pseudonymization_White_Paper_QRPH IHE QRPH Pseudonymization White Paper]
 +
:* [http://www.dclunie.com/dicom-status/status.html#Supplement142 DICOM Sup 142] (effectively replaces and updates DICOM Sup 55)
 +
:* DICOM-RT, caBIG
  
 
==5. Discussion==
 
==5. Discussion==
This really isn't an inter-operability issue.
+
This may not be a typical inter-operability issue but represents a broad interpretation of inter-operability since it will allow thousands of RT facilities to pool data originated by various vendors into a database that can advance the entire discipline of radiation oncology.  This is a big idea that needs the support of a multi-vendor effort that is the essence of IHE-RO.

Latest revision as of 06:12, 3 October 2010


1. Proposed Workitem: Clinical Trials submission II-Radiotherapy Patient Anonymization

  • Proposal Editor: C.Field
  • Editor: C.Field
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiation Oncology

2. The Problem

1. The anonymization and electronic submission of radiotherapy data for clinical trials quality assurance (QA) and storage in a central RT data repository requires some development and standardization. The current process does not support

  • the specification of which DICOM tags to anonymize (a configuration file which specifies which tags would be really nice)
  • a standard technique for performing the electronic transfer in a secure encrypted environment compliant with HIPPA in USA, FOIP and Health Information Act in Alberta, and regulations from other countries

2. Anonymization of data requested by the vendor for the troubleshooting of system issues is not currently possible. The vendor must remotely view the operation of the system without the use of optimal software analysis tools.

3. The ability of users to assist one another or cooperate in developing treatment techniques/plans for difficult or uniques cases by electronically sharing patient data anonymously does not exist. This situation is further complicated if institutions use different vendor's treatment planning systems.

3. Key Use Case

How it currently works
For clinical trial submission on a treatment planning system, a user selects the patient to export. The data is exported to a local file system. Somehow the user is required to anonymize the data (the ITC_DICOMpiler provides this tool, but it misses some tags). The data is then SFTP’d (or couriered on a CD, or mailed) to the ITC centre in St.Louis, QARC, or elsewhere. Treatment record information is generally not sent in a DICOM-RT format, but as screen captures or printed copies.

How it should work
From a treatment planning system, virtual simulator, or record and verify system the user selects a patient, the type of data required for export (e.g. CT, MR, structures, plans, doses, DVH, DRRs, treatment records), specific subsets of data (e.g. which structures to export and which DVHs to export), select tags to anonymize, select the data repository to receive the data. The data would then be anonymized, encrypted, and transmitted to the selected data repository.

4. Standards & Systems

Affected Systems:

  • Treatment planning systems, virtual simulation system, record & verify systems, CT scanners, MR scanner, PET and other scanners, Picture Archive and Communication Systems (PACS).

Related Standards:

5. Discussion

This may not be a typical inter-operability issue but represents a broad interpretation of inter-operability since it will allow thousands of RT facilities to pool data originated by various vendors into a database that can advance the entire discipline of radiation oncology. This is a big idea that needs the support of a multi-vendor effort that is the essence of IHE-RO.