Mammography Acquisition Workflow Informative Text Development- Work Page

From IHE Wiki
Jump to navigation Jump to search


  • Carolyn Reynolds (Lead)
  • Paul Morgan
  • John Paganini
  • Ron Hitzelberger


Mammography Acquisition Workflow is about handling scheduled and unscheduled image acquisition in Mammography. Acquired images serve as input to potentially any other subsequent event such as post-processing/ CAD, interpretation/ reporting, and billing. Optimal integration of acquisition steps into the overall workflow is critical.

After initial image acquisition re-takes, additional views or CAD results may be appended to the imaging study subsequently. Studies are not complete until the Radiologist is satisfied.

There are common practices in digital mammography which can have a wide variety of workflow results. Despite technical means defined in the Scheduled Workflow and Mammography Image Profiles, variances in the way users and systems behave can lead to department inefficiencies, ambiguous data, special cases for automated billing, and less than optimal acquisition and reading environments.

Because additional views are common in mammography, there is no easy, practical mechanism within mammography to declare a scheduled procedure complete. Performed Procedure Steps can continually be added to a study. MPPS complete messages and PACS distribution mechanisms can inhibit access to images, CAD result reports, and study annotations. Inconsistent study statuses and study structures have also been an issue with many PACS.

Different implementations of workflow functions and semantics can be reduced by guiding or defining which data and semantics is exchanged and used by interacting systems. IHE can facilitate the exchange of information required for efficient workflow especially for solving the problem of additional views.

One approach might be to define how to apply more generalized Scheduled Workflow use cases (e.g. Append Case) to mammography practices. IHE may re-use existing IHE work, add IHE specification based on existing standards, or identify gaps in standardization that could be handed off to the appropriate resources (i.e. DICOM committees).

Use Cases

Use Case 1

A patient comes in for a screening mammogram which is converted to a diagnostic exam upon the technologist discovering a lump. The technologist adds an extra view, but no exam type, so the hanging protocol at the workstation is unacceptable. For example, a screening mammogram typically has 4 standard views. The hanging protocol for a screening mammogram very possibly is triggered by the exam type at the diagnostic workstation. If another view is added by the technologist and the exam type is not altered, either the physician may not see that extra view in the hanging protocol or the additional view may disrupt the normal hanging steps and force the user to drag and drop images.

  • Additional views may effectively change the type of the exam (i.e. screening to diagnostic, or uni-lateral to bi-lateral). The resulting final exam type is not evident to systems and users.

Use Case 2

A radiologist views a screening exam and finds an abnormality. The radiologist requests additional images to better demonstrate the abnormality. Should the technologist add the views to the existing order? Does it depend upon whether or not the patient is still available for imaging that day? How should the exam type (and billing) change from screening to diagnostic if this is necessary?

  • Using another study or accession number to add the views leads to archiving, billing, and display presentation problems. The additional views may not hang simultaneously with the original study, or the extra views may make the study that happened just a few minutes prior the “old” study.

Use Case 3

A patient comes in for a follow-up exam on one breast. Since she is close to her yearly exam date, the radiologist calls for imaging of the other breast too, while the patient is waiting. The original room is unavailable, so another machine is used. The technologist generates a new study and accession number. The right and left breasts do not hang together at the diagnostic workstation. The following year, the prior images are hung as two prior studies, not as one complete comparison study.

  • Additional views can later be mistaken for complete prior exams.

Use Case 4

The technologist labels a view incorrectly and doesn’t realize it until after the case is completed and sent to PACS. The view information is corrected at the acquisition modality and resent. The images do not hang properly on the workstations and multiple copies of the same image exist, one of which is labeled incorrectly.

  • Additional views may be data corrections or retakes on previously acquired views. Image Managers and Workstations do not have a mechanism to understand and properly treat images produced as a result of such conditions.
  • Additional views may generate additional CAD result reports. This creates confusion as to which objects should be considered for case level processing and which CAD reports should be considered when reading.
  • Some CAD outputs consider only the most recent of the four standard views sent and so, for example, if a Right MLO view is done twice and the second one turns out worse than the first, the CAD may only be applied to the inferior image. If the hanging protocol prescribes that the first image for any one view be hung in the viewport, the CAD is not readily visible to the radiologist who then has to figure out where the CAD is.

