Use Case Workflow and Error Reconciliation

From IHE Wiki
Jump to: navigation, search

Mammo Acquisition Workflow and Errors Reconciliation

Below are some error scenarios that are up for consideration:

  1. How universal or significant is this problem?
  2. Existing mechanisms within SWF, DICOM, or other guidance to reconcile the error?
  3. What are really integration issues and what are just good product design issues?


Worklist and other demographic errors - Use Cases

General Observations: There are several things that must be considered when determining how best to handle workflow errors/ exceptions in an automated fashion (assuming it's even possible) :

  • When does the error/ exception actually occur?
  • When is the error/ exception first detected?
  • Can the error/ exception be detected automatically (by a computer system), or must it first detected manually (by a human) before the human triggers any system activity?
  • How many (and which) systems are required to handle/ process the error/ exception?

Note: Several of the error/ exception cases described below are not unique to mammography (e.g., The worklist selection errors detected after procedure has been completed, demographic error cases, etc.)

  1. Single patient worklist selection error:
    • Technologist selects the wrong worklist item from the list (item schedule for patient A, but performed on patient B).
    • Technolgist completes the patient examination, then realizes that the patient was done under the wrong patient and study identifiers.
    • Technologist does not have the proper clearance to correct her mistake at PACS, and the PACS admin doesn’t believe that he can correct or delete the study in PACS, whose images are now attributed to the wrong patient (patient A).
    • The healthcare facility would like to remove the mammography record permanently from the record of the wrong patient (patient A).
    • The facility would like to not re-expose patient B to get properly labeled images in records (also do not want to ask a patient to return, as well).
    • The technologist would like to re-assign her already acquired images to the correct worklist item for patient B.
    • The radiologist would like an indication at the workstation that the images of patient B really do not belong to patient A as labeled so that any misdiagnosis and mis-reporting of patient A is avoided.
    • The radiologist would like to see patient B’s images labeled with patient B’s correct information, including correct order information.
    • The facility would like a clean order for patient A (either use the original with confidence that it won’t be a problem, or cancel the original and generate a new, clean order). They do not want to add images to the already tainted study UID and accession number. They want all related integrated systems (scheduling, billing, reporting, etc.) to be properly reconciled with the original order and changes to the order.
    • The radiologist also wants the CAD objects associated with the corrections to be placed on the proper patient.
    • The radiologist also wants to make sure that prior exam comparison images are associated with the proper patient.
    • Any export or retrieval of patient records should contain only the images attributed to the patient whose records are being exported
    Gap Analysis: Single patient worklist selection error
    1. This use case (where a worklist selection error is detected after completion of the procedure step at the modality) is currently unspecified in the Radiology TF (or under-specified at best). The only mention of this situation occurs in Volume 1, section 3.3.4, item #3 in the numbered list:
      "After the Modality Procedure Step Completed transaction has been issued, the Operator/Radiologist may notice or become aware that an incorrect worklist entry selection was made. Whether this occurs before the Requested Procedure is read or afterwards, the modality is not responsible for performing the necessary corrections. Rather the Image Manager and the Department Scheduler Actors must make such corrections (See Volume 2 - section 4.7.4.1.3.1). The Image Manager and the Order Filler may also offer a correction capability to recover the erroneous instances. IHE does not provide a mechanism to propagate automatically this correction between the Image Manager/Image Archive and the Department System Scheduler/Order Filler."
      This last statement clearly identifies a gap that needs to be filled
    2. Further, looking at the referenced section (from above) in Volume 2 provides the following guidance:
      "In this case the Image Manager and Department System Scheduler shall take the appropriate action to ensure that already received incorrect instances (i.e. SOP Instances referenced by this Discontinued PPS) are not mistakenly used. If the images, presentation states, or key image notes are not actually deleted, the Image Manager shall:
      • not return SOP Instance UIDs for the images in query responses,
      • not return such images in Patient, Study, Series, or Instance level retrievals"
    3. The guidance provided in the Volume 2 section assumes the DSS/OF and Image Manager/ Archive has received indication/ notification of the error via the MPPS N-Set message (with a status of DISCONTINUED and the appropriate reason code). For the case described here (Single patient worklist selection error - where the error is detected after the MPPS N-Set is sent), there is no indication of how the DSS/OF and Image Manager/ Archive are to automatically 'detect' such a case after receipt of an apparently successful MPPS message (or if that's even possible).
    4. Bottom-line: "Automated" detection and system-to-system notification of incorrect worklist selection errors that are detected after "successful" procedure step completion is indicated/ initiated from the modality system is a gap.
    RECOMMENDATION: This may indeed be worth addressing, but should be done within the context of the SWF II activities. ACTION: Open issue in SWF II
  2. Multiple patient worklist selection error:
    • Technologist selects the wrong worklist item from the list (item schedule for patient A, but performed on patient B).
    • During patient B’s exam, in another room, a technologist with patient A selects the same, correct worklist item for patient A. [Note – a comment from one technologist is that she wished the “system” could lock out the other system from selecting a worklist item that was already in use]
    • Both patient B’s and patient A’s images are mixed within the same patient and study identifiers
    • The technologist who made the mistake wants to correct her mistake and label patient B’s images properly.
    • The study can not be deleted out of PACS because it contains not only improperly labeled images (patient B), but properly labeled images (patient A).
    • The facility does not want to re-expose either patient for the sake of proper labeling.
    • The radiologist wants to see patient A’s images (and priors and CAD), but not see patient B’s images when making a diagnosis for patient A.
    • The radiologist wants to see patient B’s images with the associated CAD and prior exam images for patient B, and not see any references (labeling, objects) associated with patient A.
    • Everyone would like to not confuse patient B’s and patient A’s images ever in the future (need to reconcile archived records for retrieval and export). Note: the technologist suggested a way to split up accidentally merged patient records would be a help.
    Gap Analysis: Multiple patient worklist selection error
    1. All the observations/ comments listed under the "Single patient worklist selection error" case apply here
    2. Additionally, another gap is identified within this use case: the desire to have the worklist provider manage/ prevent more than one modality from selecting/ performing a single worklist item.
    3. This second gap cannot be addressed without changing the mechanism by which modalities retrieve their worklists. The DICOM MWL service does not include a mechanism for the modality to "claim" a workitem. To the best of my knowledge, this capability is only available in the DICOM General Purpose Worklist (GPWL) and Unified Worklist and Procedure Step (UPS) Services.
      (CDi): If a Modality is required to immediately send an MPPS in Progress to the PPS Mgr. when a worklist entry is selected, then this is a 'claiming mechanism'.
      (CAL) : If MPPS is used to "claim" the MWL item, we need to be very careful about deadlock situations.
    RECOMMENDATION: This may indeed be worth addressing, but should be done within the context of the SWF II activities. ACTION: Open issue in SWF II; Is there any recommendations that we can currently provide to correct the Image Manager/RIS updates and how they play together.
  3. Procedure order error
    • A patient has a standard screening exam ordered, but she has implants.
    • The tech is told to adjust the order at the RIS, but doesn’t have access to this system.
    • The tech does the standard screening, then adds another procedure to acquire the implant views, resulting in two studies (or two procedure steps of the same study)
    • The tech (or someone else) has to go to the RIS to adjust the charges for the exams performed vs. those ordered.
    • Note: the tech relaying the issue wished for an easy procedure conversion at the modality that would switch the order from the standard screening to an implant screening exam. I’m guessing that this is just an application of the append/change order case with upstream and downstream systems adjusting without manual intervention.
    Gap Analysis: Procedure order error
    1. Since the technologist performs the standard screening exam as ordered and then adds on the procedure for the implant views (see 3rd bullet), this is simply the "Append Case" as described in Volume 2, section 4.6.4.1.2.3.3 (becoming two procedure steps within the same study). The specific details of how the modality is expected to fill key identifying attributes in MPPS and image IOD objects is described in Volume 2, Appendix A.
    RECOMMENDATION: There appears to be nothing to do for this case.
    (CAL) FOR DISCUSSION: For Mammography Hanging Protocols, Reporting and Billing, do we need to go through the workflow and ensure that the existence of 2 Performed Procedures works? We know that additional Technical Billing Charges are not permitted for Implants. ACTION: Informative Text in Volume 1 - Mammography Appendix. Discussion on the Cross-over between the Proedure Coding, the Reason for Exam, etc.
  4. Demographic errors I
    • During an exam, the patient and technologist discover that identifying patient information supplied by the worklist is not correct (like MRN when SS# are used, last names).
    • The technologist does not have access to the registration system to fix the demographic errors, but does not want to acquire images (or has already acquired images) that have incorrect information.
    • The technologist would like to fix the demographics on the image either before or after (depending upon moment of discovery) images are sent to PACS and workstations.
    • Note: these errors may also be in the prior exam images retrieved from PACS. One technologist comment that in one facility, she was able to correct some years in PACS, but not others??
    Gap Analysis: Demographic errors I
    1. The use cases described here and in "Demographic Errors II" match the scenarios described in SWF (Volume 1, section 3.3.2.2 - Patient Update after Procedure Scheduling), and PIR (Volume 1, sections 4.3.1 - PIR during Image Acquisition, and 4.4.6 - Case 6: PIR during Image Acquisition).
    RECOMMENDATION: Since the use cases listed here are already called out in the SWF and PIR profiles, there doesn't appear to be any mammography specific text to write, unless it's deemed desirable to explicitly state that the patient demographic updates and patient information reconciliation within ammography environments can be handled using the existing SWF & PIR mechanisms. ACTION: Informative Text in Volume 1 - Mammography Appendix. Handle both Demographic errors I/II.
  5. Demographic errors II
    • During an exam, the patient commented that the DOB was not correct on her images (not sure if current or prior)
    • The technologist attempted to correct the DOB at the PACS (a remote disaster recovery – type PACS).
    • DOB corrections appeared to take, however, 24 hours afterwards, the correction was gone.
    • The tech wonders if the problem had to do with being able to correct the DOB on the local cache, but the long term archive did not correct.
    Gap Analysis: Demographic errors II
    1. The use cases described here and in "Demographic Errors I" match the scenarios described in SWF (Volume 1, section 3.3.2.2 - Patient Update after Procedure Scheduling), and PIR (Volume 1, sections 4.3.1 - PIR during Image Acquisition, and 4.4.6 - Case 6: PIR during Image Acquisition).
    RECOMMENDATION: Since the use cases listed here are already called out in the SWF and PIR profiles, there doesn't appear to be any mammography specific text to write, unless it's deemed desirable to explicitly state that the patient demographic updates and patient information reconciliation within mammography environments can be handled using the existing SWF & PIR mechanisms. ACTION: To be handled same as Demographic Errors I
  6. Multiple MRN’s of the same patient
    • Sometimes the facility (or the patient during registration) does not realize that a patient has already been registered within that facility. This could be due to a simple name change which is common in women’s healthcare.
    • Technologist have experienced systems which do not facilitate operations for patients who have the same MRN, but have different names – case where the patient has changed her last name, or a nick name was used in one of the records.
    • Technologists have experienced systems which do not facilitate operations for patients who are the same patient, but have been issued multiple medical record numbers, because the registering agent did not recognize a prior existing record.
    • Technologists and radiologist would like systems that recognize the connection between patient records in the scenarios above and allow a merge function that treats dissimilar demographic identifiers as the same patient.
    Gap Analysis: Multiple MRN’s of the same patient
    1. The scenarios described in the first three bullets are identical to use cases included in the SWF and PIR Profiles, and can all be handled using those existing specifications. (The first and third bullets described the need for patient merges and teh second bullet is a simple patient update)
    2. The fourth bullet describes the "internal logic" (smarts) that is expected to exist as part of the Patient Identifier Cross-reference (PIX) Manager actor within the ITI PIX profile. This capability combined with the PIR cases for handling patient merges and updates should adequately cover this use case.
    RECOMMENDATION: Since the use cases listed here are already called out in the SWF, PIR (and possibly PIX) profiles, there doesn't appear to be any mammography specific text to write, unless it's deemed desirable to explicitly state that the patient demographic updates and patient information reconciliation (merges) within mammography environments can be handled using the existing SWF & PIR mechanisms. ACTION: Full support for Multi-MRNs should be discussed as part of SWF- support of ITI profiles such as PIX. Mammo Appendix may want to touch on this. Additionally, discussion should occur on how Scanned Films, CDs, etc. should use the Import Reconciliation to ensure that Identifiers are consistent for call-up of priors.
  7. Facilities without RIS:
    • Our applications staff says that they are challenged by following the IHE technical framework for demographic updates. The mammography market place has a significant enough population of providers without RIS’s or RIS to PACS communication, that they desire additional paths for demographic corrections or updates.
    Gap Analysis: Facilities without RIS
    1. IHE Integration Profiles are predicated on having a minimum, fundamental set of "responsibilities" (aka Actors) being necessary and implemented within the systems operating within the given healthcare environment.
    RECOMMENDATION: I would recommend NOT relaxing this 'prerequisite' to address this particular request for the following reasons:
    • I believe that mammography operations still have the need to perform the functions/ responsibilities that IHE allocates to the Department System Scheduler/ Order Filler (and Image Manager/ Archive Actors), even if the systems that typically implement these responsibilities (RISs) are not present in the environment.
    • IHE specifications do not prevent these capabilities from being implemented within a single system (known as actor grouping). For example, the functions that are typically implemented within a RIS system must still be done in environments without a "RIS". It is perfectly fine to have some other system within that environment implement that functionality. It then becomes purely a commerical question whether any vendor sees fit to implement such a system.
    • The goal of IHE is to improve interoperability between computer systems within healthcare. In environments where portions of the workflow are done manually, the benefits of IHE will be limited to those areas where computer systems are required to interoperate.
PROPOSED ACTION: Remove Use Case.

Corrected Views, Additional views, and Rejected views - Use cases

  1. Acquisition taken with wrong view defaults
    • The technologist takes a left breast cranial caudal view (LCC), and didn’t realize that defaults were set for a right breast (RCC) view.
    • Images have already been sent to CAD, PACS, and mammography workstation
    • The technologist would like to correct the image with the proper labeling (view code, view description, patient orientation, laterality, possibly other tags like view modifier, series description).
    • The technologist does not want to re-expose the patient to get a properly labeled LCC, and would like to be able to correct her mistake.
    • The radiologist doesn’t want to miss diagnose a right breast for a left breast
    • The radiologist wants images to be labeled correctly.
    • The radiologist doesn’t want an incorrectly labeled image to be included in her hanging protocol (either hung improperly or labeled improperly)
    • The radiologist would like accurate CAD results with proper hanging on the corrected image and be aware of any incorrect images. Note from technologist: even when given a tool to correct demographics, the CAD does not come out on the corrected images. I believe that this may have something to do with referencing the same original source image as the incorrect image, but I’m not completely sure of the underlying issue, but may have access to CAD, modality, and workstation developers who do understand it.
    • Technologist note: some PACS don’t seem to take the corrected image, or even with the orientation properly relabeled, still hang the images improperly. I have the name of the PACS, but don’t fully have the detail of the underlying problem. Also, in the instance, the CAD does not hang properly on the corrected image.
    • The facility would like the archived patient record to not confuse any one with its future use (avoid the export and retrieval of improperly labeled images where the technologist and radiologist are unaware of the original mistake – as opposed to current exam mistakes which can be discussed among the tech who made the mistake and the reading radiologist.)
    Gap Analysis: Acquisition taken with wrong view defaults
    1. In this case, initial detection of the error condition is manual (i.e., a human determines the error occurred).
    2. The error actually occurs during the acquistion step, but is not detected until after the acquisition, and after the acquisition artifacts (images) have been sent to other systems (e.g., the PACS (IM/IA)).
    3. The existing "Exception Management Option" on the SWF profile is the closest thing that exists for handling this case, but it wasn't designed with this case in mind and as a result, doesn't provide adequate guidance/ specification about what the affected systems should do in this case.
    RECOMMENDATION: Include in Mammo Acquisition Workflow activity. One reasonable approach might be add another option to SWF that expands on the behavior already described in SWF's Exception Management Option. This would also need to be factored into the SWF II work.
  2. Finish additional views in another room:
    • During a diagnostic exam, the technologist must add views after having completed a worklist item. However, the original room is not available, so she uses another room
    • In some facilities the worklist item is no longer available to be selected for use. In other facilities, the worklist item still remains and can be used by the technologist.
    • The technologist would like easy access to the original images, and then acquires the additional views.
    • The technologist stated that they see complications with the MPPS messages in this scenario, but did not elaborate further. Does anyone know if implementations that cause specific issues?
    Gap Analysis: Finish additional views in another room
    1. (Observation): It will not be possible to include the additional views within the same series as the original views if taken on a separate piece of equipment as this would be a violation of DICOM.
    2. If MWL is unavailable, it will be difficult (and certainly inconvenient) to add views to the same study (identified by a study UID). This is especially true if the additional views are to be taken on a different piece of equipment.
    RECOMMENDATION: Include this in the Mammo Acquisition Worflow activities for this year. An IHE solution to this problem exists within the Cardiology domain. Use Case C7 within the Cath Workflow profile (Cardio TF Volume 1) exactly describes the case of changing the room (and associated equipment) mid-procedure. This specification could (should) be the basis for solving what is essentially the same problem in the mammography environment. Note that the solution described in the Cardiology Profile requires the availability (provision) of Modality Worklist (MWL) information to the modalities in the new room.
  3. Multiple rejected views:
    • While trying to correct demographics on a modality, the technologist ended up with extra copies of rejected views.
    • I have no more specifics, and the tech couldn’t remember exactly how she got in this situation, but the reason for noting this case is to be aware of rejected views, and whether or this group should provide guidance on how to handle rejected views in terms of image availability, views deemed rejected after being sent to store devices, and any effect rejected views should have on MPPS content (to include or not include in the image count and reference sequences)
    Gap Analysis: Multiple rejected views
    1. (Observation): There is very little information provided here to analyze/ provide a recommendation on, though at first glance it doesn't appear as though the existing Technical Framework covers this specific case.
    2. That said, the behavior expected from the affected systems when "rejected views" are produced appears to be similar to the behavior expected from systems when a procedure is discontinued (as described in the PPS Exception Mgmt Option section in Volume 2).
    RECOMMENDATION: Within the context of this year's Mammo Workflow activities, investigate the options to leverage/ extend the existing PPS Exception Management Option to include an indication of "rejected views" (presumably for quality control reaons?). This may require 2 PPSs that refer to the same requested procedure/ SPS -- one that gets marked as COMPLETED and references the 'good' images, and a second that is marked as DISCONTINUED with references to the "rejected views" (images).

Systems level Concerns – multiple PACS - Use cases

  1. PACS supporting multiple facilities:
    • Some PACS vendors are tying together multiple facilities which have overlapping patient ID’s
    • The technologist or radiologist will query on PACS, and see records all attributed to the same name.
    • When the records are retrieved, the patient ID’s are all the same, but the actual names that come with the records have different names, and indeed are different patients.
    • Personal note: I have worked with PACS tying together multiple facilities with different PID schemas and the PACS will respond the PID queries, but strip the PID upon retrieval if the patient doesn’t have a local PID, instead of returning the record with a compatible PID.
  2. Facilities with multiple PACS:
    • In some facilities, technologist and radiologist need to pull patient records from a variety of PACS for which they have access. Example – a same “healthcare provider” remote facility (with it’s own PACS) does only screening exams. The patient is referred to another facility (with its own PACS) in the same network, that does diagnostic exams. At the diagnostic site, the staff pulls images from the remote facility PACS
    • The remote PACS and local PACS do not have the same patient and study identifier schema.
    • The technologist and radiologist would like to merge the records to view the images of patient all together.
    • The facilities do not want different patients with the same ID (because of multiple patient domains) to have their records accidentally combined or mixed-up