Mammography Acquisition Workflow - Detailed Proposal

1. Proposed Profile: Mammography Acquisition Workflow

• Proposal Editor: John Paganini/Ron Hitzelberger
• Profile Editor:
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. Summary

This Profile is intended to address the unique needs of the digital mammography acquisition workflow. “Mammography Acquisition Workflow” is not limited to the acquisition of digital mammography images but must be visualized as a part of a continuum that considers the entire chain of events in the mammography workflow. Ordering, post-processing, archiving, display, reporting, and billing are all dependent upon the acquisition component for optimal integration and workflow.

Digital mammography acquisition workflow is unlike that of most other modalities in that current studies have no boundries. Studies remain open and may be appended with additional images or CAD objects. They are not complete until the radiologist is satisfied.

There are common practices in digital mammography which can have a wide variety of workflow results. Even when deploying 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. Misuse of MPPS complete messages and PACS distribution mechanisms can inhibit access to images, CAD result reports, and study annotations. Inferred, incorrect study statuses and improperly organized study objects have also been at issue with many PACS.

Manufacturers benefit by addressing workflow issues but since there are no rules to guide them, proprietary implementations result. The IHE process of providing a common standards-based framework would help facilitate the exchange of information required for efficient workflow.

3. Use Cases

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.

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

2. A radiologist views a screening exam and toggles on CAD which indicates findings. 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.

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.

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

5. A PACS will not distribute images until a study is complete. A technologist wants the radiologist to view the images before completing the exam. The radiologist can not access the images from the local workstation.

• Some workstation behaviors are incompatible with the needs of mammography, such as not allowing the addition of images to studies that are open or have already been viewed.

6. CAD objects and markups are persistant. Many sites want to have them available until after the study is completed then they no longer wish to keep or store them.

• ACR does not require that mammography facilities archive CAD objects and image markups (overlays or Presentation States). • PACS vendor assumes responsibility. • Deletion is possible based on SOP Class but maybe there is a better way to deal with this situation.

7. Study objects (images, CAD SR, digitized films) for the same patient can arrive at a PACS from multiple stations, creating a ‘mixed’ station name.

• Mixed station names complicate the ability to address the individual needs of stations, i.e. body part mapping, specialty mapping, compression and archiving, etc

8. Not all mammography modalities create markers that are ‘burnt’ into the image data per the ACR QC Manual. It states that the view and laterality should be placed on the image near the axilla.

• Radiologists are used to the ‘look’ of conventional markers and dislike the variability that exists. They prefer that this information is not hidden amongst other demographic information.

9. Workstations often include a means to indicate to a radilogist that there are additional views during dictation.

• A standardized means of indicating wheteher images, objects, and presentation states have been viewed would be useful to radiologists one they begin dictation.

4. Standards & Systems

Existing standards and mechanisms to consider include:

• DICOM <Be specific>
• Existing IHE profiles, actors, and transactions <Be specific>

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

5. Discussion

<THE DISCUSSION SECTION SHOULD BE DISTRIBUTED THROUGH THE OTHER SECTIONS IN THE DETAILED PROPOSAL>

IHE is a great forum to consider solutions to these clinical challenges. The challenges with additional views might be solved by defining how to apply more generalized scheduled workflow use cases to mammography practices. Where existing profiles may not meet mammography departmental needs, it is believed that the IHE venue may be able to identify other solutions or identify gaps in technology that could be handed off to the appropriate resources (i.e. DICOM committees).

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

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

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

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