Use Case 5

It is typical for a mammography site to have an acquisition modality, diagnostic display station, and a PACS system from different vendors. The modality is expected to store images to multiple destinations (display station, CAD server, and archive). The CAD server also requires multiple destinations (display station and archive). The diagnostic display station must query for then retrieve relevant prior studies. Multiple destination workflow causes excess network traffic and creates multiple instances of images, objects, markups and status.

Standards & Systems

Existing standards and mechanisms to consider include:

  • DICOM storage, storage commit, MPPS, and modality worklist.
  • Existing IHE profiles such as Scheduled Workflow. Existing IHE actors, such as DSS/OF, MOD, IM, EC, ID. Existing transactions are further referenced in technical approach.

Existing systems that could be involved in the problem/solution include: FFDM modalities, Mammography CAD servers, Diagnostic and Technologists’ workstations, PACS, and RIS.

Technical Approach

The committee will first try to apply the existing Scheduled Workflow Profile transactions and actors to mammography and then address any gaps and user requirements not met by this profile. The committee will seek to stay aligned with any applicable developments associated with Scheduled Workflow 2.0 activity. However, because mammography is a screening modality and a highly regulated field, the committee believes that some of its unique challenges and most urgent issues would not be completely addressed by SWF 1.0/2.0. We would expect that SWF 2.0 alone would seek to resolve common issues among radiology practices, not those unique to mammography.

Below are some possible ideas that could be used to address some of the problems. Before proceeding right to the solution space, the committee will need to hold a [limited] session to make sure that common operational practices related to this profile are considered. Although not every special case circumstance may have a solution, it is believed better to address the most common problems than wait for the all encompassing perfect solution. Better ideas may be available, but these are provided to demonstrate profile feasibility.

Normal Screening Use Case (scheduled case w/o pre-fetching priors)

1. The ADT, OP, and DSS/OF, actors work as detailed in SWF to register the patient and then schedule and fill the screening order.

2. The full field digital mammography modality (FFDM MOD actor) queries the DSS/OF for the modality worklist (RAD-5)

3. When the technologist begins the exam, the modality sends a Modality Performed Procedure Step message (RAD-6) to those systems desiring such information. It is believed that PACS, RIS, and CAD may all desire MPPS data for different reasons. To date, it has not been viable to rely upon the presence of a PPS Manager to distribute MPPS messages among these multiple systems. Where a PPS manager exists, having the modality send once to the PPS manager is preferred, but the non-existence of an enterprise wide PPS manager should not limit the other systems from having access to this needed information.

4. The technologist begins acquiring the typical 4 view images for the exam. Images may be sent to destinations (RAD-8) as they are captured and accepted (one DICOM association per image), or images may be held and sent at once at the end of the exam (one association per exam). There are benefits to both methods, and destinations should be compatible with either method, giving users the choice of which method benefits them best.

5. “For processing” images are sent from the modality to CAD (RAD-8).

6. “For presentation” images are sent to the Image Manager from the modality (RAD-8) and “for processing” images can be sent per the user’s choice.

7. Store Commitment (RAD-10) message(s) are sent to the Image Manager from the modality

8. A preferred next step would be for the Image Manager to forward the image on to the Image Display actor (RAD-8) along with any relevant priors that have not already been pre-fetched already to the Image Display. The committee would not seek to define the application that would do this, but would recommend guidance from our user community on what to consider when identifying relevant priors and intelligent routing to an image display(s). Since this is a preferred and not required operation, defining an actor/transaction pair as an option would be an effective way for the committee to communicate to the user community a preferred, but not required method of data transfer and distribution.

9. In the absence of the option described in the previous step, the modality will need to be required to distribute images to not only CAD systems and an Image Manager, but would also be required to send images directly to the Image Display. This would require support of RAD-8 by the Image Display actor which is not currently part of SWF. (Note: diagnosis of mammography images from remote locations is a forceful market demand gaining momentum, even when PACS are not shared among facilities. The committee should consider how the Image Manager actors and Image Display actor relationships play not only within one facility, but among facilities that may or may not have integrated PACS).

10. The technologist would complete the procedure, thus sending an MPPS complete message (RAD-7) to the systems requiring such information. Comments similar to those in Step 3 apply here.

11. Although potentially outside the scope of this profile, the CAD system would process the screening exams and send a mammo CAD SR report to the Image Display (RAD-43). The CAD should also have the ability to optionally send the report to the Image Manager and perform a Storage Commitment (RAD-10) for those users wishing to archive CAD reports. For those archiving reports, the same comments from Step 8 apply to relaying prior CAD results to Image Display(s).

Follow-up images:

To address the problems that additional images cause systems, the follow approach could be considered:

1. The data flow for the initial images will be assumed to be the same as described for the standard screening exam. Previously acquired images would belong to a completed performed procedure step.

2. The addition of follow-up views would follow the data structure similar to the Append Use Case in scheduled workflow. Several scenarios could play out:

  • Upon confirming the need for additional views, the technologist returns to the equipment where the original views were captured and are still available on the system. The technologist appends a modality performed procedure step to the original study.
  • Instead of returning to the original system to take the extra shots, the technologist uses the only room open that has a modality of a different manufacturer. The technologist is able to still see the worklist item for the order, selects the worklist item, and prepares the additional views.
  • The technologist uses a system to take the additional views (original or different room). The original study is not available and the worklist item is not longer available [because the worklist SCP does not follow the OF requirements for this profile). The technologist is able to retrieve the original image information from the Image Manager from which then the system is able to append a modality performed procedure step.

3. In all the scenarios above, the modality will create a new procedure step and send out appropriate MPPS messages (RAD-6 and RAD-7). Per the Append Use Case data structure, the added images will contain the same study UID and accession number as the original images.

4. The images will be sent to the Image Manager and Image Display in ways similar to the standard screening use case.

5. The images could be sent to CAD in one of at least 3 approaches:

  • The modality could simply send all the images that it has for a specific study and all images from that study would then be processed as a case. Note: this would be true whether or not the original images were taken on the equipment that acquired the additional views.
  • The technologist could be given the ability to select among all available images (original set and additional views) and send just the selected images to CAD to be processed as a case.
  • The CAD could be required to either 1) retain images in cache for a configurable period of time or add all images of the same study UID to the case for processing, or 2) the CAD could be required to query the Image Manager and retrieve all case level images before processing the additional images with the case. Note: the first behavior is present in virtually all installed CAD systems, today.

Optimally, the committee could search for a DICOM mechanism that allows the technologist to communicate [from the modality] to the CAD system, which images from a reference study should be considered for CAD case processing.

6. The Image Manager and Image Display will be required to have behaviors consistent with this use case. For example, some PACS will complete a study upon receipt of a completed procedure step. The exam must not be completed at the study level since it is only a sub-study component that is completed. Image Displays will need to be able to help the radiologist not miss when views have been added to a study if the study is being viewed or has been marked viewed or read. The Image Display will also be required to display enough header information in from the CAD results to help the radiologist understand which report is most appropriate to use. The committee will not seek to define application requirements, but will aim to help vendors avoid behaviors that break mammography workflow and encourage behaviors that reduce ambiguity and increase efficiency and contribute to patient care.

Data Distribution and Access, including addressing prior exams:

