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

From IHE Wiki
Jump to navigation Jump to search
Line 6: Line 6:
 
* Proposal Editor: Jeff Pohlhammer
 
* Proposal Editor: Jeff Pohlhammer
 
* Editor: Jeff Pohlhammer or Charles Smith (Co-authors of DICOM Sup159)  
 
* Editor: Jeff Pohlhammer or Charles Smith (Co-authors of DICOM Sup159)  
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
 
* Domain: Radiology
 
* Domain: Radiology
 
[[Category:RAD]]
 
[[Category:RAD]]
 +
 +
===Summary===
 +
''<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">''
 +
 +
''<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">''
 +
 +
''<Summarize in a few lines how the problem could be solved.  E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">''
 +
 +
''<Summarize in a line or two market interest & available resources.  E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking.  Individuals from SFR are willing to participate in Profile development.">''
 +
 +
''<Summarize in a line or two why IHE would be a good venue to solve the problem.  E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
  
  
Line 48: Line 57:
 
:* New Template - http://medical.nema.org/medical/dicom/2014a/output/chtml/part16/sect_RadiopharmaceuticaRadiationDoseSRIODTemplates.html#sect_TID_10021
 
:* New Template - http://medical.nema.org/medical/dicom/2014a/output/chtml/part16/sect_RadiopharmaceuticaRadiationDoseSRIODTemplates.html#sect_TID_10021
  
==5. Discussion==
+
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.
  
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.
+
 
 +
==5. Technical Approach==
 +
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''
 +
 
 +
''<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
 +
 
 +
''<If a phased approach would make sense indicate some logical phases.  This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
  
 
The proposal introduces a new Profile. 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 (NM versus X-Ray).
 
The proposal introduces a new Profile. 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 (NM versus X-Ray).
Line 57: Line 72:
  
 
The Profile can also address the special case of a nuclear procedure that includes administration of dose to the patient, but does not include an imaging procedure.
 
The Profile can also address the special case of a nuclear procedure that includes administration of dose to the patient, but does not include an imaging procedure.
 +
 +
===Existing actors===
 +
''<Indicate what existing actors could be used or might be affected by the profile.>''
 +
 +
===New actors===
 +
''<List possible new actors>''
 +
 +
===Existing transactions===
 +
''<Indicate how existing transactions might be used or might need to be extended.>''
 +
 +
===New transactions (standards used)===
 +
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
 +
 +
===Impact on existing integration profiles===
 +
''<Indicate how existing profiles might need to be modified.>''
 +
 +
===New integration profiles needed===
 +
''<Indicate what new profile(s) might need to be created.>''
 +
 +
===Breakdown of tasks that need to be accomplished===
 +
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
 +
 +
==6. Support & Resources==
 +
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 +
 +
''<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>''
 +
 +
==7. Risks==
 +
''<List technical or political risks that will need to be considered to successfully field the profile.>''
 +
 +
==8. Open Issues==
 +
''<Point out any key issues or design problems.  This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>''
 +
 +
==9. Tech Cmte Evaluation==
 +
 +
''<The technical committee will use this area to record details of the effort estimation, etc.>''
 +
 +
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 +
:* 35% for ...
 +
 +
Responses to Issues:
 +
:''See italics in Risk and Open Issue sections''
 +
 +
Candidate Editor:
 +
: TBA

Revision as of 20:22, 8 September 2014


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

<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">


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. The DICOM Standard now includes a Structured Report object (Sup159) suitable for reporting radiopharmaceutical dose, but guidance is needed on how to make use of these report objects in the clinical setting.

Second, the administration of radiopharmaceuticals for nuclear medicine procedures generally occurs prior to imaging procedures, and is not done at the imaging system. But the NM and PET Image IODs require entry of information such as the pharmaceutical and isotope in use, and the amount of activity administered, and the time of administration. This often means that operators are manually transferring information from a lab system to the imaging system, leading to errors in recording the proper activity and time of administration. Such errors can lead to compromises in image quality and errors in quantitative measurements for things like SUV.

Value Statement

Adoption of a Profile to address reporting and management of radiopharmaceutical dose will satisfy 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 large 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 Profile will also specify the actors that will create the association dose reports (the lab and dose creation/administration systems) and that the imaging systems will consume these reports to obtain dose information automatically. This will eliminate the errors associated with manual transfer of such information, reducing the number of repeated scans due to bad image quality and incorrect SUV measurements.

3. Key Use Case

  • A patient enters the nuclear medicine lab and is injected with a radiopharmaceutical in preparation for a nuclear medicine imaging procedure that is to be performed later that day.
  • The lab technician jots down the amount of activity and time of injection, for use by the imaging technician later.
  • When the patient arrives at the NM department later for their imaging procedure, the operator types in the previously recorded dose information as part of setting up the scan.
    • Transcription errors, and differences in clock times between the lab and imaging systems can all contribute to errors at this point.

The hospital would like to create and track dose reports for these procedures. They already do so for their CT systems, but there is no agreement on a workflow to accomplish the same automation of reporting for the radiopharmaceutical dose information. Some of their lab systems may be able to generate reports, but the format is not standardized. Likewise, the nuclear medicine imaging systems in the hospital may not be able to consume these reports, and some of these imaging systems may generate their own reports as a surrogate for the lab systems – again in a variety of formats.


4. Standards and Systems

The same systems that are involved in the REM Profile would also be involved in this new Profile, with a couple of additions/exceptions.

  • The nuclear medicine modality becomes a consumer of the Dose Report, instead of the creator of the report, and would employ query and retrieve transactions to locate dose reports and match them up with imaging procedures to be performed (these procedures could be Scheduled Procedures defined in Modality Worklist, or unscheduled procedures).
  • The dose creation/calibration systems in the nuclear medicine lab, and/or injection systems in the nuclear medicine imaging suite, would be new, and would become evidence creators for the dose reports.

The Transactions will either be existing transactions or simple variants of existing transactions.

The DICOM Standard provides the definition of the structured report template to be used for the dose reports.

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.


5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

The proposal introduces a new Profile. 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 (NM versus X-Ray).

The Profile adopts a single standard format for the reports (DICOM RDSR) and specifies the information flow from dose creator, to dose repository, with the modality retrieving reports as needed to populate information needed when creating the NM and PET image IODs and for starting an imaging procedure.

The Profile can also address the special case of a nuclear procedure that includes administration of dose to the patient, but does not include an imaging procedure.

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

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

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA