Use Case Workflow and Error Reconciliation

From IHE Wiki
Revision as of 11:04, 4 January 2008 by Pseifert (talk | contribs) (added analysis and recommendation for "Acquisition taken with wrong view defaults" case)
Jump to navigation Jump to 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?
  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.
  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'.
    RECOMMENDATION: This may indeed be worth addressing, but should be done within the context of the SWF II activities.
  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 describes in Volume 2, Appendix A.
    RECOMMENDATION: There appears to be nothing to do for this case.
  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.
  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 ammography environments can be handled using the existing SWF & PIR mechanisms.
  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. observation #1
    2. Paul Seifert to fill in remainder of details here
  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:
    • It is difficult for me to believe that mammography operations don't have the need to perform the functions/ responsibilities that IHE allocates to the Department System Scheduler/ Order Filler (and Image Manager/ Archive Actors).
    • 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.

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 would be add another option to SWF that expands on teh 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 #1
    2. Paul Seifert to fill in remainder of details here
  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 #1
    2. Paul Seifert to fill in remainder of details here

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
Retrieved from "http://wiki.ihe.net/index.php?title=Use_Case_Workflow_and_Error_Reconciliation&oldid=12490"