As stated above, IHE scheduled workflow provides a great basis for mammography workflow, and perhaps SWF 2.0 will provide the missing links necessary for efficiency. A gap analysis between SWF 1.0/2.0, current practice, and user requirements will reveal what, if any, work the committee will want to address. Specifically, the committee will focus on how the necessary DICOM objects are delivered to the point of diagnosis. The committee will be careful not to get into the reading workflow space that is being addressed by another committee. It is anticipated that a white paper describing how to deploy SWF within mammography could be one possible outcome of this effort. If deploying SWF within mammography presents too large a gap to resolve users' issues, then it is anticipated that slight modifications to existing IHE transactions would be all that is necessary. It could be possible that reassignment of IHE transactions to different actors would provide the necessary efficiency for mammography.

To give the planning committee more detail before the actual gap analysis, below is an example outcome. Some of these ideas have already been mentioned in steps 8 & 9 of the normal screening case:

1. The Q/R transaction for Image Displays (RAD-14 and RAD-16) is deemed too inefficient for the large data sets of MG images, and is recognized as a non-practical way to handle accessing current and prior exams. Comparison of prior exams is required, not just a “nice to have” practice in mammography.

2. Pushing exams to the point of diagnosis is preferred. Note: image distribution may create burdens on some networks, but just as PACS has addressed distribution challenges between archives and workstations, Image Display systems should be afforded the ability to rise to solve these challenges within their system.

3. For current exams, either the MOD or the IM could be required to push the images to the Image Display Actor, and the Image Display actor would be required to support RAD-8. Note: there is plenty of experience among the committee using multiple methods, both within local and remote reading environments which must be considered when addressing distribution and access of data.

4. For prior exams, perhaps an actor performing a prefetching service could be offered as a solution. The actor would be required:

  • to receive order information (RAD-2, RAD-3?)
  • to query the IM for prior exams for the patient (RAD-14)
  • to have a method of identifying relevant prior exams (left to vendor to determine the method, allowing for the market requirements & demand to drive this feature, but the committee could provide some general guidelines)
  • to have a method of understanding the reading destination(s) for the scheduled exam (again, left to vendors to define with committee guidance)
  • to issue a DICOM C-MOVE to the Image Manager that sends the prior exams to the desired Image Display(s).

Exams that change procedure types and studies made up of more than one procedure type.

There are at least several common clinical situations that can be classified as “changing procedure types”. The committee would first seek to identify these common situations. It is anticipated that applying common coding rules for anticipated outcome use cases would help guide system designers to avoid today’s pitfalls and user inconveniences. Note: Although there is a mechanism within IHE SWF to perform a different procedure than that which is ordered, it is not until the after initial exam is begun (or even completed) that the need for changing the procedure type is identified.

For example, a screening exam may become a diagnostic exam based upon the patient’s mentioning a palpable lump or the technologist noticing a suspicious area on the screening images. Depending upon where in the process the exam is, and how coding and billing should be handled, one of the following methods could be used:

1. If no images are acquired, the Performed Procedure Protocol Code sequence could be coded as a diagnostic exam, even though the Requested and Scheduled Procedure Step sequences are coded for a screening exam.

2. If the screening images are first acquired and coded as a screening exam (under the Performed Procedure Protocol Code), the first procedure step could be discontinued with a newly defined reason code that clearly expresses why the change, so that downstream systems can act accordingly. The captured images could be assigned new instance UID’s (with reference to the first) and the new DICOM headers would reference a diagnostic Performed Procedure Protocol Code sequence.

3. If the screening portion of the exam has been completed as a procedure step and additional views are appended to the study, the additional views can be coded with a Performed Procedure Protocol Code as “diagnostic.” The committee will look into whether the Performed Procedure Step Relationship Module could be used to express the relationship between the images captured under a screening code and those added under a diagnostic code.

In all cases the committee would provide guidance on how each case should (or should not) be treated by CAD, Image Managers, and Displays in as much it is appropriate for IHE to do so. The way in which Image Displays treat hanging protocols for additional images that are diagnostic in nature is an example of the type of topics the committee will consider.

