Difference between revisions of "Quality-Controlled Image Transfer (QCIT)- XDM DICOM Mail - Proposal"
Terisippel (talk | contribs) |
|||
| Line 2: | Line 2: | ||
*Proposal Editor: Dr. Marc Kämmerer, VISUS, kaemmerer@visus.com | *Proposal Editor: Dr. Marc Kämmerer, VISUS, kaemmerer@visus.com | ||
| − | *Editor: Combined Working Group of IHE Germany and the German Radiological Society on XDM DICOM Mail,
c/o Dr. Marc Kämmerer, kaemmerer@visus.com | + | *Editor: |
| − | + | *Contributors: Combined Working Group of IHE Germany and the German Radiological Society on XDM DICOM Mail,
c/o Dr. Marc Kämmerer, kaemmerer@visus.com | |
| − | |||
*Domain: Radiology (RAD) | *Domain: Radiology (RAD) | ||
[[Category:RAD]] | [[Category:RAD]] | ||
| Line 11: | Line 10: | ||
'''2. The Problem''' | '''2. The Problem''' | ||
| − | + | Health professionals need a secure, straightforward and standardized solution for the ad-hoc peer-to-peer communication of DICOM-based (and other) data. The infrastructure needs to be simple to set up. The connections need to be reliable and constantly available. There must be mechanisms to monitor the availability so basic quality control can be implemented. | |
| − | In many teleradiology settings | + | Existing profile solutions have gaps: |
| − | + | * XDS and XDS-I require a rather complex infrastructure (affinity domain) to be established before communication is possible. In many teleradiology settings peer-to-peer communication is sufficient and email is readily available. | |
| − | + | * XD* require changes in security policies of the health organizations involved while firewalls have already addressed email. | |
| − | + | * XD* to not provide sufficient mechanisms for quality control/availability | |
| − | |||
| Line 24: | Line 22: | ||
'''3.1. Key Use Case #1: Time Critical Transfer of Health Information''' | '''3.1. Key Use Case #1: Time Critical Transfer of Health Information''' | ||
| − | A trauma patient is | + | * A trauma patient is admitted to the emergency department of Hospital A and needs a full body CT scan. |
| − | + | * The patient may need to be transferred to a Trauma Center | |
| − | + | * While scanning the patient, the images are immediately transferred to the associated Trauma Center to save time for making the transfer decision. | |
| − | + | * ''Without QCIT'' | |
| − | The on-call physician at the Trauma Center | + | ** The Trauma Center physician must wait at the workstation until Hospital A notifies him when the transmission is complete and the number of images he should have received. |
| + | ** Trauma Center physician counts the received images and compares this to the reported number from Hospital A to make sure he has seen all the images. | ||
| + | * ''With QCIT'' | ||
| + | ** The on-call physician at the Trauma Center is notified by his workstation when a transmission is complete. | ||
'''3.2. Key Use Case #2: Analyzing Transmission Irregularities''' | '''3.2. Key Use Case #2: Analyzing Transmission Irregularities''' | ||
| Line 42: | Line 43: | ||
Systems involved in the solution: | Systems involved in the solution: | ||
| − | Teleradiology/-medicine Systems, PACS, Information Systems (e.g., HIS, RIS), Health Record Systems (e.g., EHR, PHR) | + | * Teleradiology/-medicine Systems, PACS, Information Systems (e.g., HIS, RIS), Health Record Systems (e.g., EHR, PHR) |
| − | Referenced Standards | + | Referenced Standards: |
| − | RFC 4134 Examples of S/MIME Messages | + | * RFC 4134 Examples of S/MIME Messages |
| − | ITI TF-2b: 3.41.3 ITI-41 Provide and Register Document Set-b | + | * ITI TF-2b: 3.41.3 ITI-41 Provide and Register Document Set-b |
| − | ITI TF-2b: 3.32.3 ITI-32 Distribute Document Set on Media | + | * ITI TF-2b: 3.32.3 ITI-32 Distribute Document Set on Media |
'''5. Discussion''' | '''5. Discussion''' | ||
| − | The proposed profile (QCIT) is a transaction and workflow profile. The first draft of the profile has already been written by the Combined Working Group of IHE Germany and the German Radiological Society together with the German Association of Health-IT Vendors (bvitg). | + | The proposed profile (QCIT) is based on XDM and reuses its directory structure, in which one or more XDS submission sets can be included. This means that the new profile can also serve as an intermediate step for establishing full XDS / XDS-I based networks. |
| − | QCIT defines two new actors, the Transmission Set Creator and the Transmission Set Receiver, along with the transaction Distribute Transmission Set via Email. This transaction | + | |
| − | + | QCIT is a transaction and workflow profile. The first draft of the profile has already been written by the Combined Working Group of IHE Germany and the German Radiological Society together with the German Association of Health-IT Vendors (bvitg). | |
| − | To maintain the necessary privacy of patient data and provision of the authenticity of the sender the profile | + | |
| + | QCIT defines two new actors, the Transmission Set Creator and the Transmission Set Receiver, along with the transaction Distribute Transmission Set via Email. This transaction uses zipped and encrypted data as specified by XDM. | ||
| + | |||
| + | To monitor the availability of services, QCIT defines structures for implementing basic quality control mechanisms. These structures enable the users as well as service providers to monitor the dataflow in regards to availability, speed and correctness of each transmission. | ||
| + | |||
| + | To maintain the necessary privacy of patient data and provision of the authenticity of the sender the profile requires that all transmitted data be encrypted and signed according to the S/MIME standard. | ||
A specification similar to the proposed profile has been used in Germany for over a decade for transferring millions of DICOM studies. Now, other countries like Holland, Austria, Switzerland and Greece are also showing interest in using email-based communication as described by this profile proposal. | A specification similar to the proposed profile has been used in Germany for over a decade for transferring millions of DICOM studies. Now, other countries like Holland, Austria, Switzerland and Greece are also showing interest in using email-based communication as described by this profile proposal. | ||
| − | The risk for creating the new profile is | + | The risk for creating the new profile is reduced as most parts for profile have been taken from either existing IHE profiles or other existing standards. |
Latest revision as of 15:49, 9 May 2016
1. Proposed Workitem: Quality-Controlled Image Transfer (QCIT)
- Proposal Editor: Dr. Marc Kämmerer, VISUS, kaemmerer@visus.com
- Editor:
- Contributors: Combined Working Group of IHE Germany and the German Radiological Society on XDM DICOM Mail, c/o Dr. Marc Kämmerer, kaemmerer@visus.com
- Domain: Radiology (RAD)
2. The Problem
Health professionals need a secure, straightforward and standardized solution for the ad-hoc peer-to-peer communication of DICOM-based (and other) data. The infrastructure needs to be simple to set up. The connections need to be reliable and constantly available. There must be mechanisms to monitor the availability so basic quality control can be implemented.
Existing profile solutions have gaps:
- XDS and XDS-I require a rather complex infrastructure (affinity domain) to be established before communication is possible. In many teleradiology settings peer-to-peer communication is sufficient and email is readily available.
- XD* require changes in security policies of the health organizations involved while firewalls have already addressed email.
- XD* to not provide sufficient mechanisms for quality control/availability
3. Key Use Cases
3.1. Key Use Case #1: Time Critical Transfer of Health Information
- A trauma patient is admitted to the emergency department of Hospital A and needs a full body CT scan.
- The patient may need to be transferred to a Trauma Center
- While scanning the patient, the images are immediately transferred to the associated Trauma Center to save time for making the transfer decision.
- Without QCIT
- The Trauma Center physician must wait at the workstation until Hospital A notifies him when the transmission is complete and the number of images he should have received.
- Trauma Center physician counts the received images and compares this to the reported number from Hospital A to make sure he has seen all the images.
- With QCIT
- The on-call physician at the Trauma Center is notified by his workstation when a transmission is complete.
3.2. Key Use Case #2: Analyzing Transmission Irregularities
Health Professional (HP) A is sending images to Health Professional (HP) B on regular basis. Suddenly HP B complains that the images do not reach him in time anymore. Key Use Case Proceeding - Procedure without QCIT HP A and HP B have to compare their log files. They have to calculate the transmission times and they have to determine if there are any discrepancies, e.g., loss of transmissions or multiple retransfers. Key Use Case Proceeding - Procedure with QCIT HP A extracts a complete transmission protocol based on the information he received with the enhanced notification messages from each individual email transmission. With this information, HP A and HP B, respectively, can easily locate or rule out any technical problems.
4. Standards and Systems
Systems involved in the solution:
- Teleradiology/-medicine Systems, PACS, Information Systems (e.g., HIS, RIS), Health Record Systems (e.g., EHR, PHR)
Referenced Standards:
- RFC 4134 Examples of S/MIME Messages
- ITI TF-2b: 3.41.3 ITI-41 Provide and Register Document Set-b
- ITI TF-2b: 3.32.3 ITI-32 Distribute Document Set on Media
5. Discussion
The proposed profile (QCIT) is based on XDM and reuses its directory structure, in which one or more XDS submission sets can be included. This means that the new profile can also serve as an intermediate step for establishing full XDS / XDS-I based networks.
QCIT is a transaction and workflow profile. The first draft of the profile has already been written by the Combined Working Group of IHE Germany and the German Radiological Society together with the German Association of Health-IT Vendors (bvitg).
QCIT defines two new actors, the Transmission Set Creator and the Transmission Set Receiver, along with the transaction Distribute Transmission Set via Email. This transaction uses zipped and encrypted data as specified by XDM.
To monitor the availability of services, QCIT defines structures for implementing basic quality control mechanisms. These structures enable the users as well as service providers to monitor the dataflow in regards to availability, speed and correctness of each transmission.
To maintain the necessary privacy of patient data and provision of the authenticity of the sender the profile requires that all transmitted data be encrypted and signed according to the S/MIME standard.
A specification similar to the proposed profile has been used in Germany for over a decade for transferring millions of DICOM studies. Now, other countries like Holland, Austria, Switzerland and Greece are also showing interest in using email-based communication as described by this profile proposal.
The risk for creating the new profile is reduced as most parts for profile have been taken from either existing IHE profiles or other existing standards.