Enterprise Scanner Protocol Management - Proposal

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Workitem: Enterprise Scanner Protocol Management

  • Proposal Editor: Krishna Juluru
  • Editor: Chris Lindop
  • Domain: Radiology

Summary

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.

Protocol Review

  • 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

Systems

  • Modalities
  • Protocol Management System
  • Radiology Information Systems
  • Dose Management Systems
  • PACS

Standards

  • 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 7 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.

Existing actors

  • Acquisition Modality
  • Image Manager
  • DSS/Order Filler

New actors

  • Protocol Manager
  • Protocol Creator
  • Protocol Repository


Existing transactions

  • 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.

7. Risks

  • Depends on Sup121 going to Final Text
  • Current Status: missed letter ballot at the Sept WG6 meeting by a few hours. Will go to letter ballot after the Nov 8-12 WG6 meeting and Final Text at the Jan 18-22 WG6 meeting.
  • Seems like the timeline still align with the public comment publication schedule. Is the supplement in decent shape that it is expected to be final text as planned?
  • Depends on vendors migrating to an open standard from their current proprietary formats
  • Is there a candidate profile editor?

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 modalities push to the Manager (in response to a trigger?) or will the manager query retrieve?
  • *[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.
  • 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.
  • Are the transactions REST (DICOMWeb/FHIR) or DIMSE or both? Note that in order to support the change management aspect, RESTful services may be better equiped than the legacy DIMSE protocol.
  • Will the modalities have protocols pushed back from the manager or will they query/retrieve protocols from a repository?
  • Can the Protocol Manager create new protocols and if so where would those be stored?
  • DICOM Sup121 presumed that it would be difficult for various vendor modalities to externalize the logic for composing new protocols (e.g. interactions between related parameters).
  • A product could choose to implement one or more Acquisition Modality actors that are really console SW without a gantry and group them with a Protocol Manager actor.
  • How should Defined Protocols and Performed Protocols be handled differently? Do they need different transactions? Different actors?
  • How should version control of protocols be handled?
  • DICOM does not allow such instances to be modified. New instances must be created.
  • Attributes exist to point to "prior" instances from new instances. Profiling of certain Label/Name attributes might be helpful.
  • [Siemens] DICOM WGs 2 and 28 are looking into taking this approach to angiography as well. The supplement should be general enough to deal with additional protocol SOP classes. Also a use case in order to monitor protocol changes for legal reasons should be listed.
  • [Agfa] Is there any modification / enhancement anticipated to the Assisted Acquisition Protocol Setting Option to facilitate better integration with this 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%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Chris Lindop
Retrieved from "http://wiki.ihe.net/index.php?title=Enterprise_Scanner_Protocol_Management_-_Proposal&oldid=89316"