Another example of a changing protocol types for an exam is when a unilateral exam (one breast) changes to a bilateral exam (both breasts) if a woman is being imaged as a follow-up and happens to be due for her annual exam. For this example, and all others that the user community identifies, the following approach will be taken:

1. Specify the use case in detail.

2. Validate the universality of the use case among the user community, making sure fixing workflow for one user doesn’t cause new issues for other users with different environments.

3. Comprehend the nature of the issues and problems experienced with today’s industry practices.

4. Determine if standardizing coding, data organization, transactions, and actor behavior [all within DICOM and IHE transactions] can reduce or even eliminate the issues. Note: any behavior requirements would be of a nature similar to what was required for the IHE Mammography Image Profile. The committee is sensitive to not specifying how systems should work, but may seek for actors to meet universal user requirements, with the vendors being free to define the implementation by which the requirement is met.

Existing actors

  • Department System Scheduler/Order Filler
  • Acquisition Modality
  • Image Manager
  • Evidence Creator (CAD)
  • Image Manager
  • Modality Performed Procedure Step Manager
  • Image Display

Impact on existing integration profiles

  • Possible expansion of requirements within data objects (i.e. Digital Mammography Image objects and Mammo CAD SR objects) for certain transactions. Note: the expansion of requirements would only apply to this profile, not existing profiles.
  • Possible expansion of requirements on Image Display within the existing Mammo Image Profile if resulting changes are not enough to justify a new profile.

Breakdown of tasks that need to be accomplished

The original profile proposal, “Mammography Acquisition and CAD Workflow” has been separated into two different IHE proposals, although there are several overlapping concerns.

The following options and issues need to be clarified and resolved, including boundaries/ interfaces to a potential CAD profile:

  • What mechanisms solve which part of the problem:
    • Dataflow: reliably get images to a CAD box, workstation, PACS, etc. This includes clarifying the data lifecycle, e.g. retaining acquired images (or relevant data) on the modality so that in the append case, this previous Study and Procedure information can be re-used. Where to send which data to (PACS as single data sink or additional push to few known systems performing single next steps, e.g. CAD)?
    • Workflow: tell another system to do something, including references to input data. Which systems query for worklists (CAD worklist)? What scheduled steps are needed (e.g. schedule potential re-takes/ additional views, or CAD)? Which systems send and receive work status (MPPS to CAD and PACS)?
    • Internal logic of querying/ sending and receiving actors in order to determine when all images are available. For instance, compare MPPS references to available images, or query/ send image availability status.
  • It does not seem realistic to assume that IHE Technical Specifications can solve all variability in the field. Thus, users and vendors need to know how local practices and habits impact system use and departmental efficiency.
  • In acquisition and subsequent steps - how to access the images:
    • Pull: query/ retrieve, e.g. by CAD. This implies that PACS is required to retrieve images that match the query, irrespective of "Study complete" internal logic.
    • Push: store to one/ more receivers. This implies that the modality has internal logic to know when to send images or appended images, e.g. by using a waiting queue, by providing an interactive function for a user to manually send images.
  • For Workflow: prefer re-use and established things.
    • SWF
      • normal case - for scheduled acquisitions without re-takes or additional views
      • unscheduled case - is it relevant in Mammography at all?
      • append case - for re-takes or additional views (unscheduled or scheduled cases)
      • group case - is it relevant in Mammography at all?
      • Are Mammo-specific codes for procedures/ steps needed?
    • There are no other relevant IHE workflow profiles to be reused for acquisition workflow (PWF, RWF do other things).
    • If Modality Worklist and SWF do not solve the Mammo acquisition problems, is it worth while looking for less-established mechanisms? E.g. opportunities and risks of using UPS (still not finalized); dataflow (push images and MPPS to CAD).
  • Study complete - define the concept, i.e. relation of MPPS and "all images available". Only a human user can finally reliably state that a study is complete. If additional views are taken at a 2nd, different modality, does IHE need to cover this case (is it 80% routine?)? If a CAD system receives an MPPS from one modality, how sure can it be that there won't follow another MPSP from a 2nd modality notifying the CAD box of additional images/ views?
  • Exam type - clarify what this means exactly (screening <--> diagnostic). What are implications and required behavior?

