Enterprise Scanner Protocol Management - Proposal
1. Proposed Workitem: Enterprise Scanner Protocol Management
- Proposal Editor: Krishna Juluru
- Editor: <Name of candidate Lead Editor for the Profile, if known>
- Domain: Radiology
There is currently no way to manage protocols centrally across devices. This creates inefficiency, inconsistency and chaos in the management of protocols at radiology sites.
DICOM is about to ballot Supplement 121 which defines SOP classes to distribute planned CT protocols and to record performed CT protocols. IHE Radiology has the Assisted Acquisition Protocol Setting Option in Scheduled Workflow, which enables the operator to use procedure codes provided in the modality worklist to select the acquisition protocol.
Defining the basic operations of a Protocol Manager actor and a few transactions between that actor and the Acquisition Modality actor and Image Manager/Archive would enable communication of protocol information and centralized management of protocols across devices.
Several vendors have implemented proprietary protocol management functions. Modality, PACS and EHR vendors would all benefit from having a standardized method for performing this function.
The standards are nearing maturity for implementation and an IHE profile would provide an effective implementation guide that acts as a extension of other widely implemented IHE profiles.
2. The Problem
Although imaging protocols in different scanners may have the same name and are intended to achieve the same diagnostic outcome, the contents of the protocols often differ in details such as:
- procedure step name (series name)
- procedure step sequence
- procedure step parameters
This has consequences in both clinical and research settings. Inconsistent series names can lead to failures of hanging protocols and failures of image processing pipelines in research. Wrong procedure step sequence can lead to scan delays and incorrect timing of post-contrast phases. Variability in scan parameters can lead to difficulties in following lesions over time, and variability in image quantification, not to mention unnecessary radiation.
There is a need to standardize imaging protocols within an institution, and between institutions. Currently, at most institutions, this standardization is performed manually by a lead technologist who visits every scanner and checks the uniformity the protocols.
Value Statement: Manual management of imaging protocols involves a visit to every scanner in an institution and is a time-consuming and error prone process. The problem is exacerbated when scanner software is upgraded and existing protocols are deleted. The institution’s ability to implement desirable changes to protocols is also limited due to this manual process.
A better solution would be a system and process that could manage all scanner protocols within an institution from a central access point. This would enable standardization across scanners, quick updates of protocols, and monitoring of protocols for quality assurance purposes.
In the long run it would be nice to have this capability available for all modalities, but CT would be a good place to start. This alone would address a big problem.
3. Key Use Case
Rather than an ad hoc manual process that involves physically visiting each device in an institution or group of institutions and on each device reviewing dozens or hundreds of protocols, using tools and doing much of this remotely would have a tremendous benefit. The following use case is an example. The tech cmte is expected to explore variants.
- Lead tech or radiologist visits a protocol management workstation
- The workstation pulls the full set of protocols from all the scanners in the institution or group of institutions
- Features on the workstation let the tech
- organize the protocols by device model, clinical purpose, patient type, etc.
- see what protocols have been added or changed recently or since the last review
- compare parameter values across selected protocols, e.g. to find undesired differences, or confirm necessary differences are in place
- The workstation allows the tech to push the appropriate protocol sets out to specific devices or groups of devices
- The tech might be allowed to make certain simple edits to protocols
- E.g. when a "correct" version of the protocol is not available on another scanner to be simply copied.
- Edits might include aligning names or descriptions, or setting dose notification popup thresholds for a group of protocols.
- Some edits will require the user interface and business logic of the scanner itself to perform correctly.
- The workstation may help the tech generate and print a list of such changes to visit the appropriate device then use the workstation to replicate the changes on additional scanners of the same model if needed.
4. Standards and Systems
- Protocol Management System
- Radiology Information Systems
- Dose Management Systems
- DICOM Sup121 - CT Protocol Storage
- NEMA XR-29 (Smart Dose), XR-25 (Dose Check)
5. Technical Approach
This would be a new profile with potentially 6 new transactions.
Figure 1. ESPM Transaction Diagram
It would interact well with some of the dose management features of MITA XR-29.
In terms of phases, it would need to limit to CT Protocols initially since that's the only one DICOM has standardized so far. (DICOM felt that CT protocols was a good choice to trial this technology and if it worked out well, expand to other modalities). There is work starting in DICOM for Angiography protocols. This profile would have to follow that path too.
- Acquisition Modality
- Image Manager
- DSS/Order Filler
- Protocol Manager
- Protocol Creator
- Protocol Repository
- Reuse Storage Commitment as is?
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.>
- New DICOM Query Transaction (Query protocols by RIS or Modality)
- New DICOM object transfer transaction (push or pull TBA)
Impact on existing integration profiles
Assisted Protocol Setting Option in Scheduled Workflow could link to the stored protocols. Not clear that there would be a direct impact on the SWF.b profile option.
New integration profiles needed
Enterprise Scanner Protocol Management would be a new integration profile. No other new profiles are required.
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.>
Prior to the face-to-face meeting in Dec,
- Draft volume 1 & 2 to include:
- Use cases
- Swim lane Diagram
- Transaction Diagram (protocol movement transaction)
Resolve open issues prior to the face-to-face:
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.>
It would be good for IHE to get involved to promote a cross-vendor, standards-based solution. Currently some vendors provide proprietary solutions that only work for one vendors scanners (and sometimes not for all models). Many sites have scanners from more than one vendor.
- Depends on Sup121 going to Final Text (which will require that it goes to letter ballot at the Sept WG6 meeting and passes ballot so it can be Final Texted at the Nov or Jan WG6 meetings)
- Depends on vendors migrating to an open standard from their current proprietary formats
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.>
- Will protocol creators will be required to push to the Manager (in response to a trigger?) or will the manager optionally be able to query retrieve?
- What UI capabilities, if any, will be required (comparison screens, etc.) Note that this should be out-of-scope
- What features will be mandated on the Modality, if any other than supporting the transactions (overwrite/delete local protocols, etc.)
- What will be required from the DICOM Supplement.
- Is the transactions REST (DICOMWeb/FHIR) or DIMSE?
- Will the modalities be able to Query for protocols or will it be a push?
- [Balaji Raman-GECT] Protocol Manager could itself be the creator. Does Protocol Manager need a transaction for submit to the Protocol Repository?
- [Balaji Raman-GECT] Protocol Manager should also query modality and retrieve protocols. The use case for this scenario is as follows: if there are new protocols created from already pushed protocols, we would like to know who modified it and check what parameters got changed.
- [Balaji Raman-GECT] This profile needs to differentiate between modality Defined Protocol and modality Performed Protocols in terms of transaction. We might need to store in PACS the performed protocols. So we might need to add another actor and transaction for it.
- [Balaji Raman-GECT] The modality should retain locally both defined and performed protocol on the modality itself. Do we need to capture that here?
- [Chris Lindop-GEMRI] Version control should be a profile requirement.
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
- Chris Lindop