Difference between revisions of "REM for Radiopharmaceutical Imaging - Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 103: Line 103:
 
:* Review existing REM transactions for payload dependence.
 
:* Review existing REM transactions for payload dependence.
 
::* Draft payload extension paragraphs for affected transactions
 
::* Draft payload extension paragraphs for affected transactions
 +
:* Decide if we want to make anything that's optional in Sup159 be required.
 
:* Decide on dataflow pattern from hotlab to modality
 
:* Decide on dataflow pattern from hotlab to modality
 
::* Clone/revise REM Vol. 1 text
 
::* Clone/revise REM Vol. 1 text
 
::* Draft transaction for scanner to find/retrieve RRD and copy some values into image headers.
 
::* Draft transaction for scanner to find/retrieve RRD and copy some values into image headers.
 
  
 
==6. Support & Resources==
 
==6. Support & Resources==
Line 125: Line 125:
 
::* Dose "Creator" could push directly to scanners
 
::* Dose "Creator" could push directly to scanners
 
::* Scanner could query/retrieve from Image Manager based on Patient/Accession info from Worklist
 
::* Scanner could query/retrieve from Image Manager based on Patient/Accession info from Worklist
 +
::* [Agfa] Would it make sense for the Dose Creator to use STOW-RS to send the RRD to DSS/OF and then the dose information will be available in MWL query?
 +
:::* Modality already widely supports MWL. So getting the RRD information from MWL query is a small incremental change
 +
:::* Most DSS/OF will likely be interested in the dose information, similar to REM
 +
:::* Using RESTful STOW-RS may lower the entry barrier given the hotlab systems traditionally do not use DICOM
 
:* How should the Dose "Creator" get the patient/procedure context?
 
:* How should the Dose "Creator" get the patient/procedure context?
 
::* MWL worklist
 
::* MWL worklist
 
::* MPPS?
 
::* MPPS?
 
::* HL7 Order?
 
::* HL7 Order?
 +
::* [Agfa] Need to take into account that the Dose Creator (e.g. hotlab systems) traditionally do not use DICOM. Adding more DICOM requirement (e.g. MWL) may prohibit the adoption.
 +
:* [Agfa] If the RRD is created before the acquisition, how should the Dose Creator manage to use a consistent study instance UID that matches the study that will be eventually acquired?
 +
::* Potentially it will be using the Study Instance UID from the scheduled order message, which the modality should be doing the same
 +
::* But how about the unscheduled case? Or is it relevant for PET / SPECT studies?
  
 
==9. Tech Cmte Evaluation==
 
==9. Tech Cmte Evaluation==
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* TBD
+
:* 20%
  
 
Candidate Editor:
 
Candidate Editor:
 
: Jeff Pohlhammer and/or Charles Smith (Co-authors of DICOM Sup159)
 
: Jeff Pohlhammer and/or Charles Smith (Co-authors of DICOM Sup159)
 
: Kevin O'Donnell (as IHE Mentor)
 
: Kevin O'Donnell (as IHE Mentor)

Latest revision as of 15:13, 23 September 2015


1. Proposed Workitem: REM for Radiopharmaceutical Imaging

  • Proposal Editor: Jeff Pohlhammer
  • Editor: Jeff Pohlhammer or Charles Smith (Co-authors of DICOM Sup159)
  • Domain: Radiology

Summary

Performers of PET or SPECT scans (which image radioactive materials administered into the patient's body) would like to track, analyze and reduce the patient dose, similar to the work done on CT dose, but they lack tools to make it easy/automatic.

DICOM has final texted Sup159 (Radiopharmaceutical Radiation Dose Reporting) which makes a new SR object that mirrors the RDSR that we used for IHE REM for CT and X-ray radiation dose .

The "front half" of the Profile would require the creation and distribution of the new SR object. The "back half" of the profile would be the same as IHE REM.

Modality (Philips) and IT vendors (Numa) have already demonstrated interest and brought resources. The Society of Nuclear Medicine has submitted a letter that such a profile would further the goals of the nuclear medicine community. Interest has also been expressed by individuals at Mallinkrodt/WashU, QIBA-PET, and Memorial Sloan Kettering.

This would be a logical continuation of the work in IHE REM.

2. The Problem

First, regulatory bodies are reviewing procedures for administration of radiopharmaceuticals and are beginning to require that radiopharmaceutical-related dose information be tracked and reported, similar to what has occurred for X-Ray-based radiation dose.

Second, the administration of radiopharmaceuticals for nuclear medicine procedures generally occurs prior to imaging, not at the imaging system. But the NM and PET Image IODs require information such as the pharmaceutical and isotope used, the amount of activity administered, and the time of administration. This often means operators manually transferring information, leading to errors which can compromise image quality and spoil quantitative measurements like SUV (Standardized Uptake Value).

IHE guidance is needed on how to use the DICOM Standard (Radiopharmaceutical Radiation Dose SR) in the clinical setting.

Ironically, for commonly used PET/CT scans, sites may have better access to the dose data from the CT used to estimate attenuation than from the PET scan providing the primary diagnostic information (and likely the larger dose).

Value Statement

Adoption of a Profile to address reporting and management of radiopharmaceutical dose will support the needs of the regulatory bodies, and provides both the regulatory bodies and clinical community a means for tracking and reporting radiopharmaceutical-related patient dose in a manner similar to that already adopted for ionizing radiation via the REM Profile.

There are savings in infrastructure cost, procedure and technical complexity to be gained by adopting a Profile that is similar to the existing REM profile, making use of many of the same actors and concepts.

This will eliminate the errors associated with manual transfer, reducing the number of repeat scans due to bad image quality and incorrect SUV measurements. So the Profile would provide operational/workflow benefits in addition to the dose management benefits of REM.

IHE is the right place to address the issues described above. IHE has already addressed similar issues in the REM profile, so it makes sense to resolve the same problems in the nuclear medicine domain. With the entire PET modality market, and increasing percentages of the NM modality market being hybrid systems, it makes sense to have a common solution for reporting dose from both the radiopharmaceutical and X-Ray contributions in a similar manner.

3. Key Use Case

Currently:

  • Patient arrives at the nuclear medicine lab.
  • Lab staff injects the patient with a radiopharmaceutical in preparation for the imaging procedure later that day.
  • Lab tech jots down the amount of activity and time of injection, for use by the imaging operator later.
  • Operator selects worklist entry when Patient arrives at the imaging suite.
  • Operator types in the previously recorded dose information as part of setting up the scan.
  • Some lab systems generate reports in non-standard formats.

Sparse information, transcription errors, and differences in clock times between the lab and imaging systems can all contribute to errors and poor image quality, as well as making it hard to collect/analyze data to improve practice and reduce dose.

Improved:

  • Patient arrives at the nuclear medicine lab.
  • Lab staff injects the patient with a radiopharmaceutical in preparation for the imaging procedure later that day.
  • Lab system stores RRD recording extensive details, including amount of activity, time of injection.
  • Operator selects worklist entry when Patient arrives at the imaging suite.
  • Scanner gets/parses RRD, presents relevant details to the Operator, uses details in image corrections, records details in image headers
  • Dose Reporter collects/analyzes dose metrics to flag outliers, drive performance improvement, etc. and submits standardized data to Dose Registries.

4. Standards and Systems

The same systems that are involved in the REM Profile would also be involved in this new Profile, with the addition of the dose creation/calibration systems in the "Hot Lab" and/or injection systems.

The modalities will be PET and SPECT scanners (including PET/CT, PET/MRI, etc).

The DICOM Standard provides the structured report template to be used for the RRD (Radiopharmaceutical Radiation Dose) dose reports.

5. Technical Approach

Follow the REM architecture with a few modifications described below.

New actors

  • Dose "Creator"?
  • The RRD is ideally created by the dose creation/calibration systems in the nuclear medicine "hot lab", which knows the critical details of the radiopharmaceutical dose that was prepared/administered.
  • Might also consider the injection systems in the nuclear medicine imaging suite.

Existing actors

  • Image Manager
  • Keep doing Store/Query/Retrieve of SR objects, so almost no change
  • Dose Information Reporter, Dose Registry
  • Same jobs as in REM, but when parsing the SR handle the RRD data elements that differ from RDSR.
  • Acquisition Modality
  • Likely becomes a consumer of the dose report instead of the creator. Details about the radioactive material used, it's strength and when it was prepared are used by the modality to correct the images for decay, scatter, etc as well as being copied into the image header.

Existing transactions

Most of the existing REM transactions can be used as is, or with simple variant text added to reference the new payload flavour.

New transactions (standards used)

Might create a new transaction (cloning existing REM transaction) to handle how the PET/SPECT system finds/gets the RRD.

New integration profiles needed

A new Profile is proposed. The main reason for not simply introducing an option in REM, is to give it visibility, and call attention to the difference in architecture/dataflow (TO the modality, not FROM) and domain (NucMed versus X-Ray).

Impact on existing integration profiles

No significant modifications. Might want to mention the new profile in the "Related Profiles" section of REM and mention the payload in transport profiles. Also maybe a mention in Scheduled Workflow that this profile supplements SWF.b for Nucmed systems.


Breakdown of tasks that need to be accomplished

  • Review existing REM transactions for payload dependence.
  • Draft payload extension paragraphs for affected transactions
  • Decide if we want to make anything that's optional in Sup159 be required.
  • Decide on dataflow pattern from hotlab to modality
  • Clone/revise REM Vol. 1 text
  • Draft transaction for scanner to find/retrieve RRD and copy some values into image headers.

6. Support & Resources

The Society of Nuclear Medicine has submitted a letter that this proposal would further the goals of the nuclear medicine community. Interest has also been expressed by individuals at Mallinkrodt/WashU and Memorial Sloan Kettering.

The QIBA (Quantitative Imaging Biomarkers Alliance) PET Cmte is interested in and supportive of this proposal. They feel that the current practice of manual transcription leads to errors in recording the proper activity and time of administration which can compromise image quality and quantitative measurements. They feel this proposal would be an effective step forward.

Numa Inc. is interested in implementing and prototyping the profile.

7. Risks

  • The hotlab systems have not traditionally used DICOM and might resist the regulatory and clinical pressure to facilitate automated standard dose reporting.
  • Although Bayer/Medrad did participate in the meetings developing SUP159
  • It will be important to have domain experts participate
  • Philips, NUMA and Society of Nuclear Medicine representatives have expressed interest in participating

8. Open Issues

  • How should the scanner get the RRD?
  • Dose "Creator" could push directly to scanners
  • Scanner could query/retrieve from Image Manager based on Patient/Accession info from Worklist
  • [Agfa] Would it make sense for the Dose Creator to use STOW-RS to send the RRD to DSS/OF and then the dose information will be available in MWL query?
  • Modality already widely supports MWL. So getting the RRD information from MWL query is a small incremental change
  • Most DSS/OF will likely be interested in the dose information, similar to REM
  • Using RESTful STOW-RS may lower the entry barrier given the hotlab systems traditionally do not use DICOM
  • How should the Dose "Creator" get the patient/procedure context?
  • MWL worklist
  • MPPS?
  • HL7 Order?
  • [Agfa] Need to take into account that the Dose Creator (e.g. hotlab systems) traditionally do not use DICOM. Adding more DICOM requirement (e.g. MWL) may prohibit the adoption.
  • [Agfa] If the RRD is created before the acquisition, how should the Dose Creator manage to use a consistent study instance UID that matches the study that will be eventually acquired?
  • Potentially it will be using the Study Instance UID from the scheduled order message, which the modality should be doing the same
  • But how about the unscheduled case? Or is it relevant for PET / SPECT studies?

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 20%

Candidate Editor:

Jeff Pohlhammer and/or Charles Smith (Co-authors of DICOM Sup159)
Kevin O'Donnell (as IHE Mentor)