Current Practices

Current Technical Coding Practices

  • Siemens Summary of coding from images
  • Hologics retrieved data from 20 customers to review the use of the procedure description/codes. 4 Customers used codes, but the codes themselves vary widely.

Clinical Coding Practices

  • CPT codes are not sufficient for automating Ordering in all cases. (Note: CPT Codes only cover the US (see open issues))
    • CPT codes are sufficient in the case of Screening.
    • CPT codes may be sufficient in the case of low level Diagnostic Imaging.
    • CPT codes are NOT suffient in the case of more advanced Diagnostic Imaging where the Radiologist must first review the case before determining the Procedure (similar to Cardiology and other Diagnostic Imaging).
  • Order Entry needs to occur not only on HIS/RIS systems, but also on EMR Systems. Orderables in both cases need to be queried.
  • Scheduling Process is used to refine the Order (Many facilities have script which is used by the Scheduler).

Support & Resources

  • The Mammography Committee membership includes:
    • practicing radiologists from the US and Europe with broader affiliations and connections throughout the world
    • active vendor participants who represent a majority of the systems used in digital mammography practices, today
    • participants who are also are members in DICOM working groups 6, 15, and 11.

The editors of this proposal have shared a draft of this proposal with the DICOM Working Group 15 members (Breast Imaging) and have considered and incorporated WG15's comments and feedback within this proposal.


- We may discover that there is not an existing DICOM service/field/tag or IHE transaction for the critical trigger needed to implement this profile.

- There may not be agreement that these Use Cases are in fact are universally applicable (i.e. applicable to most other countries).

- IHE committee may not agree on overall implementation strategy.

- There is a possibility that SWF2.0 may obsolote this profile. The development of the Mammo Acquisition Profile should be coordinated with SWF2.0 to mitigate the risk of obsolescence.

Note: These items are planned to be addressed in the face-to-face meeting.

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

  • Need for DICOM transaction for "Exam Complete".
  • Value of doing Mammography Acquisition Workflow based on current SWF TF v8.0 is questioned if SWF II is going to come out in the next couple of years.
  • There are known gaps in the SWF relative to the needs of Mammography Acquisition Workflow. How should the gaps be discussed in an informative appendix.
  • CP codes only cover the US. IHE may need to define different code sets to Internationationalize the coding. SNOMED is not sufficient as its distribution is limited.
    • Laterality is critical within coding. Would this be something that Users can be trained on and expected to enter, or does it need to be completed at the Modality level in some cases?

Planning Cmte Recommendation

Create informative text explaining how the current SWF/PIRM ammography Acquisition Workflow should be implemented based upon the TF v8.0 implementation. This alternative has been presented as a result of the SWF II discussion which occurred after the initial Mammography Acquisition Workflow Profile discussion. It is the preference of the Mammo Committee not to develop a full Mammography Acquisition Workflow profile independent of the SWF II development. It is assumed that the SWF II development would take into account the Mammography Acquisition Workflow needs. However, in the interim it is felt that some sort of informative text must be developed to help Users with the implementation of SWF for system with Mammography. This text would be informative in nature and would be included either as an Appendix in the TF or as a User's Handbook. NOTE: This Informative text could be based upon the NM Appendix which also discussed NM Acquisition Workflow.

Technical Committee discussed providing some informative text to aid PACS vendors in the implementation of SWF for Mammography based upon current functionality. PACS vendors are becoming exceedlingly interested in the implementation of Mammography based upon current implementation architectures.

Responses to Issues:

See italics in Risk and Open Issue sections